> 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). Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
