From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: HOT patch - version 14 |
Date: | 2007-08-30 22:16:49 |
Message-ID: | 20070830221649.GZ5872@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane escribió:
> "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
> > On 8/30/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> I don't think that works --- what if the last tuple in the chain isn't
> >> committed good yet? If its inserter ultimately rolls back, you've
> >> indexed the wrong value.
>
> > I am confused. How could we get ShareLock on the relation while
> > there is some open transaction which has inserted a tuple in the
> > table ? (Of course, I am not considering the system tables here)
>
> Not if someone else releases lock before committing.
FWIW, a red flag raised for me here, though maybe it is irrelevant or
unimportant. Currently, VACUUM acquires an exclusive lock for
truncating the table. The lock is kept till commit. However I am
proposing that it be released before commit.
Now, VACUUM never inserts rows. But I don't claim I understand what's
going on here.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-08-30 23:24:36 | Re: HOT patch - version 14 |
Previous Message | Andrew Dunstan | 2007-08-30 21:44:16 | Re: enum types and binary queries |