Re: Lazy xid assignment V4

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
Cc: "PostgreSQL-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Lazy xid assignment V4
Date: 2007-09-05 10:19:04
Message-ID: 46DE8298.90103@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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.

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.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian G. Pflug 2007-09-05 11:42:03 Re: Lazy xid assignment V4
Previous Message tomas 2007-09-05 07:56:48 Re: Per-function GUC settings: trickier than it looked

Browse pgsql-patches by date

  From Date Subject
Next Message Florian G. Pflug 2007-09-05 11:42:03 Re: Lazy xid assignment V4
Previous Message Kris Jurka 2007-09-05 09:49:30 GSS warnings