pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18014: Releasing catcache entries makes schema_to_xmlschema() fail when parallel workers are used
Date: Fri, 21 Jul 2023 15:21:46 -0400
Message-ID: <982076.1689967306@sss.pgh.pa.us> (raw)
In-Reply-To: <00e24aa6-5d03-99b6-ab41-495a35fc93f6@gmail.com>
References: <b2dcd258-82f1-dfe3-498e-9f652a0c0c4b@gmail.com>
	<20230720.162802.905550494964943231.horikyota.ntt@gmail.com>
	<20230720.164459.2183367718473165651.horikyota.ntt@gmail.com>
	<20230720.172924.535889842187000361.horikyota.ntt@gmail.com>
	<1a2d5aba-df29-ab8d-65ac-6ffd54d1ac62@gmail.com>
	<969017.1689960055@sss.pgh.pa.us>
	<00e24aa6-5d03-99b6-ab41-495a35fc93f6@gmail.com>

Alexander Lakhin <exclusion@gmail.com> writes:
> 21.07.2023 20:20, Tom Lane wrote:
>> I like #2 better if it's not hard to do cleanly.  However, I'm not
>> quite sure how we are getting to an inval during relation close;
>> maybe that's not something we want to prevent.

> Yes, there is a detailed comment in LockRelationOid(), that explains why
> AcceptInvalidationMessages() is called. (I've tried to remove that call
> now, just for testing, and get 6 tests failed during `make check`.)

Yes, we certainly want to do that during LockRelationOid.  But what
seems to be happening here is an inval while we are closing/unlocking
the catalog we got the syscache entry from.  That is, the expected
behavior here is:

SearchSysCacheExists:

  * is entry present-and-valid?
    No, so...

  * open and lock relevant catalog (with possible inval)

  * scan catalog, find desired row, create valid syscache entry

  * close and unlock catalog

  * return success

SearchSysCache1 (from pg_class_aclmask_ext):

  * is entry present-and-valid?
    Yes, so increment its refcount and return it

There is no inval in the entry-already-present code path in syscache
lookup.  So if we are seeing this failure, ISTM it must mean that an
inval is happening during "close and unlock catalog", which seems like
something that we don't want.  But I've not traced exactly how that
happens.

			regards, tom lane





view thread (24+ messages)  latest in thread

Message-ID: <982076.1689967306@sss.pgh.pa.us>
Permalink:  ../982076.1689967306@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/982076.1689967306@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, exclusion@gmail.com, horikyota.ntt@gmail.com, pgsql-bugs@lists.postgresql.org
  Subject: Re: BUG #18014: Releasing catcache entries makes schema_to_xmlschema() fail when parallel workers are used
  In-Reply-To: <982076.1689967306@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox