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