Re: ENOSPC FailedAssertion("!(RefCountErrors == 0)"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ENOSPC FailedAssertion("!(RefCountErrors == 0)"
Date: 2018-07-18 18:05:17
Message-ID: 7342.1531937117@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jul 18, 2018 at 10:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-07-18 18:27:48 Re: Subplan result caching
Previous Message Marco van Eck 2018-07-18 17:46:26 Have an encrypted pgpass file