Search Postgresql Archives

Re: FATAL: lock file "postmaster.pid" already exists

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx>
To: Tom Lane <tgl@xxxxxxxxxxxxx>
Cc: Alban Hertroys <haramrae@xxxxxxxxx>; pgsql-general@xxxxxxxxxxxxxx; markdilger@xxxxxxxxx
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@xxxxxxxxxxxxx> wrote:
deepak <deepak.pn@xxxxxxxxx> 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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux