Thread: pgsql: Assorted cleanups in preparation for using a map file to support
pgsql: Assorted cleanups in preparation for using a map file to support
From
tgl@postgresql.org (Tom Lane)
Date:
Log Message:
-----------
Assorted cleanups in preparation for using a map file to support altering
the relfilenode of currently-not-relocatable system catalogs.
1. Get rid of inval.c's dependency on relfilenode, by not having it emit
smgr invalidations as a result of relcache flushes. Instead, smgr sinval
messages are sent directly from smgr.c when an actual relation delete or
truncate is done. This makes considerably more structural sense and allows
elimination of a large number of useless smgr inval messages that were
formerly sent even in cases where nothing was changing at the
physical-relation level. Note that this reintroduces the concept of
nontransactional inval messages, but that's okay --- because the messages
are sent by smgr.c, they will be sent in Hot Standby slaves, just from a
lower logical level than before.
2. Move setNewRelfilenode out of catalog/index.c, where it never logically
belonged, into relcache.c; which is a somewhat debatable choice as well but
better than before. (I considered catalog/storage.c, but that seemed too
low level.) Rename to RelationSetNewRelfilenode.
3. Cosmetic cleanups of some other relfilenode manipulations.
Modified Files:
--------------
pgsql/src/backend/catalog:
heap.c (r1.368 -> r1.369)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/heap.c?r1=1.368&r2=1.369)
index.c (r1.331 -> r1.332)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/index.c?r1=1.331&r2=1.332)
toasting.c (r1.28 -> r1.29)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/toasting.c?r1=1.28&r2=1.29)
pgsql/src/backend/commands:
tablecmds.c (r1.321 -> r1.322)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/tablecmds.c?r1=1.321&r2=1.322)
pgsql/src/backend/storage/smgr:
smgr.c (r1.118 -> r1.119)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/smgr/smgr.c?r1=1.118&r2=1.119)
pgsql/src/backend/utils/cache:
inval.c (r1.92 -> r1.93)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/cache/inval.c?r1=1.92&r2=1.93)
relcache.c (r1.300 -> r1.301)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/cache/relcache.c?r1=1.300&r2=1.301)
pgsql/src/include/catalog:
index.h (r1.80 -> r1.81)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/index.h?r1=1.80&r2=1.81)
pgsql/src/include/utils:
inval.h (r1.46 -> r1.47)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/inval.h?r1=1.46&r2=1.47)
relcache.h (r1.66 -> r1.67)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/relcache.h?r1=1.66&r2=1.67)
On Wed, 2010-02-03 at 01:14 +0000, Tom Lane wrote: > 1. Get rid of inval.c's dependency on relfilenode, by not having it emit > smgr invalidations as a result of relcache flushes. Instead, smgr sinval > messages are sent directly from smgr.c when an actual relation delete or > truncate is done. This makes considerably more structural sense and allows > elimination of a large number of useless smgr inval messages that were > formerly sent even in cases where nothing was changing at the > physical-relation level. Note that this reintroduces the concept of > nontransactional inval messages, but that's okay --- because the messages > are sent by smgr.c, they will be sent in Hot Standby slaves, just from a > lower logical level than before. Presumably this means that SHAREDINVALSMGR_ID messages are no longer part of the invalidation messages attached to a commit record? If so, there is some minor code cleanup and comment changes in ProcessCommittedInvalidationMessages(). Would you like me to do that, or should we wait? -- Simon Riggs www.2ndQuadrant.com