Message-ID: <d882d134-6a7a-4e92-ba65-174feb3f19f6@enterprisedb.com>
Date: Tue, 11 Jun 2024 15:42:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: confirmed flush lsn seems to be move backward in certain error
 cases
To: Amit Kapila <amit.kapila16@gmail.com>, vignesh C <vignesh21@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <CALDaNm3hgow2+oEov5jBk4iYP5eQrUCF1yZtW7+dV3J__p4KLQ@mail.gmail.com>
 <CAA4eK1KqYQHA67bhUJLJx1GOCcJHm=rgLU4OSKb-ft2hq40FSA@mail.gmail.com>
 <CALDaNm1Z+o99eyv1pvMHF2rHQX8Kgcox9asDnGDTuxFJ0G4z5w@mail.gmail.com>
 <CAA4eK1+2cACaeEw7pDQs6eH8nRCiDw+temUv0fUe=JXJGaAXzQ@mail.gmail.com>
 <CALDaNm0LLLvBjDK4z71kC8bonpq2xz=JODO6Lrek3Yqvu-KVKQ@mail.gmail.com>
 <CAA4eK1+_d564ap4JrZ2dRO9tk7DyGFMDC48+dTWvguTrRqwBNA@mail.gmail.com>
Content-Language: en-US
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: <CAA4eK1+_d564ap4JrZ2dRO9tk7DyGFMDC48+dTWvguTrRqwBNA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/d882d134-6a7a-4e92-ba65-174feb3f19f6%40enterprisedb.com>
Precedence: bulk

Hi,

On 6/11/24 10:39, Amit Kapila wrote:
> On Mon, Jun 10, 2024 at 7:24 PM vignesh C <vignesh21@gmail.com> wrote:
>>
>> I have re-verified  the issue by running the tests in a loop of 150
>> times and found it to be working fine. Also patch applies neatly,
>> there was no pgindent issue and all the regression/tap tests run were
>> successful.
>>
> 
> Thanks, I have pushed the fix.
> 

Sorry for not responding to this thread earlier (two conferences in two
weeks), but isn't the pushed fix addressing a symptom instead of the
actual root cause?

Why should it be OK for the subscriber to confirm a flush LSN and then
later take that back and report a lower LSN? Seems somewhat against my
understanding of what "flush LSN" means.

The commit message explains this happens when the subscriber does not
need to do anything for - but then why shouldn't it just report the
prior LSN, in such cases?

I haven't looked into the details, but my concern is this removes an
useful assert, protecting us against certain type of bugs. And now we'll
just happily ignore them. Is that a good idea?


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company