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
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 |
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 |