From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
Cc: | Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>, David Steele <david(at)pgmasters(dot)net>, cleyssondba(at)gmail(dot)com, "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Detecting File Damage & Inconsistencies |
Date: | 2021-07-06 03:21:20 |
Message-ID: | CAA4eK1+w8QDoLg=SOGDv0+L=w_WNdCAxKHup4G8HYQdk5yX8Dg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 2, 2021 at 8:29 PM Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> wrote:
>
> On Fri, Jul 2, 2021 at 5:34 AM Craig Ringer
> <craig(dot)ringer(at)enterprisedb(dot)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 adding it on the commit record. It's just that with logical decoding moving toward a streaming model I suspect only having it 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.
From | Date | Subject | |
---|---|---|---|
Next Message | houzj.fnst@fujitsu.com | 2021-07-06 03:42:28 | RE: Parallel INSERT SELECT take 2 |
Previous Message | David Rowley | 2021-07-06 02:48:47 | Re: Re: parallel distinct union and aggregate support patch |