On Fri, 2008-12-19 at 14:00 +0200, Heikki Linnakangas wrote:
> Heikki Linnakangas wrote:
> > Well, to be honest, I don't much like the whole notion of tracking the
> > slots. I think we should just rely on the XLOG_RECOVERY_END records to
> > purge stale PGPROC entries, belonging to backends that died without
> > writing an abort record.
>
> Sorry, I meant XLOG_XACT_RUNNING_XACTS, not XLOG_RECOVERY_END.
OK, previous response aborted, but the problem is fairly similar.
If we just assign a recovery proc to each new transaction started then
* we would need an expandable number of recovery procs to cope with the
fact that we have more potentially emulated transactions than procs.
This info needs to be in shared memory, so however many you allocate, it
can still run out. Then what do you do? PANIC recovery and permanently
fail? Kick off all queries until a XLOG_XACT_RUNNING_XACTS arrives?
* there would be no direct mapping between the commit record and the
proc, so each commit would need to scan the whole proc array to get the
correct proc (which is potentially getting bigger and bigger because of
the first point)
The slotid (or backendid) is essential to keeping the number of emulated
transactions bounded at all times. I don't see that it costs much, if
anything and the resulting code is at least as simple as the
alternatives.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support