Re: Detecting File Damage & Inconsistencies - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Detecting File Damage & Inconsistencies
Date
Msg-id CAA4eK1+w8QDoLg=SOGDv0+L=w_WNdCAxKHup4G8HYQdk5yX8Dg@mail.gmail.com
Whole thread Raw
In response to Re: Detecting File Damage & Inconsistencies  (Simon Riggs <simon.riggs@enterprisedb.com>)
Responses Re: Detecting File Damage & Inconsistencies  (Simon Riggs <simon.riggs@enterprisedb.com>)
List pgsql-hackers
On Fri, Jul 2, 2021 at 8:29 PM Simon Riggs <simon.riggs@enterprisedb.com> wrote:
>
> On Fri, Jul 2, 2021 at 5:34 AM Craig Ringer
> <craig.ringer@enterprisedb.com> wrote:
> >
>
> > If you don't think the sorts of use cases I presented are worth the trouble that's fair enough. I'm not against
addingit on the commit record. It's just that with logical decoding moving toward a streaming model I suspect only
havingit at commit time may cause us some pain later. 
>
> I think you have some good ideas about how to handle larger
> transactions with streaming. As a separate patch it might be worth
> keeping track of transaction size and logging something when a
> transaction gets too large.
>

If we want this additional information for streaming mode in logical
replication then can't we piggyback it on the very first record
written for a transaction when this info is required? Currently, we do
something similar for logging top_level_xid for subtransaction in
XLogRecordAssemble().


--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Re: parallel distinct union and aggregate support patch
Next
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Parallel INSERT SELECT take 2