On Tue, Jun 11, 2024 at 7:12 PM Tomas Vondra
wrote:
>
> 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
> l
Tomas Vondra writes:
> 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 any
Hi,
On 6/11/24 10:39, Amit Kapila wrote:
> On Mon, Jun 10, 2024 at 7:24 PM vignesh C 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 test
On Mon, Jun 10, 2024 at 7:24 PM vignesh C 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 pushe
On Mon, 10 Jun 2024 at 16:38, Amit Kapila wrote:
>
> On Tue, Feb 20, 2024 at 12:35 PM vignesh C wrote:
> >
> > On Sat, 17 Feb 2024 at 12:03, Amit Kapila wrote:
> > >
> > >
> > > @@ -1839,7 +1839,8 @@ LogicalConfirmReceivedLocation(XLogRecPtr lsn)
> > >
> > > SpinLockAcquire(&MyReplicationSlot-
On Mon, 10 Jun 2024 at 16:39, Amit Kapila wrote:
>
> On Tue, Feb 20, 2024 at 12:35 PM vignesh C wrote:
> >
> > On Sat, 17 Feb 2024 at 12:03, Amit Kapila wrote:
> > >
> > >
> > > @@ -1839,7 +1839,8 @@ LogicalConfirmReceivedLocation(XLogRecPtr lsn)
> > >
> > > SpinLockAcquire(&MyReplicationSlot-
On Tue, Feb 20, 2024 at 12:35 PM vignesh C wrote:
>
> On Sat, 17 Feb 2024 at 12:03, Amit Kapila wrote:
> >
> >
> > @@ -1839,7 +1839,8 @@ LogicalConfirmReceivedLocation(XLogRecPtr lsn)
> >
> > SpinLockAcquire(&MyReplicationSlot->mutex);
> >
> > - MyReplicationSlot->data.confirmed_flush = lsn;
>
On Fri, 16 Feb 2024 at 17:39, vignesh C wrote:
>
> Hi,
>
> The following assertion failure was seen while testing one scenario
> for other patch:
> TRAP: failed Assert("s->data.confirmed_flush >=
> s->last_saved_confirmed_flush"), File: "slot.c", Line: 1760, PID:
> 545314
> postgres: checkpointer
On Sat, 17 Feb 2024 at 12:03, Amit Kapila wrote:
>
> On Fri, Feb 16, 2024 at 5:53 PM vignesh C wrote:
> >
> >
> > After the insert operation is replicated to the subscriber, the
> > subscriber will set the lsn value sent by the publisher in the
> > replication origin (in my case it was 0/1510978)
On Fri, Feb 16, 2024 at 5:53 PM vignesh C wrote:
>
>
> After the insert operation is replicated to the subscriber, the
> subscriber will set the lsn value sent by the publisher in the
> replication origin (in my case it was 0/1510978). publisher will then
> send keepalive messages with the current
Hi,
The following assertion failure was seen while testing one scenario
for other patch:
TRAP: failed Assert("s->data.confirmed_flush >=
s->last_saved_confirmed_flush"), File: "slot.c", Line: 1760, PID:
545314
postgres: checkpointer performing shutdown
checkpoint(ExceptionalCondition+0xbb)[0x564ee
11 matches
Mail list logo
