RE: Potential data loss due to race condition during logical replication slot creation

Поиск
Список
Период
Сортировка
От Hayato Kuroda (Fujitsu)
Тема RE: Potential data loss due to race condition during logical replication slot creation
Дата
Msg-id TYCPR01MB120774D17B90FFDAC087B959FF52C2@TYCPR01MB12077.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Potential data loss due to race condition during logical replication slot creation  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Potential data loss due to race condition during logical replication slot creation  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-bugs
Dear Amit,

> I feel setting "needs_full_snapshot" to true for decoding means the
> snapshot will start tracking non-catalog committed xacts as well which
> is costly.

I think the approach was most conservative one which does not have to change
the version of the snapshot. However, I understood that you wanted to consider
the optimized solution for HEAD first.

> See SnapBuildCommitTxn(). Can we avoid this problem if we
> would have list of all running xacts when we serialize the snapshot by
> not decoding any xact whose xid lies in that list? If so, one idea to
> achieve could be that we maintain the highest_running_xid while
> serailizing the snapshot and then during restore if that
> highest_running_xid is <= builder->initial_xmin_horizon, then we
> ignore restoring the snapshot. We already have few such cases handled
> in SnapBuildRestore().

Based on the idea, I made a prototype. It can pass tests added by others and me.
How do other think?

Best Regards,
Hayato Kuroda
FUJITSU LIMITED
https://www.fujitsu.com/ 



Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #18399: Query plan optimization results in runtime error when hoisting cast from inside subquery
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Potential data loss due to race condition during logical replication slot creation