On Mon, 2009-01-05 at 18:24 +0100, Zeugswetter Andreas OSB sIT wrote:
> > Logically, "xmin horizon" conflicts could be flexible/soft.
> > That is, if we implemented the idea to store a lastCleanedLSN for each buffer then
> > "xmin horizon" conflicts would be able to continue executing until they
> > see a buffer with buffer.lastCleanedLSN > conflictLSN.
>
> I think the trouble is, that HOT can put extremely recent lastCleanedLSN's on pages.
> It would need some knobs to avoid this, that most likely reduce efficiency of HOT.
>
> What about using the page LSN after max_standby_delay ?
> Using the page LSN cancels queries earlier than the lastCleanedLSN,
> but probably in many cases later than an immediate cancel after max_standby_delay.
> Of course that only helps when reading static parts of tables :-(
>
> Instead of a cancel message, the replay would need to send (set in shmem) the first
> LSN applied after max_standby_delay to the relevant backend for it's LSN checks
> (if buffer.LSN >= received_max_delay_lsn cancel).
I like your train of thought there: If HOT is the problem then
lastCleanedLSN approx= LSN on HOT blocks, so having lastCleanedLSN
doesn't help much.
OK, so I'll skip that idea and go with what you suggest.
Design:
When conflict occurs we set a RecoveryConflictLSN on the Proc of the
backend to be cancelled. Every time we read a block in recovery we check
MyProc.RecoveryConflictLSN against the LSN on the block and backend will
commit suicide (ERROR) if block LSN is equal or greater.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
