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.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
