Re: ENOSPC FailedAssertion("!(RefCountErrors == 0)" - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ENOSPC FailedAssertion("!(RefCountErrors == 0)"
Date
Msg-id 7342.1531937117@sss.pgh.pa.us
Whole thread Raw
In response to Re: ENOSPC FailedAssertion("!(RefCountErrors == 0)"  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jul 18, 2018 at 10:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> So couldn't we use TopTransactionResourceOwner instead of
>>> AuxProcessResrouceOwner? I feel a bit uneasy that bootstrap and
>>> standalone-backend have *AuxProcess*ResourceOwner.

>> Since the aux processes aren't running transactions, I didn't think
>> that TopTransactionResourceOwner was appropriate.  There's also
>> a problem for bootstrap and standalone backend cases: those do run
>> transactions and therefore create/destroy TopTransactionResourceOwner,
>> leaving nothing behind for ShutdownXLOG to use if it tries to use
>> that.  We need an extra resowner somewhere.

> FallbackResourceOwner?  DefaultResourceOwner? SessionResourceOwner?

Those names all suggest (to me anyway) that this resowner exists in
all, or at least most, processes.  That's not the situation as of this
patch, although I could imagine an alternate universe where it's true;
for example, if we decided there were a reason for normal backends to
have a session-lifespan resowner.  But even then, it might be better
to distinguish that from aux processes' use of resowners.

(I'm not really convinced that it'd be a good idea for normal backends
to have a session-lifespan resowner; that could mask bugs involving
trying to acquire resources outside a transaction.)

            regards, tom lane


pgsql-hackers by date:

Previous
From: Marco van Eck
Date:
Subject: Have an encrypted pgpass file
Next
From: Robert Haas
Date:
Subject: Re: Subplan result caching