Re: [PoC] pg_upgrade: allow to upgrade publisher node

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, 'Julien Rouhaud' <rjuju123(at)gmail(dot)com>
Cc: 'vignesh C' <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re: [PoC] pg_upgrade: allow to upgrade publisher node
Date: 2023-04-26 07:18:33
Message-ID: f9210a4c-0001-9aa1-aece-d30663206c85@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 24.04.23 14:03, Hayato Kuroda (Fujitsu) wrote:
>> so at least there's a good chance that they will still be at
>> shutdown, and will therefore send all the data to the subscribers? Having a
>> regression tests for that scenario would also be a good idea. Having an
>> uncommitted write transaction should be enough to cover it.
>
> I think background_psql() can be used for the purpose. Before doing pg_upgrade
> --check, a transaction is opened and kept. It means that the confirmed_flush has
> been not reached to the current WAL position yet, but the checking says OK
> because all slots are active.

A suggestion: You could write some/most tests against test_decoding
rather than the publication/subscription system. That way, you can
avoid many timing issues in the tests and you can check more exactly
that the slots produce the output you want. This would also help ensure
that this new facility works for other logical decoding output plugins
besides the built-in one.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2023-04-26 07:38:40 Re: run pgindent on a regular basis / scripted manner
Previous Message John Naylor 2023-04-26 07:16:28 Re: Overhauling "Routine Vacuuming" docs, particularly its handling of freezing