Re: Detecting File Damage & Inconsistencies
| От | Craig Ringer |
|---|---|
| Тема | Re: Detecting File Damage & Inconsistencies |
| Дата | |
| Msg-id | CAGRY4nyf3Rd2V9xqcMvMyH=uTJAJW9-pkpk0Q_9xu9vvm43eqw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Detecting File Damage & Inconsistencies (Simon Riggs <simon.riggs@enterprisedb.com>) |
| Ответы |
Re: Detecting File Damage & Inconsistencies
|
| Список | 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 по дате отправления: