On Wed, 2006-05-03 at 10:56 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > On Tue, 2006-05-02 at 15:35 -0400, Tom Lane wrote: > >> This is unnecessary and probably wrong. > > > You'll need to be more specific about what you mean. > > There is no point in marking a page half-dead, as that doesn't save > anyone else from visiting it, and it's probably wrong to mark a leaf > page as half-dead at all. That state is associated with upper pages. > > Even if it were a legal tree configuration, marking the page half-dead > would make it impossible to insert any more keys in the page, which > doesn't strike me as an appropriate behavior; it's likely to force > excess I/O later due to unnecessary page splits during future inserts.
OK. So do you see a problem scenario like this? A, B and C separate backends: A1 Reads page, some row versions are *not* marked LP_DELETE but will be later when A2 happens B1 VACUUM removes dead rows, just happens to be all of them B2 Recycles page into FSM C1 Inserts new data into old page A2 Attempts to update old page to notify about dead rows (UGH!) B2 can only stopped by pinning... -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly