Thread: [ADMIN] Immediate Shutdowns
Greetings,
Are there long-term detriments from executing an immediate shutdown and/or issuing SIGQUITs to either the parent or any child postmaster? I'm aware that PostgreSQL, upon next start, performs a WAL replay and performs other crash recovery steps. Are there certain operations, such as VACUUM ANALYZEs, CREATE INDEXs, INSERTs, UPDATEs, and/or DELETEs, for example, that are less easily recovered or less recoverable than other operations?
Are there long-term detriments from executing an immediate shutdown and/or issuing SIGQUITs to either the parent or any child postmaster? I'm aware that PostgreSQL, upon next start, performs a WAL replay and performs other crash recovery steps. Are there certain operations, such as VACUUM ANALYZEs, CREATE INDEXs, INSERTs, UPDATEs, and/or DELETEs, for example, that are less easily recovered or less recoverable than other operations?
What might cause an operation, such as a VACUUM ANALYZE, not to exit upon receiving a SIGTERM. Are there any circumstances when a SIGQUIT could fail to cause an imminent exit (other than a process in an fundamentally unreceptive state, such as an uninterruptible sleep).
Harold Falkmeyer
On 6/6/17 22:56, Harold Falkmeyer wrote: > Are there long-term detriments from executing an immediate shutdown > and/or issuing SIGQUITs to either the parent or any child postmaster? There shouldn't be any. > What might cause an operation, such as a VACUUM ANALYZE, not to exit > upon receiving a SIGTERM. Are there any circumstances when a SIGQUIT > could fail to cause an imminent exit (other than a process in an > fundamentally unreceptive state, such as an uninterruptible sleep). You write in another thread that you are using 8.4. That could certainly have more issues/bugs in this area, if you're not seeing the behavior you want. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services