| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Subject: | Re: Do we need so many hint bits? |
| Date: | 2012-11-17 21:53:31 |
| Message-ID: | 14867.1353189211@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> What's the problem with that? If you already have the VM buffer pinned
> (which should be possible if we keep the VM buffer in a longer-lived
> structure), then doing the test is almost as cheap as checking
> PD_ALL_VISIBLE, because you don't need any locks.
Really? What about race conditions? Specifically, I think what you
suggest is likely to be unreliable on machines with weak memory
ordering. Consider possibility that someone else just changed the VM
bit. Getting a lock ensures synchronization. (Yeah, it's possible that
we could use some primitive cheaper than a lock ... but it's not going
to be free.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-11-17 21:57:49 | Re: Proposal for Allow postgresql.conf values to be changed via SQL |
| Previous Message | Fujii Masao | 2012-11-17 21:38:03 | Re: Proposal for Allow postgresql.conf values to be changed via SQL |