Hi,
On 4/5/23 8:59 AM, Amit Kapila wrote:
> On Mon, Apr 3, 2023 at 12:05 PM Amit Kapila <amit.kapila16@gmail.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