patternsqlMinor
Is it safe to call pg_ctl reload while doing heavy writes?
Viewed 0 times
heavywriteswhilepg_ctlreloaddoingcallsafe
Problem
I am running Postgres 8.4, and I would like to change the authentication method for a user. It's my understanding that I have to do this in
However, I am also importing a ton of data from flat files using multiple processes.
Is it safe to do this?
pg_hba.conf, and then reload the configuration files with pg_ctl reload (or, in this case, service postgresql reload) for the settings to take effect.However, I am also importing a ton of data from flat files using multiple processes.
Is it safe to do this?
Solution
Yes, it is safe, at least on 9.2, and I'm not aware of any major changes in that regard since 8.4. If absolute certainty is required you should
In the following tests with Pg 9.3-pre, if PostgreSQL cannot re-read the config file due to a syntax error or other serious problem it'll skip the reload, eg:
If an individual parameter is invalid it'll apply the other changes but skip that param:
Even if you somehow managed to find a case where PostgreSQL would shut down or even crash, the worst that you'd have to do would be start it back up again and resume your writes from the last commited point. Not-yet-committed work is guaranteed to be rolled back and committed work is guaranteed to be applied to the database after disconnect, a database restart or even after a full system crash.
If your bulk writes don't periodically commit their work and write a local checkpoint, they probably should so you can resume them if they're interrupted. Reducing transaction lengths also makes some admin tasks easier and more efficient for the database.
initdb a test instance to experiment with before changing the production system.In the following tests with Pg 9.3-pre, if PostgreSQL cannot re-read the config file due to a syntax error or other serious problem it'll skip the reload, eg:
LOG: received SIGHUP, reloading configuration files
LOG: syntax error in file "..../postgresql.conf" line 215, near token "!"
LOG: configuration file "..../postgresql.conf" contains errors; no changes were appliedIf an individual parameter is invalid it'll apply the other changes but skip that param:
LOG: received SIGHUP, reloading configuration files
LOG: -10 is outside the valid range for parameter "vacuum_cost_delay" (0 .. 100)
LOG: configuration file "..../postgresql.conf" contains errors; unaffected changes were appliedEven if you somehow managed to find a case where PostgreSQL would shut down or even crash, the worst that you'd have to do would be start it back up again and resume your writes from the last commited point. Not-yet-committed work is guaranteed to be rolled back and committed work is guaranteed to be applied to the database after disconnect, a database restart or even after a full system crash.
If your bulk writes don't periodically commit their work and write a local checkpoint, they probably should so you can resume them if they're interrupted. Reducing transaction lengths also makes some admin tasks easier and more efficient for the database.
Code Snippets
LOG: received SIGHUP, reloading configuration files
LOG: syntax error in file "..../postgresql.conf" line 215, near token "!"
LOG: configuration file "..../postgresql.conf" contains errors; no changes were appliedLOG: received SIGHUP, reloading configuration files
LOG: -10 is outside the valid range for parameter "vacuum_cost_delay" (0 .. 100)
LOG: configuration file "..../postgresql.conf" contains errors; unaffected changes were appliedContext
StackExchange Database Administrators Q#41517, answer score: 6
Revisions (0)
No revisions yet.