| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Euler Taveira <euler(at)eulerto(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com> |
| Subject: | Re: 040_pg_createsubscriber.pl is slow and unstable (was Re: speed up a logical replica setup) |
| Date: | 2024-07-30 04:26:31 |
| Message-ID: | 2946218.1722313591@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> On Tue, Jul 30, 2024 at 1:48 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> If the problem can be correctly described as "pg_createsubscriber
>> takes 10 seconds or so to detect end-of-stream",
> The problem can be defined as: "pg_createsubscriber waits for an
> additional (new) WAL record to be generated on primary before it
> considers the standby is ready for becoming a subscriber". Now, on
> busy systems, this shouldn't be a problem but for idle systems, the
> time to detect end-of-stream can't be easily defined.
Got it. IMO, that absolutely will be a problem for real users,
not only test cases.
> One of the proposed solutions is that pg_createsubscriber generate a
> dummy WAL record on the publisher/primary by using something like
> pg_logical_emit_message(), pg_log_standby_snapshot(), etc. This will
> fix the problem (BF failures and slow detection for end-of-stream) but
> sounds more like a hack.
It's undoubtedly a hack, but I like it anyway because it's small,
self-contained, and easily removable once we have a better solution.
As you say, it seems a bit late in the v17 cycle to be designing
anything more invasive.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2024-07-30 04:46:54 | Re: 040_pg_createsubscriber.pl is slow and unstable (was Re: speed up a logical replica setup) |
| Previous Message | shveta malik | 2024-07-30 04:19:41 | Re: Conflict Detection and Resolution |