Re: Replication slot stats misgivings - Mailing list pgsql-hackers

From vignesh C
Subject Re: Replication slot stats misgivings
Date
Msg-id CALDaNm2NMbwUXqUErrUDGiY=r1bRfZV=gjUgAN5efXuUD5jvMA@mail.gmail.com
Whole thread Raw
In response to Re: Replication slot stats misgivings  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Thu, Apr 29, 2021 at 11:14 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Thu, Apr 29, 2021 at 11:55 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Thu, Apr 29, 2021 at 4:58 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > >
> > > On Thu, Apr 29, 2021 at 5:41 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > >
> > > > It seems that the test case added by f5fc2f5b2 is still a bit
> > > > unstable, even after c64dcc7fe:
> > >
> > > Hmm, I don't see the exact cause yet but there are two possibilities:
> > > some transactions were really spilled,
> > >
> >
> > This is the first test and inserts just one small record, so how it
> > can lead to spill of data. Do you mean to say that may be some
> > background process has written some transaction which leads to a spill
> > of data?
>
> Not sure but I thought that the logical decoding started to decodes
> from a relatively old point for some reason and decoded incomplete
> transactions that weren’t shown in the result.
>
> >
> > > and it showed the old stats due
> > > to losing the drop (and create) slot messages.
> > >
> >
> > Yeah, something like this could happen. Another possibility here could
> > be that before the stats collector has processed drop and create
> > messages, we have enquired about the stats which lead to it giving us
> > the old stats. Note, that we don't wait for 'drop' or 'create' message
> > to be delivered. So, there is a possibility of the same. What do you
> > think?
>
> Yeah, that could happen even if any message didn't get dropped.
>
> >
> > > For the former case, it
> > > seems to better to create the slot just before the insertion and
> > > setting logical_decoding_work_mem to the default (64MB). For the
> > > latter case, maybe we can use a different name slot than the name used
> > > in other tests?
> > >
> >
> > How about doing both of the above suggestions? Alternatively, we can
> > wait for both 'drop' and 'create' message to be delivered but that
> > might be overkill.
>
> Agreed. Attached the patch doing both things.

Having a different slot name should solve the problem. The patch looks
good to me.

Regards,
Vignesh



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] Identify LWLocks in tracepoints
Next
From: Peter Smith
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions