From: Jan Wieck <jwieck@debis.com>
The diff looks so simple and easy. But to find it wasn't fun. It must have been there for a long time. What happened: When a tuple in one of some central catalogs was updated, the referenced relation got flushed, so it would be reopened on the next access (to reflect new triggers, rules and table structure changes into the relation cache). Some data (the tupleDescriptor e.g.) is used in the system cache too. So when a relation is subject to the system cache, this must know too that a cached system relation got flushed because the tupleDesc data gets freed during the flush! For the GRANT/REVOKE on pg_class it was slightly different. There is some local data in inval.c that gets initialized on the first invalidation of a tuple in some central catalogs. This needs a SysCache lookup in pg_class. But when the first of all commands is a GRANT on pg_class, exactly the needed tuple is the one actually invalidated. So I added little code snippets that the initialization of the local variables in inval.c will already happen during InitPostgres().
Showing
Please register or sign in to comment