| From: | Zeugswetter Andreas OSB sIT <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: lazy_truncate_heap() |
| Date: | 2009-01-05 17:24:51 |
| Message-ID: | 6DAFE8F5425AB84DB3FCA4537D829A561CEA8AA752@M0164.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2009-01-05 17:40:36 | Re: QuickLZ compression algorithm (Re: Inclusion in the PostgreSQL backend for toasting rows) |
| Previous Message | Tom Lane | 2009-01-05 16:55:46 | Re: pg_dump roles support |