| From: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
|---|---|
| To: | "Hannu Krosing" <hannu(at)krosing(dot)net> |
| Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Nasty bug in heap_page_prune |
| Date: | 2008-03-07 10:40:56 |
| Message-ID: | 2e78013d0803070240p27cd1cadqd39cb8539c482a90@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 7, 2008 at 3:42 PM, Hannu Krosing <hannu(at)krosing(dot)net> wrote:
>
> Is this something that happens only with concurrent VACUUM FULLs ?
>
No, its about VACUUM FULL on a system catalog which fails for some reason.
The VACUUM FULL may have changed CTID of a tuple because of line
pointer redirection collapse. But the change is non-transactional.
The current cache invalidation mechanism can only handle transactional changes
(since it does not broadcast invalidations if the transaction aborts). Hence
some other backend which has cached the tuple may not see the change
in CTID and fail when the cached tuple is accessed.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2008-03-07 10:52:34 | Re: Grouped Index Tuples |
| Previous Message | Anton Melser | 2008-03-07 10:26:14 | shared_buffers and shmmax what are the max recommended values? |