Add a hint when postgresql.conf hot_standby = 'off' and recovery.conf standby = 'on'
If you do the following sequence, the server gives the least helpful error message:
----
initdb data
pg_ctl -D data -l logfile start
# The following reconfigs are obvious based on error message if you try to take a base backup
echo 'local replication all trust’ >> data/pg_hba.conf
sed -i 's/#wal_level = minimal/wal_level = hot_standby/' data/postgresql.conf
sed -i 's/#max_wal_senders = 0/max_wal_senders = 5/' data/postgresql.conf
# Backup and start
pg_basebackup -D data_5434 -R
pg_ctl -D data_5434 -l logfile_5434 -o ‘-p 5434’ start
# Attempt psql
psql -p 5434
psql: FATAL: the database system is starting up
----
It doesn’t matter what log level you put the server log in either, it providers no additional helpful information.
The problem of course is that:
postgresql.conf: hot_standby = ‘off'
recovery.conf: standby = ‘on'
Why anybody in practice would want hot_standby off while in standby mode eludes me, but these are our default values (recovery.conf was generated by pg_basebackup -R).
It seems worth adding a hint and/or changing the error message to be more descriptive when in this state. Any options about what should be logged before I start putting together a patch?
- Matt K
On 05/22/2015 06:53 AM, Matthew Kelly wrote:
Why anybody in practice would want hot_standby off while in standby
mode eludes me, but these are our default values (recovery.conf was
generated by pg_basebackup -R).
That's how you set up a cold standby system.
It seems worth adding a hint and/or changing the error message to be
more descriptive when in this state. Any options about what should
be logged before I start putting together a patch?
Yeah, might be worthwhile. Perhaps:
FATAL: the database system is in standby mode and hot_standby is not
enabled
Or just:
FATAL: the database system is in cold standby mode
It would be useful to distinguish that state, where you could connect if
hot standby was enabled, from the state where it's starting up and
hasn't reached min-recovery-point yet and you couldn't connect even if
hot_standby was enabled. Not sure how much signalling you'd need between
postmaster and the startup process for that.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, May 22, 2015 at 4:22 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 05/22/2015 06:53 AM, Matthew Kelly wrote:
Why anybody in practice would want hot_standby off while in standby
mode eludes me, but these are our default values (recovery.conf was
generated by pg_basebackup -R).That's how you set up a cold standby system.
It seems worth adding a hint and/or changing the error message to be
more descriptive when in this state. Any options about what should
be logged before I start putting together a patch?Yeah, might be worthwhile. Perhaps:
FATAL: the database system is in standby mode and hot_standby is not
enabled
Since we may connect to the server even during an archive recovery (e.g.,
recovery_target_action = pause case), this message should be changed
as follows?
FATAL: the database system is in standby or archive recovery mode and
hot_standby is not enabled
Or just:
FATAL: the database system is in cold standby mode
It would be useful to distinguish that state, where you could connect if hot
standby was enabled, from the state where it's starting up and hasn't
reached min-recovery-point yet and you couldn't connect even if hot_standby
was enabled. Not sure how much signalling you'd need between postmaster and
the startup process for that.
Probably we need to make the startup process send the SIGUSR1 signal to
postmaster when it reaches the consistent point even if hot_standby is not
enabled.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas <hlinnaka@iki.fi> writes:
On 05/22/2015 06:53 AM, Matthew Kelly wrote:
It seems worth adding a hint and/or changing the error message to be
more descriptive when in this state. Any options about what should
be logged before I start putting together a patch?
Yeah, might be worthwhile. Perhaps:
FATAL: the database system is in standby mode and hot_standby is not
enabled
Or just:
FATAL: the database system is in cold standby mode
It would be useful to distinguish that state, where you could connect if
hot standby was enabled, from the state where it's starting up and
hasn't reached min-recovery-point yet and you couldn't connect even if
hot_standby was enabled. Not sure how much signalling you'd need between
postmaster and the startup process for that.
Another angle worth considering is whether PQping can or should
distinguish this state from "database is fully up". (I do not
recall what it does right now.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 05/22/2015 12:22 AM, Heikki Linnakangas wrote:
It seems worth adding a hint and/or changing the error message to be
more descriptive when in this state. Any options about what should
be logged before I start putting together a patch?Yeah, might be worthwhile. Perhaps:
FATAL: the database system is in standby mode and hot_standby is not
enabledOr just:
FATAL: the database system is in cold standby mode
Warm Standby is what we called it in the past, so I think we should be
consistent. Otherwise +1.
The additional benefit of this is that it would (hopefully) allow us to
distinguish between a warm standby which was still reading its own xlogs
(i.e. in crash recovery) and a warm standby which was using the
restore_command (i.e. standby-ing). For that reason, it would be ideal
if the new message only displayed once the restore_command starts being
used.
That is:
Cold Standby == DB Snapshot and a huge folder of WAL files (i.e. Barman)
Warm Standby == hot_standby=off, recoveryconf.standby=on
Hot Standby == hot_standby=on, recoveryconf.standby=on
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WM0ecaaad71893ca6257ebafcabf41624985493774f7f66a53c0baef6dc30cf4c0fd7e3f91d254d2b6b12a54dd1c6c7c46@asav-1.01.com
On 05/22/2015 11:01 AM, Josh Berkus wrote:
On 05/22/2015 12:22 AM, Heikki Linnakangas wrote:
It seems worth adding a hint and/or changing the error message to be
more descriptive when in this state. Any options about what should
be logged before I start putting together a patch?Yeah, might be worthwhile. Perhaps:
FATAL: the database system is in standby mode and hot_standby is not
enabledOr just:
FATAL: the database system is in cold standby mode
Warm Standby is what we called it in the past, so I think we should be
consistent. Otherwise +1.
As I recall, warm standby is actually what it is. A cold standby is not
applying logs. A warm standby is. So if there is a recovery.conf and
more importantly PostgreSQL is running, it is going to be a warm standby
not a cold.
Other than that, absolute +1.
JD
--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers