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

From: Mark Dilger <markdilger(at)yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: deepak <deepak(dot)pn(at)gmail(dot)com>, Alban Hertroys <haramrae(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: FATAL: lock file "postmaster.pid" already exists
Date: 2012-05-23 22:47:18
Message-ID: 1337813238.84595.YahooMailNeo@web39302.mail.mud.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Dilger <markdilger(at)yahoo(dot)com>
Cc: deepak <deepak(dot)pn(at)gmail(dot)com>; Alban Hertroys <haramrae(at)gmail(dot)com>; "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Sent: Wednesday, May 23, 2012 1:54 PM
Subject: Re: [GENERAL] FATAL: lock file "postmaster.pid" already exists

Mark Dilger <markdilger(at)yahoo(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Andreas 2012-05-23 23:11:48 pg_log is 2 hours ahead ???
Previous Message Lonni J Friedman 2012-05-23 22:33:36 Re: Re: significant performance hit whenever autovacuum runs after upgrading from 9.0 -> 9.1