2011/1/19 Robert Haas <robertmh...@gmail.com>: > On Wed, Jan 19, 2011 at 11:52 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Robert Haas <robertmh...@gmail.com> writes: >>> ... So what we >>> want to do is write a percentage of them, in a way that guarantees >>> that they'll all eventually get written if people continue to access >>> the same data. >> >> The word "guarantee" seems quite inappropriate here, since as far as I >> can see this approach provides no such guarantee --- even after many >> cycles you'd never be really certain all the bits were set. >> >> What I asked for upthread was that we continue to have some >> deterministic, practical way to force all hint bits in a table to be >> set. This is not *remotely* responding to that request. It's still not >> deterministic, and even if it were, vacuuming a large table 20 times >> isn't a very practical solution. > > I get the impression you haven't spent as much time reading my email > as I spent writing it. Perhaps I'm wrong, but in any case the code > doesn't do what you're suggesting. In the most recently posted > version of this patch, which is v2, if VACUUM hits a page that is
Please update the commitfest with the accurate patch, there is only the old immature v1 of the patch in it. I was about reviewing it... https://commitfest.postgresql.org/action/patch_view?id=500 > hint-bit-dirty, it always writes it. Full stop. The "20 times" bit > applies to a SELECT * FROM table, which is a rather different case. > > As I write this, I realize that there is a small fly in the ointment > here, which is that neither VACUUM nor SELECT force out all the pages > they modify to disk. So there is some small amount of remaining > nondeterminism, even if you VACUUM, because VACUUM will leave the last > few pages it dirties in shared_buffers, and whether those hint bits > hit the disk will depend on a decision made at the time they're > evicted, not at the time they were dirtied. Possibly I could fix that > by making SetBufferCommitInfoNeedsSave() set BM_DIRTY during vacuum > and BM_HINT_BITS at other times. That would nail the lid shut pretty > tight. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
