Обсуждение: archive_command during database shutdown
I've recently wanted to run a different archive_command during database shutdown than during normal operations. In particular, if the normal archive process fails during normal operations, I want it to be retried later (as it currently does). But if it fails during shutdown, I want it to run a fallback archive_command. The only way I can see to accomplish this is to have the archive_command try to connect back to the database and see if it gets an error. That seems pretty ugly. Is there a better way? Cheers, Jeff
On Thu, 26 May 2016, 1:25 a.m. Jeff Janes, <jeff.janes@gmail.com> wrote:
I've recently wanted to run a different archive_command during
database shutdown than during normal operations. In particular, if
the normal archive process fails during normal operations, I want it
to be retried later (as it currently does). But if it fails during
shutdown, I want it to run a fallback archive_command.
What version of PostgreSQL are you using?
The only way I can see to accomplish this is to have the
archive_command try to connect back to the database and see if it gets
an error. That seems pretty ugly. Is there a better way?
What's your goal here?
During a shutdown, if you don't so much care about checkpoint and fsync of buffers to disk, you can do an immediate shutdown.
Cheers,
Jeff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
--
--
Best Regards
Sameer Kumar | DB Solution Architect
ASHNIK PTE. LTD.
101 Cecil Street, #11-11 Tong Eng Building, Singapore 069 533
T: +65 6438 3504 | M: +65 8110 0350 | www.ashnik.com
On Wed, May 25, 2016 at 10:31 AM, Sameer Kumar <sameer.kumar@ashnik.com> wrote: > > > On Thu, 26 May 2016, 1:25 a.m. Jeff Janes, <jeff.janes@gmail.com> wrote: >> >> I've recently wanted to run a different archive_command during >> database shutdown than during normal operations. In particular, if >> the normal archive process fails during normal operations, I want it >> to be retried later (as it currently does). But if it fails during >> shutdown, I want it to run a fallback archive_command. > > > What version of PostgreSQL are you using? 9.2, 9.4, 9.5, 9.6beta. > >> >> The only way I can see to accomplish this is to have the >> archive_command try to connect back to the database and see if it gets >> an error. That seems pretty ugly. Is there a better way? > > > What's your goal here? I want my database to shut down cleanly when I tell it to. > > During a shutdown, if you don't so much care about checkpoint and fsync of > buffers to disk, you can do an immediate shutdown. But I do care about the checkpoint. Otherwise you lose all your unlogged tables. And probably other unfortunate things happen, as well. Cheers, Jeff
On 25/05/16 20:57, Jeff Janes wrote: > On Wed, May 25, 2016 at 10:31 AM, Sameer Kumar <sameer.kumar@ashnik.com> wrote: >> >> >> On Thu, 26 May 2016, 1:25 a.m. Jeff Janes, <jeff.janes@gmail.com> wrote: >>> >>> I've recently wanted to run a different archive_command during >>> database shutdown than during normal operations. In particular, if >>> the normal archive process fails during normal operations, I want it >>> to be retried later (as it currently does). But if it fails during >>> shutdown, I want it to run a fallback archive_command. >> >> >> What version of PostgreSQL are you using? > > 9.2, 9.4, 9.5, 9.6beta. > >> >>> >>> The only way I can see to accomplish this is to have the >>> archive_command try to connect back to the database and see if it gets >>> an error. That seems pretty ugly. Is there a better way? >> >> >> What's your goal here? > > I want my database to shut down cleanly when I tell it to. > >> >> During a shutdown, if you don't so much care about checkpoint and fsync of >> buffers to disk, you can do an immediate shutdown. > > But I do care about the checkpoint. Otherwise you lose all your > unlogged tables. And probably other unfortunate things happen, as Isn't that the point of unlogged tables? Or rather, isn't that the risk you knowingly take with them - you trade reliability for speed? Ray
On Wed, May 25, 2016 at 1:36 PM, Raymond O'Donnell <rod@iol.ie> wrote: > On 25/05/16 20:57, Jeff Janes wrote: >> >> On Wed, May 25, 2016 at 10:31 AM, Sameer Kumar <sameer.kumar@ashnik.com> >> wrote: >>> >>> >>> >>> On Thu, 26 May 2016, 1:25 a.m. Jeff Janes, <jeff.janes@gmail.com> wrote: >>>> >>>> >>>> I've recently wanted to run a different archive_command during >>>> database shutdown than during normal operations. In particular, if >>>> the normal archive process fails during normal operations, I want it >>>> to be retried later (as it currently does). But if it fails during >>>> shutdown, I want it to run a fallback archive_command. >>> >>> >>> >>> What version of PostgreSQL are you using? >> >> >> 9.2, 9.4, 9.5, 9.6beta. >> >>> >>>> >>>> The only way I can see to accomplish this is to have the >>>> archive_command try to connect back to the database and see if it gets >>>> an error. That seems pretty ugly. Is there a better way? >>> >>> >>> >>> What's your goal here? >> >> >> I want my database to shut down cleanly when I tell it to. >> >>> >>> During a shutdown, if you don't so much care about checkpoint and fsync >>> of >>> buffers to disk, you can do an immediate shutdown. >> >> >> But I do care about the checkpoint. Otherwise you lose all your >> unlogged tables. And probably other unfortunate things happen, as > > > Isn't that the point of unlogged tables? Or rather, isn't that the risk you > knowingly take with them - you trade reliability for speed? Sure. And I have rebuilt them. But when the firemen pack up and leave, I've got better things to be doing with my time (and limited IO capacity on a half crippled system) than rebuilding unlogged tables for no particular reason. The purpose of the database is to be a tool, not a moral scold. But now I think the problem is not when the archive_command fails, but when it hangs and never returns at all. That means the solution has to look somewhat different, but I still don't know exactly what. Cheers, Jeff