| From: | Hannu Krosing <hannu(at)krosing(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: Nasty bug in heap_page_prune |
| Date: | 2008-03-07 10:12:45 |
| Message-ID: | 1204884765.6568.1.camel@huvostro |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 2008-03-05 at 20:23 -0500, Tom Lane wrote:
> Not sure about a clean solution to this. I don't really want to
> bastardize inval.c by making it deal with nontransactional semantics,
> but there may be no other way.
Is this something that happens only with concurrent VACUUM FULLs ?
If so, than can't we just disallow doing them concurrently ?
VACUUM FULL is something you don't want on a high-load database anyway
> Or we could forget about letting VACUUM FULL collapse out LP_REDIRECT
> pointers, at least in system catalogs. That might be the best answer
> for 8.3 in any case; I am not seeing a real fix that I'd care to risk
> back-patching. (Note that this is not exactly trivial in itself, since
> then vacuum.c would need at least some minimal ability to deal with
> LP_REDIRECT entries.)
>
> regards, tom lane
Hannu Krosing
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Anton Melser | 2008-03-07 10:26:14 | shared_buffers and shmmax what are the max recommended values? |
| Previous Message | Pavan Deolasee | 2008-03-07 09:22:56 | Re: 8.3.0 Core with concurrent vacuum fulls |