Re: Re: [COMMITTERS] pgsql: Assorted cleanups in preparation for using a map file to support
От | Simon Riggs |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Assorted cleanups in preparation for using a map file to support |
Дата | |
Msg-id | 1265307684.4660.1420.camel@ebony обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Assorted cleanups in preparation for using a map file to support (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: