> This is going to be a problem with any operation that does a transactional
> pg_class update without taking a lock that conflicts with ShareLock.
GRANT
> doesn't lock the table at all, so I can reproduce this in v17 as follows:
>
> == session 1
> create table t (c int);
> begin;
> grant select on t to public;
>
> == session 2
> alter table t add primary key (c);
>
> == back in session 1
> commit;
>
>
> We'll likely need to change how we maintain relhasindex or perhaps take a
lock
> in GRANT.
Oh, that explains it. Thank you very much.
> Can you explore that as follows?
>
>- PITR to just before the COMMIT record.
>- Save all rows of pg_class.
>- PITR to just after the COMMIT record.
>- Save all rows of pg_class.
>- Diff the two sets of saved rows.
Sure, but it will take some time, its a large db with lots of WAL segments
to apply.
> extensions
extname | extversion
--------------------+------------
plpgsql | 1.0
pg_stat_statements | 1.8
pg_buffercache | 1.3
pgstattuple | 1.5
