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.
Removing slotid does improve the code, I agree. It was never there for
reasons other than the functions and features it provides.
Effects of removing slotid are at least these
* if FATAL errors occur, yet we have long running transactions then we
have no way of removing those entries from the recovery procs. Since we
have a fixed pool of recovery transactions we won't have anywhere to
store that data. Snapshot sizes are fixed maximum with max_connections,
so eventually we would not be able to take a snapshot at all, and we'd
need to have a "ERROR: unable to take valid snapshot".
* if FATAL errors occur while holding AccessExclusiveLock then we have
no way of releasing those locks until the recovery proc is stale, which
might be some time. Not sure if your patch releases those?
* xid->proc lookup is now very slow and needs to be called more
frequently; will still be slower even with the further optimisations you
mention. Possibly a minor point with right tuning.
* slotid removed from xlrec header; makes no difference with 64-bit
systems because of alignment issues.
...perhaps more, not sure yet.
All we need to do is decide if we want these things or not. If not, then
we can remove the slotid stuff.
If it wasn't clear before, this was, for me, never a discussion about a
particular way of coding things. I care little for that and would
probably go with your suggestions more often than not. It's just simply
about what we want it to do. If you want to argue in favour of
restrictions to make things simpler, that's OK and I could probably live
with them quite happily myself. I'm trying to implement the project
philosophy of It Just Works, no restrictions or caveats - and I know if
I had not then the patch would have been rejected on that basis, as has
happened many times before.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
