On Mon, Oct 17, 2022 at 6:46 AM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > > At Sun, 16 Oct 2022 12:32:56 +0530, Bharath Rupireddy > <bharath.rupireddyforpostg...@gmail.com> wrote in > > On Sat, Oct 15, 2022 at 4:58 PM Amit Kapila <amit.kapil...@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.