| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Hannu Krosing <hannu(at)skype(dot)net> |
| Cc: | Neil Conway <neilc(at)samurai(dot)com>, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: PATCH to allow concurrent VACUUMs to not lock each |
| Date: | 2005-05-23 15:42:31 |
| Message-ID: | 8215.1116862951@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Hannu Krosing <hannu(at)skype(dot)net> writes:
> I can't think of any other cases where it could matter, as at least the
> work done inside vacuum_rel() itself seema non-rollbackable.
VACUUM FULL's tuple-moving is definitely roll-back-able, so it might be
prudent to only do this for lazy VACUUM. But on the other hand, VACUUM
FULL holds an exclusive lock on the table so no one else is going to see
its effects concurrently anyway.
As I said, it needs more thought than I've been able to spare for it yet
...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2005-05-23 15:55:01 | Re: inet increment w/ int8 |
| Previous Message | --= Tono =-- | 2005-05-23 15:26:38 | Re: INSTEAD OF trigger on VIEWs |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2005-05-23 16:20:16 | Re: PATCH to allow concurrent VACUUMs to not lock each |
| Previous Message | Hannu Krosing | 2005-05-23 15:13:47 | Re: PATCH to allow concurrent VACUUMs to not lock each |