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