On Mon, Oct 17, 2022 at 6:46 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
>
> At Sun, 16 Oct 2022 12:32:56 +0530, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote in
> > On Sat, Oct 15, 2022 at 4:58 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > > I spent some time today reading this. As others said upthread, the
> > > > output can be more verbose if all the backends are running max
> > > > subtransactions or subtransactions overflow occurred in all the
> > > > backends.
> > > >
> > >
> > > As far as I can understand, this contains subtransactions only when
> > > they didn't overflow. The latest information provided by Sawada-San
> > > for similar records (XLOG_STANDBY_LOCK and XLOG_INVALIDATIONS) made me
> > > think that maybe we are just over-worried about the worst case.
> >
> > Agreed. I see the below comment, which means when
> > xlrec->subxid_overflow is set to true, there will not be any
> > subtransaction ids logged in the WAL record.
>
> Since I categorized this tool as semi-debugging purpose so I'm fine
> that sometimes very long lines are seen. In the first place it is
> already seen in, for example, transaction commit records. They can be
> 30k characters long by many relfile locators, stats locators,
> invalidations and snapshots, when 100 relations are dropped.
>
> > If my above understanding is correct, having something like below does
> > no harm, like Masahiko-san's one of the initial patches, no? I'm also
> > fine with the way it is in the v3 patch.
>
> Yeah, v3 works exactly the same way with the initial patch, except
> when something bad happens in that record. So *I* thought that it's
> rather better that the tool describes records as-is (even if only for
> this record..:p) rather than how the broken records are recognized by
> the recovery code.
>
Okay, let's wait for two or three days and see if anyone thinks
differently, otherwise, I'll push v3 after a bit more testing.
--
With Regards,
Amit Kapila.
