Re: Re: [COMMITTERS] pgsql: Assorted cleanups in preparation for using a map file to support

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [COMMITTERS] pgsql: Assorted cleanups in preparation for using a map file to support
Date: 2010-02-04 18:21:24
Message-ID: 1265307684.4660.1420.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Thu, 2010-02-04 at 13:02 -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message User Sas 2010-02-04 19:26:54 slony1-ctl - slony-ctl: Per Richard Yen: "We need an extra sync event
Previous Message Tom Lane 2010-02-04 18:02:13 Re: Re: [COMMITTERS] pgsql: Assorted cleanups in preparation for using a map file to support

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2010-02-04 18:22:23 Re: testing cvs HEAD - HS/SR - cannot stat
Previous Message Tom Lane 2010-02-04 18:02:13 Re: Re: [COMMITTERS] pgsql: Assorted cleanups in preparation for using a map file to support