Re: [HACKERS] [COMMITTERS] pgsql: Do a pass of code review for the ALTER TABLE
I'm keeping on studying multixact.c and log management, and I hope you can help me, as usual, in clearing my doubts.My doubts now concern MultixactID wrap-around management. Afaics, it is possible to spawn multixactids so quickly to have a wrap-around and to start overwriting the data stored in the offset slru (but analogous considerations apply to the member slru as well). This would cause corruption, if the overwritten info was still needed, e.g., by a (very) long-running transaction. This is of course very unlikely in practice, but yet still possible in theory.In GetNewMultiXactId() wrap-around of MultiXactId seems to be simply handled this way: 00780 _/* Handle wraparound of the nextMXact counter */00781 if (MultiXactState->nextMXact < FirstMultiXactId)00782 MultiXactState->nextMXact = FirstMultiXactId; I cannot see how this may avoid possible overwriting of still needed data. To address such an issue shouldn't one need to check against OldestMemberMXactId, OldestVisibleMXactId? Or, alternatively, rely on an approach similar to the one taken to handle standard XID generation (xidWarnLimit, see GetNewTransactionId)?Is it me who's missing something or is it just that such a case has been considered so unlikely not to motivate additional overheads/checks?Thanks in advance! Paolo Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
Re: [HACKERS] [COMMITTERS] pgsql: Do a pass of code review for the ALTER TABLE
Bruce Momjian wrote: > Neil Conway wrote: > > Log Message: > > --- > > Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep > > the read lock we hold on the table's parent relation until commit. > > Update equalfuncs.c for the new field in AlterTableCmd. Various > > improvements to comments, variable names, and error reporting. > > > > There is room for further improvement here, but this is at least > > a step in the right direction. > > Thanks, that is what was needed. The author obviously took the patch as > far as he could, and we needed to adjust his XXX areas, rather than not > apply the patch and have the code drifting. Hmm, is this how we should do things? I mean, should I finish the autovacuum parts of my relminxid patch, apply it, and then hope for someone to fix the mistaeks? And if we don't see any failure in the buildfarm, assume that all is well? To me this is really the easiest way, but I have a hard time convincing myself that I want to have it easy but break things in a way that nobody notices. The other day when I typoed a commit to the 8.1 branch I was all red in the face. I wonder what will happen if someone points to me or Greg as causing major breakage somewhere, just because the patch was applied in a hurry without careful review. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Do a pass of code review for the ALTER TABLE
Neil Conway wrote: > Log Message: > --- > Do a pass of code review for the ALTER TABLE ADD INHERITS patch. Keep > the read lock we hold on the table's parent relation until commit. > Update equalfuncs.c for the new field in AlterTableCmd. Various > improvements to comments, variable names, and error reporting. > > There is room for further improvement here, but this is at least > a step in the right direction. Thanks, that is what was needed. The author obviously took the patch as far as he could, and we needed to adjust his XXX areas, rather than not apply the patch and have the code drifting. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org