On Thu, 2009-02-26 at 12:19 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2009-02-26 at 11:36 +0200, Heikki Linnakangas wrote:
> >
> >>> You haven't even given a good reason to make these changes.
> >> Simplicity.
> >
> > You used that argument in January to explain why the c
Simon Riggs wrote:
On Thu, 2009-02-26 at 11:36 +0200, Heikki Linnakangas wrote:
You haven't even given a good reason to make these changes.
Simplicity.
You used that argument in January to explain why the coupling should be
reduced and now the same argument to put it back again.
That was i
On Thu, 2009-02-26 at 11:36 +0200, Heikki Linnakangas wrote:
> > You haven't even given a good reason to make these changes.
>
> Simplicity.
You used that argument in January to explain why the coupling should be
reduced and now the same argument to put it back again.
> > We don't have time to
Simon Riggs wrote:
On Thu, 2009-02-26 at 10:04 +0200, Heikki Linnakangas wrote:
we keep track of which xids
have already been "reported" in the WAL (similar to what you had in an
earlier version of the patch)
You objected to doing exactly that earlier.
I'm talking about the "xidMarkedInWAL
On Thu, 2009-02-26 at 10:04 +0200, Heikki Linnakangas wrote:
> we keep track of which xids
> have already been "reported" in the WAL (similar to what you had in an
> earlier version of the patch)
You objected to doing exactly that earlier. Why is it OK to do it now
that you are proposing it?
Y
Simon Riggs wrote:
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
Simon Riggs wrote:
On Tue, 2009-02-24 at 21:59 +0200, Heikki Linnakangas wrote:
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 trans
On Tue, 2009-02-24 at 23:41 +, Simon Riggs wrote:
> On Tue, 2009-02-24 at 22:29 +0200, Heikki Linnakangas wrote:
> > overwrites subxids array, and will resurrect any already aborted
> > subtransaction.
> >
> > Isn't XLByteLT(proc->lsn, lsn) always true, because 'lsn' is the lsn of
> > the
On Tue, 2009-02-24 at 22:29 +0200, Heikki Linnakangas wrote:
> Oh, right... But we have the same problem with the subtransactions,
> don't we? This block:
>
> > /*
> > * If our state information is later for this proc, then
> > * overwrite it. It's possibl
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
Simon Riggs wrote:
On Tue, 2009-02-24 at 21:59 +0200, Heikki Linnakangas wrote:
We only need the lsn atrribute because we when we take the snapshot
of
running xids, we don't write it to the WAL immediately, and a new
transaction might begin after that. If we close that gap in the
master,
we d
On Tue, 2009-02-24 at 21:59 +0200, Heikki Linnakangas wrote:
> We only need the lsn atrribute because we when we take the snapshot
> of
> running xids, we don't write it to the WAL immediately, and a new
> transaction might begin after that. If we close that gap in the
> master,
> we don't need
Simon Riggs wrote:
On Tue, 2009-02-24 at 10:40 +0200, Heikki Linnakangas wrote:
(back to reviewing the main hot standby patch at last)
Why do we need recovery procs? AFAICS the only fields that we use are
xid and the subxid cache. Now that we also have the unobserved xids
array, why don't we us
On Tue, 2009-02-24 at 10:40 +0200, Heikki Linnakangas wrote:
> (back to reviewing the main hot standby patch at last)
>
> Why do we need recovery procs? AFAICS the only fields that we use are
> xid and the subxid cache. Now that we also have the unobserved xids
> array, why don't we use it to tra
14 matches
Mail list logo
