| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavan Deolasee | 2007-08-31 05:26:34 | Re: HOT patch - version 14 |
| Previous Message | Alvaro Herrera | 2007-08-30 22:16:49 | Re: HOT patch - version 14 |