Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-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

pgsql-hackers by date

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

pgsql-committers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group