Hot Standby 0.2.1
in [PgSql]
|
From: Heikki Linnakangas on 25 Sep 2009 08:50 In XidInMVCCSnapshot: > if (snapshot->takenDuringRecovery) > { > /* > * If the snapshot contains full subxact data, the fastest way to check > * things is just to compare the given XID against both subxact XIDs and > * top-level XIDs. If the snapshot overflowed, we have to use pg_subtrans > * to convert a subxact XID to its parent XID, but then we need only look > * at top-level XIDs not subxacts. > */ .... > } > else > { > int32 j; > > /* > * > * In recovery we store all xids in the subxact array because this > * is by far the bigger array and we mostly don't know which xids > * are top-level and which are subxacts. The xip array is empty. > * > * We start by searching subtrans, if we overflowed. > */ .... > } Hang on, isn't this 180 degrees backwards? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 25 Sep 2009 13:25 On Fri, 2009-09-25 at 15:50 +0300, Heikki Linnakangas wrote: > Hang on, isn't this 180 degrees backwards? A witty riposte escapes me; yes, the if test is !correct. What I find amazing is that it passed the test where I put it doing make installcheck in an infinite loop for a long time. I guess that means the regression tests hardly touch the concurrency code at all, which now I think about it makes sense but I still find that very worrying. :-( -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 25 Sep 2009 16:30 Simon Riggs wrote: > What I find amazing is that it passed the test where I put it doing make > installcheck in an infinite loop for a long time. I guess that means the > regression tests hardly touch the concurrency code at all, which now I > think about it makes sense but I still find that very worrying. :-( Try installcheck-parallel, which should be a bit better. It's probably not yet good enough though because it always runs the same tests concurrently. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 25 Sep 2009 17:04 On Fri, 2009-09-25 at 16:30 -0400, Alvaro Herrera wrote: > Simon Riggs wrote: > > > What I find amazing is that it passed the test where I put it doing make > > installcheck in an infinite loop for a long time. I guess that means the > > regression tests hardly touch the concurrency code at all, which now I > > think about it makes sense but I still find that very worrying. :-( > > Try installcheck-parallel, which should be a bit better. It's probably > not yet good enough though because it always runs the same tests > concurrently. Good tip, thanks. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 25 Sep 2009 20:10
Alvaro Herrera wrote: > Simon Riggs wrote: > > >> What I find amazing is that it passed the test where I put it doing make >> installcheck in an infinite loop for a long time. I guess that means the >> regression tests hardly touch the concurrency code at all, which now I >> think about it makes sense but I still find that very worrying. :-( >> > > Try installcheck-parallel, which should be a bit better. It's probably > not yet good enough though because it always runs the same tests > concurrently. > > It is also quite easy to set up your own schedule. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |