From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hot standby, recovery procs |
Date: | 2009-02-24 20:52:39 |
Message-ID: | 1235508759.16176.252.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2009-02-24 at 21:59 +0200, Heikki Linnakangas wrote:
> > I think if I had not made those into procs you would have said that they
> > are so similar it would aid code readability to have them be the same.
>
> And in fact I suggested earlier that we get rid of the unobserved xids
> array, and only use recovery procs.
Last week, I think. Why are these tweaks so important?
Checking pg_subtrans for every call to XidInMVCCSnapshot will destroy
performance, as well you know.
> > What benefit would we gain from separating them, especially since we now
> > have working, tested code?
>
> Simplicity. That matters a lot. Removing the distinction between
> unobserved xids and already-observed running transactions would slash a
> lot of code.
It might and it might not, but I don't believe all angles have been
evaluated. But I would say that major changes such as this have resulted
in weeks of work. More bugs have been introduced since feature freeze
than were present beforehand.
If you want this code to fail, then twisting it in lots of directions
every week is exactly the way to do that. Neither of us will understand
how it works and we'll take more weeks for it to settle down to the
point of reviewability again. We don't have weeks any more.
So far I've made every change you've asked, but there is a reasonable
limit.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-02-24 21:35:30 | Re: GIN fast insert |
Previous Message | Heikki Linnakangas | 2009-02-24 20:29:04 | Re: Hot standby, recovery procs |