Re: Support for pg_receivexlog --post-segment command

From: Feike Steenbergen <feikesteenbergen(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, David Steele <david(at)pgmasters(dot)net>
Subject: Re: Support for pg_receivexlog --post-segment command
Date: 2017-01-06 13:09:48
Message-ID: CAK_s-G3z=2X80w7h9JYdRZm2xA=ZkrN82HdGjc+d9zQMbAZvOQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6 January 2017 at 13:50, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> I think we're better off clearly documenting that we don't care about it.
And basically let the external command be responsible for that part.

> So for example, your typical backup manager would listen to this signal
or whatever to react quickly. But it would *also* have some sort of
fallback. For example, whenever it's triggered it also checks if there are
any previous segments it missed (this would also cover the startup
sequence).

For me this works fine. I just want to ensure that if there is any work to
be done, my backup manager will do the work quickly. My implementation
might be very simply a process that checks every n seconds or when
signalled.

> Since we never actually remove anything (unlike archive_command which has
the integration with wal segment rotation), I think this can be done
perfectly safe.
>
> Looking at the usecases where you have been doing it, are there any where
this would not work?

This would work for all usecases I've come across.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Sharma 2017-01-06 13:28:01 Re: Add pgstathashindex() to get hash index table statistics.
Previous Message Etsuro Fujita 2017-01-06 13:01:04 Re: postgres_fdw bug in 9.6