pgsql: Move postmaster's RemovePgTempFiles call to a less randomly chos

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Move postmaster's RemovePgTempFiles call to a less randomly chos
Date: 2012-05-22 02:50:48
Message-ID: E1SWfBQ-00064r-7F@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Move postmaster's RemovePgTempFiles call to a less randomly chosen place.

There is no reason to do this as early as possible in postmaster startup,
and good reason not to do it until we have completely created the
postmaster's lock file, namely that it might contribute to pg_ctl thinking
that postmaster startup has timed out. (This would require a rather
unusual amount of time to be spent scanning temp file directories, but we
have at least one field report of it happening reproducibly.)

Back-patch to 9.1. Before that, pg_ctl didn't wait for additional info to
be added to the lock file, so it wasn't a problem.

Note that this is not a complete fix to the slow-start issue in 9.1,
because we still had identify_system_timezone being run during postmaster
start in 9.1. But that's at least a reasonably well-defined delay, with
an easy workaround if needed, whereas the temp-files scan is not so
predictable and cannot be avoided.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/b94ce6e807ce5685bda1dcd36027091ceec6b5a0

Modified Files
--------------
src/backend/postmaster/postmaster.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2012-05-22 13:32:47 pgsql: Repair out-of-date information in src/backend/storage/buffer/REA
Previous Message Tom Lane 2012-05-22 02:11:09 pgsql: Update woefully-obsolete comment.