Re: Restore CurrentUserId only if 'prevUser' is valid when abort transaction

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Richard Guo <riguo(at)pivotal(dot)io>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Restore CurrentUserId only if 'prevUser' is valid when abort transaction
Date: 2018-11-13 01:17:29
Message-ID: 14335.1542071849@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> So, I have spent a couple of hours today looking a bit more at the
> problem, and I have hacked the attached patch that I am pretty happy
> with:

I don't like this too much, because it does not scale: there can be
only one action that can rely on executing "just before we switch to
TRANS_INPROGRESS".

I think the real bug here is that a bunch of potentially-failable
operations have been thrown in before we've finished initializing the
TransactionState to minimal sanity. (Inserting code with the aid of a
dartboard seems to be a chronic disease around here :-(.) Since
GetUserIdAndSecContext is *not* an operation that can fail, there's
no reason why we need to expend a lot of effort on the possibility that
it hasn't happened. What we ought to do is move that and the rest of the
"initialize current transaction state fields" stanza up to before we start
doing things like calling RecoveryInProgress(). And put in a comment to
clearly mark where we first allow failure to occur.

I'd be strongly inclined to change the elog(WARNING) at line 1815
to an assertion, because calling elog exposes us to all kinds of
hazards that we don't need here.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2018-11-13 01:34:50 Re: move PartitionBoundInfo creation code
Previous Message Pavel Stehule 2018-11-13 01:16:36 Re: [HACKERS] Decimal64 and Decimal128