Re: Lazy xid assignment V4 - Mailing list pgsql-patches

From Florian G. Pflug
Subject Re: Lazy xid assignment V4
Date
Msg-id 46DE97D2.5060400@phlo.org
Whole thread Raw
In response to Re: Lazy xid assignment V4  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
List pgsql-patches
Heikki Linnakangas wrote:
> Florian G. Pflug wrote:
>> 1) 2PC was broken in V3. I added code that skips
>> LOCKTYPE_VIRTUALTRANSACTION
>> locks when writing the locks to the 2PC state file, but I didn't
>> add the same exception to the code that reassigns the locks to
>> a dummy PGROC afterwards. So the locks weren't released at PREPARE
>> time. Fixed now.
>
> Let me check if I got this right:
>
> We only use the lock on virtual transaction id in CREATE INDEX
> CONCURRENTLY, to wait until everyone that might insert to the table sees
> the new index. Releasing the virtual transaction id right away at
> PREPARE TRANSACTION, instead of reassigning it to the dummy PGPROC, is
> ok because the transaction can't insert anything to the table after
> PREPARE TRANSACTION.

Yes. Or to put it another way: We use the transaction id to wait for
transactions that did on-disk changes, and the virtual transaction id
to wait for transactions only found in shared memory. Since xacts mostly
vanishe from shmem at PREPARE time, we drop the lock on the VXID,
but keep the one on XID.

> Sounds valid to me, but better add some comments to note that the lock
> is released early, in case it's going to be used for some other purpose
> in the future.
Yeah, more comments are always a Good Thing I guess.

greetings, Florian Pflug



pgsql-patches by date:

Previous
From: "Florian G. Pflug"
Date:
Subject: Re: Lazy xid assignment V4
Next
From: "Heikki Linnakangas"
Date:
Subject: Re: tsearch refactorings