Re: lazy_truncate_heap()
От | Simon Riggs |
---|---|
Тема | Re: lazy_truncate_heap() |
Дата | |
Msg-id | 1231179702.4032.403.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: lazy_truncate_heap() (Zeugswetter Andreas OSB sIT <Andreas.Zeugswetter@s-itsolutions.at>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: