Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
What do you think about solving the requirements of the *first* waiting
phase (Where we wait for current ShareLock holders) inside the lock manager?
The only real downside I can see is that I feel uneasy about messing with
that code.
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> What do you think about solving the requirements of the *first* waiting
> phase (Where we wait for current ShareLock holders) inside the lock manager?
> The only real downside I can see is that I feel uneasy about messing with
> that code... It seems
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Sounds good, if we decide to go with the transient XID idea. So below
for an alternative that I just came up with.
This proposal appears to require taking and releasing a brand-new lock
type every time a snapshot is made or destroy
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Sounds good, if we decide to go with the transient XID idea. So below
> for an alternative that I just came up with.
This proposal appears to require taking and releasing a brand-new lock
type every time a snapshot is made or destroyed. That is cer
Tom Lane wrote:
I wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Yeah - I do not really like that dual-locking thing either. But it makes
prepared transaction handling much easier - if we were to only lock the
RID, we'd have to store the rid<->xid mapping for prepared transactions
Hmm
I wrote:
> "Florian G. Pflug" <[EMAIL PROTECTED]> writes:
>> Yeah - I do not really like that dual-locking thing either. But it makes
>> prepared transaction handling much easier - if we were to only lock the
>> RID, we'd have to store the rid<->xid mapping for prepared transactions
> Hmmm th
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> [ squint... ] Why do you need that?
> I invented the TemporaryTransactionId because it seemed worthwhile to
> distinguish between backends which do not currently run a transaction
> (xid == InvalidTransactionId), and such which r
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
I've spent the last few days factoring out that work, and turning it into
a general solution. The result is this patch, which basically does the following
.) It defines a special TemporaryTransactionId that is used as an xact's xi
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> I've spent the last few days factoring out that work, and turning it into
> a general solution. The result is this patch, which basically does the
> following
> .) It defines a special TemporaryTransactionId that is used as an xact's xid
> unt
I'm resending this without that actual patch attached, since my first
mail didn't get through. The patch can be found here:
http://soc.phlo.org/lazyxidassign.patch
Hi
Lately, there was some interest in assigning XIDs for toplevel Transactions
only when the transaction actually needs one (that is
10 matches
Mail list logo
