Skip site navigation (1) Skip section navigation (2)

Re: HOT patch - version 14

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: (view raw, whole thread or download thread mbox)
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                      
The PostgreSQL Company - Command Prompt, Inc.

In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2007-08-30 23:24:36
Subject: Re: HOT patch - version 14
Previous:From: Andrew DunstanDate: 2007-08-30 21:44:16
Subject: Re: enum types and binary queries

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group