On Tue, Dec 2, 2014 at 11:54 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: > During abort processing after getting a SIGTERM, the back end truncates > 59288 to zero size, and unlinks all the other files (including 59288_init). > The actual removal of 59288 is left until the checkpoint. So if you SIGTERM > the backend, then take down the server uncleanly before the next checkpoint > completes, you are left with just 59288. > > Here is the strace: > > open("base/16416/59288", O_RDWR) = 8 > ftruncate(8, 0) = 0 > close(8) = 0 > unlink("base/16416/59288.1") = -1 ENOENT (No such file or > directory) > unlink("base/16416/59288_fsm") = -1 ENOENT (No such file or > directory) > unlink("base/16416/59288_vm") = -1 ENOENT (No such file or > directory) > unlink("base/16416/59288_init") = 0 > unlink("base/16416/59288_init.1") = -1 ENOENT (No such file or > directory)
Hmm, that's not good. I guess we can either adopt your suggestion of adjusting ResetUnloggedRelationsInDbspaceDir() to cope with the possibility that the situation has changed during recovery, or else figure out how to be more stringent about the order in which forks get removed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers