Re: Detecting File Damage & Inconsistencies

On Fri, Jul 2, 2021 at 5:34 AM Craig Ringer
<craig(dot)ringer(at)enterprisedb(dot)com> wrote:
>
> On Fri, 2 Jul 2021 at 00:19, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> wrote:
>
>>
>> > So yeah. I think it'd be better to log the info you want at start-of-txn unless there's a compelling reason not so, and I don't see one yet.
>>
>> AFAIK, XLOG_XACT_ASSIGNMENT does not occur for normal top-level
>> transactions, only for subxids.
>>
>> I don't really want to add an extra record just for this because it
>> will slow down applications and it won't get turned on as often.
>
>
> OK, that makes sense - I was indeed operating on an incorrect assumption.
>
> I wouldn't want to add a new record either. I thought we could piggyback on XLOG_XACT_ASSIGNMENT with a new chunk that's only added when the feature is required, much like we do for replication origin info on commit records.
>
> Is it worth considering forcing XLOG_XACT_ASSIGNMENT to be logged if this feature is enabled?

My feeling is that the drop in performance would lead to it being
turned off most of the time, reducing the value of the feature.

Does anyone else disagree?

> 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.

--
Simon Riggs http://www.EnterpriseDB.com/