Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"
Дата
Msg-id CA+hUKGJBrKENOmq6zHGMOh637cjHL6VeOc1NF98Vtq9c962oBA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"  ("Anton A. Melnikov" <aamelnikov@inbox.ru>)
Список pgsql-hackers
On Tue, Jan 31, 2023 at 5:09 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> Clearly there is an element of speculation or superstition here.  I
> don't know what else to do if both PostgreSQL and ext4 decided not to
> add interlocking.  Maybe we should rethink that.  How bad would it
> really be if control file access used POSIX file locking?  I mean, the
> writer is going to *fsync* the file, so it's not like one more wafer
> thin system call is going to hurt too much.

Here's an experimental patch for that alternative.  I wonder if
someone would want to be able to turn it off for some reason -- maybe
some NFS problem?  It's less back-patchable, but maybe more
principled?

I don't know if Windows suffers from this type of problem.
Unfortunately its equivalent functionality LockFile() looks non-ideal
for this purpose: if your program crashes, the documentation is very
vague on when exactly it is released by the OS, but it's not
immediately on process exit.  That seems non-ideal for a control file
you might want to access again very soon after a crash, to be able to
recover.

A thought in passing: if UpdateMinRecoveryPoint() performance is an
issue, maybe we should figure out how to use fdatasync() instead of
fsync().

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Logical replication timeout problem
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Logical replication timeout problem