Re: Minimal logical decoding on standbys

Hi,

On 4/5/23 8:59 AM, Amit Kapila wrote:
> On Mon, Apr 3, 2023 at 12:05 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:

> On further thinking, as such this shouldn't be a problem because all
> the WAL records before PARAMETER_CHANGE record will have sufficient
> information so that they can get decoded. However, with the current
> approach, the subscriber may not even receive the valid records before
> PARAMETER_CHANGE record. This is because startup process will
> terminate the walsenders while invaliding the slots and after restart
> the walsenders will exit because the corresponding slot will be an
> invalid slot. So, it is quite possible that walsender was lagging and
> wouldn't have sent records before the PARAMETER_CHANGE record making
> subscriber never receive those records that it should have received.

Agree that would behave that way.

> I don't know whether this is what one would expect.

If one change wal_level to < logical on the primary, he should at least
know that:

"
Existing
+ logical slots on standby also get invalidated if wal_level on primary is reduced to
+ less than 'logical'.
"

If the doc has been read (as the quote above is coming from 0006).

I think that what is missing is the "when" the slots are invalidated.

Maybe we could change the doc with something among those lines instead?

"
Existing logical slots on standby also get invalidated if wal_level on primary is reduced to
less than 'logical'. This is done as soon as the standby detects such a change in the WAL stream.

It means, that for walsenders that are lagging (if any), some WAL records up to the parameter change on the
primary won't be decoded".

I don't know whether this is what one would expect but that should be less of a surprise if documented.

What do you think?

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com