On Thu, 2009-01-08 at 20:30 +0200, Heikki Linnakangas wrote:
> I've mentioned before that I don't like the slotid stuff. From an
> architectural point of view, we should try to keep the extra
> communication between primary and standby to a minimum, for the sake of
> robustness. The primary shouldn't have such a big role in keeping track
> of which xids it has already emitted in WAL records, which subxids have
> been marked, and so on.
>
> Since I've been whining about that for some time, I figured I have to
> put my money where my mouth is
Yes, you do, but I think not like this. Turning up with a patch and
saying "my way is better" but not actually saying what that way *is*
just confuses things.
If you want to do things a different way you need to say what you want
to do and what effects those changes will have. Are there tradeoffs? If
so what are they? ISTM easier to discuss them on list first than to
write a load of code and ask us all to read, understand and comment.
> , so here's a patch based on v6a that
> eliminates the concept of slotids, as well as the new xl_info2 field in
> XLogRecord. This seems much simpler to me. I haven't given it much
> testing, but seems to work. There's a whole bunch of comments marked
> with XXX that need resolving, though.
>
> Attached is a patch agains CVS HEAD (hs-noslotid-1.patch) as well as an
> incremental patch against your v6a (hs-noslotid-against-v6a.patch).
> Sorry if you were just working on some big changes and I joggled your
> elbow. I also didn't check what changes you had in v7 yet.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
