fsync-pgdata-on-recovery tries to write to more files than previously

Поиск
Список
Период
Сортировка
От Christoph Berg
Тема fsync-pgdata-on-recovery tries to write to more files than previously
Дата
Msg-id 20150523172627.GA24277@msg.df7cb.de
обсуждение исходный текст
Ответы Re: fsync-pgdata-on-recovery tries to write to more files than previously  (Christoph Berg <myon@debian.org>)
Re: fsync-pgdata-on-recovery tries to write to more files than previously  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

the new fsync-pgdata-on-recovery code tries to open all files using
O_RDWR. At least on 9.1, this can make recovery fail:

* launch postgres, hit ^\ (or otherwise shut down uncleanly)
* touch foo; chmod 444 foo
* launch postgres

LOG:  database system was interrupted; last known up at 2015-05-23 19:18:36 CEST
FATAL:  could not open file "/home/cbe/9.1/foo": Permission denied
LOG:  startup process (PID 27305) exited with exit code 1
LOG:  aborting startup due to startup process failure

The code on 9.4 looks similar to me, but I couldn't trigger the
problem there.

I think this is a real-world problem:

1) In older releases, the SSL certs were read from the data directory,
and at least the default Debian installation creates symlinks from
PGDATA/server.* to /etc/ssl/ where PostgreSQL can't write

2) It's probably a pretty common scenario that the root user will edit
postgresql.conf, and make backups or create other random files there
that are not writable. Even a non-writable postgresql.conf itself or
recovery.conf was not a problem previously.

To me, this is a serious regression because it prevents automatic
startup of a server that would otherwise just run.

Christoph
--
cb@df7cb.de | http://www.df7cb.de/

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Run pgindent now?
Следующее
От: Nils Goroll
Дата:
Сообщение: Re: xid wrap / optimize frozen tables?