Re: [HACKERS] Re: [COMMITTERS] pgsql: Assorted cleanups in preparation for using a map file to support
On Thu, 2010-02-04 at 13:02 -0500, Tom Lane wrote: > Simon Riggs 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Assorted cleanups in preparation for using a map file to support
Simon Riggs 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. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [COMMITTERS] pgsql: Assorted cleanups in preparation for using a map file to support
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. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
