Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions
Date
Msg-id CANP8+j+56fcvkWbnERJug+cCb4VCwHwri=hu6TNQk08T-rX8AQ@mail.gmail.com
Whole thread Raw
In response to Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List 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 by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: PATCH: Exclude unlogged tables from base backups
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] Restricting maximum keep segments by repslots