On Thu, 2010-02-04 at 13:02 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Wed, 2010-02-03 at 10:48 -0500, Tom Lane wrote:
> >>> If so, there is some minor code cleanup and comment changes in
> >>> ProcessCommittedInvalidationMessages(). Would you like me to do that, or
> >>> should we wait?
> >>
> >> I saw that. I didn't touch it because it's not directly relevant to
> >> what I'm doing right now, but I would like to go back and see whether
> >> that routine can't be got rid of completely. It seems to me to be a
> >> very klugy substitute for having enough information. I'm inclined to
> >> think that we should emit an sinval message (or maybe better a separate
> >> WAL entry) for initfile removal, instead of trying to reverse-engineer
> >> whether one happened.
>
> > An additional sinval message type would work. There is a requirement for
> > us to run RelationCacheInitFileInvalidate() both before and after the
> > other messages. So we would need to append and prepend the new message
> > type onto the array of messages if transInvalInfo->RelcacheInitFileInval
> > is true. That way we would just do SendSharedInvalidMessages() in
> > xact_redo_commit and remove ProcessCommittedInvalidationMessages(),
> > adding other code to handle the inval message. Doesn't seem any easier
> > though.
>
> > Another WAL record would definitely be cumbersome.
>
> BTW, we're definitely going to have to do *something* with that code,
> because it's assuming that non-shared relcache init files always live in
> DEFAULTTABLESPACE. That is not correct.
Oh dear.
> I think that there is no
> simple way for the startup process to identify which tablespace a given
> database lives in (normally, one would have to consult pg_database to
> find that out). So we are going to have to drive this off an sinval or
> WAL record that does provide the tablespace as well as the DB OID.
Seems OK to just add the tablespace to the sinval.
-- Simon Riggs www.2ndQuadrant.com
