From: | Christoph Berg <myon(at)debian(dot)org> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | PostgreSQL in Debian <pkg-postgresql-public(at)lists(dot)alioth(dot)debian(dot)org>, team(at)security(dot)debian(dot)org |
Subject: | fsync-pgdata-on-recovery tries to write to more files than previously |
Date: | 2015-05-23 17:26:27 |
Message-ID: | 20150523172627.GA24277@msg.df7cb.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)df7cb(dot)de | http://www.df7cb.de/
From | Date | Subject | |
---|---|---|---|
Next Message | Nils Goroll | 2015-05-23 17:26:48 | Re: xid wrap / optimize frozen tables? |
Previous Message | Tom Lane | 2015-05-23 16:32:34 | Re: Run pgindent now? |