Re: drop/truncate table sucks for large values of shared buffers - Mailing list pgsql-hackers

From Robert Haas
Subject Re: drop/truncate table sucks for large values of shared buffers
Date
Msg-id CA+TgmoZrPikGs=BCFWUg0ouXx4KpnR2Nken8XfR0nyYY=s49ag@mail.gmail.com
Whole thread Raw
In response to Re: drop/truncate table sucks for large values of shared buffers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Jun 28, 2015 at 12:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm not sure what you consider "dire", but missing a dirty buffer
> belonging to the to-be-destroyed table would result in the system being
> permanently unable to checkpoint, because attempts to write out the buffer
> to the no-longer-extant file would fail.  You could only get out of the
> situation via a forced database crash (immediate shutdown), followed by
> replaying all the WAL since the time of the problem.  In production
> contexts that could be pretty dire.

Hmm, that is kind of ugly.  Is the write actually going to fail,
though, or is it just going to create a sparse file?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Solaris testers wanted for strxfrm() behavior
Next
From: Robert Haas
Date:
Subject: Re: anole: assorted stability problems