Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions
Дата
Msg-id CANP8+j+56fcvkWbnERJug+cCb4VCwHwri=hu6TNQk08T-rX8AQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Список pgsql-hackers
On 23 January 2018 at 19:17, Petr Jelinek <petr.jelinek@2ndquadrant.com> wrote:

> I am not sure if this helps streaming use-case though as
> there is not going to be any external transaction management involved there.

So, I think we need some specific discussion of what to do in that case.

Streaming happens only with big transactions and only for short periods.

The problem only occurs when we are decoding and we hit a catalog
table change. Processing of that is short, then we continue. So it
seems perfectly fine to block aborts in those circumstances. We can
just mark that state in a in-memory array of
StreamingDecodedTransactions that has size SizeOf(TransactionId) *
MaxNumWalSenders.

We can add a check into RecordTransactionAbort() just before the
critical section to see if we are currently processing a
StreamingDecodedTransaction and if so, poll until we're OK to abort.
The check will be quick and the abort path is not considered one we
need to optimize.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: PATCH: Exclude unlogged tables from base backups
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: [HACKERS] Restricting maximum keep segments by repslots