Re: [PATCH] Avoid open and lock the table Extendend Statistics (src/backend/commands/statscmds.c)

Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
> On 2/13/22 22:43, Andres Freund wrote:
>> Having looked briefly at it, I don't understand what the locking scheme is?

> I don't recall the details of the discussion (if at all), but if you try
> to do concurrent ALTER STATISTICS, that'll end up with:
> ERROR: tuple concurrently updated
> reported by CatalogTupleUpdate. AFAIK that's what we do for other object
> types that don't have a relation that we might lock (e.g. try to co
> CREATE OR REPLACE FUNCTION).

Yeah, we generally haven't bothered with a separate locking scheme
for objects other than relations. I don't see any big problem with
that for objects that are defined by a single catalog entry, since
"tuple concurrently updated" failures serve fine (although maybe
that error message could be nicer). Extended stats don't quite
fit that definition, but at least for updates that only need to
touch the pg_statistic_ext row, it's the same story.

When we get around to supporting multi-relation statistics,
there might need to be some protocol around when ANALYZE can
update pg_statistic_ext_data rows. But I don't think that
issue exists yet, since only one ANALYZE can run on a particular
relation at a time.

regards, tom lane