I tried moving the call to RemovePgTempFiles until
after the PID file is fully written, but it did not help.
pg_ctl attempts to connect to the database, and does
not report the database as running until that connection
succeeds. I am not comfortable moving the call to
RemovePgTempFiles after the point in the postmaster
where child processes are spawned and connections
made available to clients because by that point the
temporary files encountered may be valid ones from
the current incarnation of Postgres and not from the
incarnation before the reboot.
I do not know precisely why the filesystem is so slow,
except to say that we have many relations:
xyzzy=# select count(*) from pg_catalog.pg_class;
count
-------
27340
(1 row)
xyzzy=# select count(*) from pg_catalog.pg_attribute;
count
--------
236252
(1 row)
Running `find . | wc -l` on the data directory gives
55219
From: deepak <deepak.pn@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alban Hertroys <haramrae@gmail.com>; pgsql-general@postgresql.org; markdilger@yahoo.com
Sent: Wednesday, May 23, 2012 9:03 AM
Subject: Re: [GENERAL] FATAL: lock file "postmaster.pid" already exists
Thanks, I have put one of the other developers working on this issue, to comment.
--
Deepak
On Mon, May 21, 2012 at 10:55 PM, Tom Lane
<tgl@sss.pgh.pa.us> wrote:
deepak <
deepak.pn@gmail.com> writes:
> We could reproduce the start-up problem on Windows 2003. After a reboot,
> postmaster, in its start-up sequence cleans up old temporary files, and
> this step used to take several minutes (a little over 4 minutes), delaying
> the writing of line 6 onwards into the PID file. This delay caused pg_ctl
> to timeout, leaving behind an orphaned postgres.exe process (which
> eventually forks off many other postgres.exe processes).
postmaster's PID file is completely written, so I've committed a patch
for that. However, I find it mildly astonishing that such cleanup could
take multiple minutes. What are you using for storage, a man with an
abacus?
regards, tom lane