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
