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

Re: HOT patch - version 14

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
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 23:24:36
Message-ID: 2661.1188516276@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane escribi:
>> 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.

I think that's all right, because it's dealing with a different set of
concerns.  AFAICS the only issue for truncation is to prevent physical
access to the blocks in question until we can get rid of them.  Once
they're gone, if there wasn't an active seqscan (with an
already-established notion of the max block number to scan to), there
would be no reason for anyone to try to touch them.

			regards, tom lane

In response to

pgsql-patches by date

Next:From: Pavan DeolaseeDate: 2007-08-31 05:26:34
Subject: Re: HOT patch - version 14
Previous:From: Alvaro HerreraDate: 2007-08-30 22:16:49
Subject: Re: HOT patch - version 14

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