From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Race condition in b-tree page deletion |
Date: | 2013-11-09 16:24:46 |
Message-ID: | 32194.1384014286@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> 2. The second-simplest solution I see is to keep locked the whole chain
> of pages that will be deleted, and delete all of them as one atomic
> WAL-logged operation. Ie. the leaf page, and all the parent pages above
> it that will become half-dead, and the parent of the last half-dead page.
This would be more tenable if we could put a known limit on the number of
pages to be changed at once. I'm not too awake at the moment, so maybe
this is not possible, but could we simply decide in advance that we won't
propagate page deletion up more than a-small-number of levels? It'd
require allowing a page to remain half-dead until some other vacuum comes
along and fixes it, but that seems OK.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | pansen | 2013-11-09 16:39:17 | Re: Darwin: make check fails with "child process exited with exit code 134" |
Previous Message | Heikki Linnakangas | 2013-11-09 16:02:02 | Race condition in b-tree page deletion |