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

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: FATAL: lock file "postmaster.pid" already exists
Дата
Msg-id 1337813238.84595.YahooMailNeo@web39302.mail.mud.yahoo.com
обсуждение исходный текст
Ответ на Re: FATAL: lock file "postmaster.pid" already exists  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: FATAL: lock file "postmaster.pid" already exists  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: FATAL: lock file "postmaster.pid" already exists  (Magnus Hagander <magnus@hagander.net>)
Список 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 по дате отправления:

Предыдущее
От: Lonni J Friedman
Дата:
Сообщение: Re: Re: significant performance hit whenever autovacuum runs after upgrading from 9.0 -> 9.1
Следующее
От: Andreas
Дата:
Сообщение: pg_log is 2 hours ahead ???