Re: [HACKERS] logical decoding of two-phase transactions

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Ajin Cherian <itsajin(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Date: 2021-02-27 02:01:21
Message-ID: CAHut+PvzZg03Dx=SgOf3kdODsNGgov=gWDD1oPYBw46W-rJdQw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 26, 2021 at 9:58 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> 6.
> + * XXX - Is there a potential timing problem here - e.g. if signal arrives
> + * while executing this then maybe we will set table_states_valid without
> + * refetching them?
> + */
> +static void
> +FetchTableStates(bool *started_tx)
> ..
>
> Can you explain which race condition you are worried about here which
> is not possible earlier but can happen after this patch?
>

Yes, my question (in that XXX comment) was not about anything new for
the current patch, because this FetchTableStates function has exactly
the same logic as the HEAD code.

I was only wondering if there is any possibility that one of the
function calls (inside the if block) can end up calling
CHECK_INTERRUPTS. If that could happen, then perhaps the
table_states_valid flag could be assigned false (by the
invalidate_syncing_table_states signal handler) only to be
immediately/wrongly overwritten as table_states_valid = true in this
FetchTableStates code.

------
Kind Regards,
Peter Smith.
Fujitsu Australia

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2021-02-27 02:14:18 Re: [HACKERS] Custom compression methods
Previous Message Thomas Munro 2021-02-27 01:48:25 Re: Reducing WaitEventSet syscall churn