From: Tom Lane <tgl@sss.pgh.pa.us>
To: Семёнов Михаил <m7onov@yandex.ru>
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Function modification visibility in parallel connection
Date: Tue, 27 Sep 2022 19:24:44 -0400
Message-ID: <3854487.1664321084@sss.pgh.pa.us> (raw)
In-Reply-To: <1205251664297977@mail.yandex.ru>
References: <1205251664297977@mail.yandex.ru>
=?utf-8?B?0KHQtdC80ZHQvdC+0LIg0JzQuNGF0LDQuNC7?= <m7onov@yandex.ru> writes:
> [ squishy behavior with function redefinitions ]
Yeah, if you just do "select foo(...);" over and over within an open
transaction, we won't notice any concurrent redefinitions of foo(),
because AcceptInvalidationMessages never gets called. To a first
approximation, there are two cases where we call
AcceptInvalidationMessages:
1. StartTransaction.
2. When opening (acquiring some lock on) a relation.
(I'm oversimplifying, but that will do for this discussion.) As long as
you don't submit a query that references a table, nor one that provokes
any new catalog fetch, no AcceptInvalidationMessages happens ... at least
not till some other session decides we're clogging the sinval queue
and pokes us with a catchup interrupt.
Given that it's been like this since roughly the late bronze age
with few complaints, there's a reasonable argument for doing nothing.
However, it's hard to deny that this isn't pretty inconsistent.
A "bulletproof" fix would involve adding the same amount of locking
overhead for functions as we have for tables; which has been discussed
but I think nobody wants to go there. Functions are basically defined
by just one catalog entry, so they don't have anywhere near the hazard
of seeing a partially-inconsistent definition as we'd have with tables
if we weren't paranoid about locks.
I wonder though if it could make sense to add AcceptInvalidationMessages
to what StartTransactionCommand() does in the INPROGRESS cases. That
would seem to bring things to parity with what happens for statements
that aren't inside a transaction block, and the overhead wouldn't be
very high (I think).
I notice that pgstat_init_function_usage recently grew some very
grotty hacking including its own AcceptInvalidationMessages call [1].
I wonder if it'd be acceptable to drop that if we added this.
It's not like that code is entirely race-condition-free anyway,
and we'd get away from the semantic inconsistency complained of
in its comments.
regards, tom lane
[1] https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=5891c7a8ed8
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, m7onov@yandex.ru, andres@anarazel.de, pgsql-bugs@lists.postgresql.org
Subject: Re: Function modification visibility in parallel connection
In-Reply-To: <3854487.1664321084@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