On 2017-02-10 07:52:57 -0500, Robert Haas wrote: > On Thu, Feb 9, 2017 at 6:38 PM, Thomas Munro > > Up until two minutes ago I assumed that policy would leave only two > > possibilities: you attach to the DSM segment and attach to the > > SharedBufFileManager successfully or you attach to the DSM segment and > > then die horribly (but not throw) and the postmaster restarts the > > whole cluster and blows all temp files away with RemovePgTempFiles(). > > But I see now in the comment of that function that crash-induced > > restarts don't call that because "someone might want to examine the > > temp files for debugging purposes". Given that policy for regular > > private BufFiles, I don't see why that shouldn't apply equally to > > shared files: after a crash restart, you may have some junk files that > > won't be cleaned up until your next clean restart, whether they were > > private or shared BufFiles. > > I think most people (other than Tom) would agree that that policy > isn't really sensible any more; it probably made sense when the > PostgreSQL user community was much smaller and consisted mostly of the > people developing PostgreSQL, but these days it's much more likely to > cause operational headaches than to help a developer debug.
FWIW, we have restart_after_crash = false. If you need to debug things, you can enable that. Hence the whole RemovePgTempFiles() crash-restart exemption isn't required anymore, we have a much more targeted solution. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers