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...@gmail.com> To: Tom Lane <t...@sss.pgh.pa.us> Cc: Alban Hertroys <haram...@gmail.com>; pgsql-general@postgresql.org; markdil...@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 <t...@sss.pgh.pa.us> wrote: deepak <deepak...@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). > >Hmm. It's easy enough to postpone temp file cleanup till after the >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 >