From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Florent Guiliani <florent(at)guiliani(dot)fr> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Retrieve the snapshot's LSN |
Date: | 2015-07-17 16:53:07 |
Message-ID: | CA+TgmoZkGbgcu18vr4ewx6L9n8Nfe89GADc2W7kwhdWa8YRh=g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 17, 2015 at 8:31 AM, Florent Guiliani <florent(at)guiliani(dot)fr> wrote:
> A pg_export_snapshot_for_slot(...) would work very well.
>
> Let me explain the use case. You have many downstream systems that are
> replicated with logical decoding. Using a dedicated replication slot
> for each target is not practical. A single logical replication slot is
> configured. It generates a stream of LSN-stamped transactions in
> commit order. Those transactions are published to all downstream
> nodes.
>
> The snapshot exported during the slot creation can be used to generate
> a complete dump that the replicated systems will load before applying
> the transaction stream.
>
> How do you individually reload/recover one of the downstream node? You
> can use the initial dump and reapply all transactions emitted since
> the slot's inception. It will quickly become impractical. What you
> need is to generate a newer dump and only apply the transactions from
> that point.
I'd like to point out that I told Andres repeatedly during the
development of logical decoding that this exact thing was going to be
a problem. He told me fixing it was way too complicated, but I hope
he'll relent, because I still think this is important.
(Not trying to be a jerk here.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-07-17 16:56:29 | Re: option for psql - short list non template database |
Previous Message | Robert Haas | 2015-07-17 16:50:17 | Re: Transactions involving multiple postgres foreign servers |