| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Synchronizing slots from primary to standby |
| Date: | 2022-02-11 14:28:19 |
| Message-ID: | 2d67fe58-b3b5-ab9e-e417-23752733cdb6@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 05.02.22 20:59, Andres Freund wrote:
> On 2022-01-03 14:46:52 +0100, Peter Eisentraut wrote:
>> From ec00dc6ab8bafefc00e9b1c78ac9348b643b8a87 Mon Sep 17 00:00:00 2001
>> From: Peter Eisentraut<peter(at)eisentraut(dot)org>
>> Date: Mon, 3 Jan 2022 14:43:36 +0100
>> Subject: [PATCH v3] Synchronize logical replication slots from primary to
>> standby
> I've just skimmed the patch and the related threads. As far as I can tell this
> cannot be safely used without the conflict handling in [1], is that correct?
This or similar questions have been asked a few times about this or
similar patches, but they always come with some doubt. If we think so,
it would be useful perhaps if we could come up with test cases that
would demonstrate why that other patch/feature is necessary. (I'm not
questioning it personally, I'm just throwing out ideas here.)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-02-11 14:59:55 | Re: pgsql: Add TAP test to automate the equivalent of check_guc |
| Previous Message | Yura Sokolov | 2022-02-11 14:26:37 | Re: Accommodate startup process in a separate ProcState array slot instead of in MaxBackends slots. |