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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
