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

From Craig Ringer
Subject Re: Detecting File Damage & Inconsistencies
Date
Msg-id CAGRY4nyf3Rd2V9xqcMvMyH=uTJAJW9-pkpk0Q_9xu9vvm43eqw@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
List pgsql-hackers
On Fri, 2 Jul 2021 at 00:19, Simon Riggs <simon.riggs@enterprisedb.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?

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.

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Can a child process detect postmaster death when in pg_usleep?
Next
From: "tanghy.fnst@fujitsu.com"
Date:
Subject: RE: Added schema level support for publication.