Re: FATAL: lock file "postmaster.pid" already exists - Mailing list pgsql-general

From Mark Dilger
Subject Re: FATAL: lock file "postmaster.pid" already exists
Date
Msg-id 1337813238.84595.YahooMailNeo@web39302.mail.mud.yahoo.com
Whole thread Raw
In response to Re: FATAL: lock file "postmaster.pid" already exists  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: FATAL: lock file "postmaster.pid" already exists
Re: FATAL: lock file "postmaster.pid" already exists
List pgsql-general
I am running this code on Windows 2003.  It
appears that postgres has in src/port/dirent.c
a port of readdir() that internally uses the
WIN32_FIND_DATA structure, and the function
FindNextFile() to iterate through the directory.
Looking at the documentation, it seems that
this function does collect file creation time,
last access time, last write time, file size, etc.,
much like performing a stat.

In my case, the code is iterating through roughly
56,000 files.  Apparently, this is doing the
equivalent of a stat on each of them.

See http://msdn.microsoft.com/en-us/library/windows/desktop/aa365740%28v=vs.85%29.aspx




From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Dilger <markdilger@yahoo.com>
Cc: deepak <deepak.pn@gmail.com>; Alban Hertroys <haramrae@gmail.com>; "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
Sent: Wednesday, May 23, 2012 1:54 PM
Subject: Re: [GENERAL] FATAL: lock file "postmaster.pid" already exists

Mark Dilger <markdilger@yahoo.com> writes:
> We only use one database, not counting the
> built-in template databases.  The server is
> running 9.1.3.  We were running 9.1.1 until
> fairly recently.

OK.  I had forgotten that in recent versions, RemovePgTempFiles doesn't
only iterate through the pgsql_tmp directories; it scans the regular
database directories too, looking for possibly orphaned temp relations.
So if you had lots and lots of files in your regular database
directories, possibly scanning those could be slow.  Still, it's only
looking at the file names, not attempting to stat() them or anything,
so it would be a pretty shoddy filesystem that would take a really long
time for that.

            regards, tom lane


pgsql-general by date:

Previous
From: Lonni J Friedman
Date:
Subject: Re: Re: significant performance hit whenever autovacuum runs after upgrading from 9.0 -> 9.1
Next
From: Andreas
Date:
Subject: pg_log is 2 hours ahead ???