On 2014-10-14 17:53:10 -0400, Robert Haas wrote: > On Tue, Oct 14, 2014 at 4:42 PM, Andres Freund <and...@2ndquadrant.com> wrote: > >> The code in CHashSearch shows the problem there: you need to STORE the > >> hazard pointer before you begin to do the LOAD operations to scan the > >> bucket, and you must finish all of those LOADs before you STORE the > >> NULL hazard pointer. A read or write barrier won't provide store/load > >> or load/store ordering. > > > > I'm not sure I understand the problem here - but a read + write barrier > > should suffice? To avoid falling back to two full barriers, we'd need a > > separate define pg_read_write_barrier(), but that's not a problem. IIUC > > that should allow us to avoid emitting any actual code on x86. > > Well, thinking about x86 specifically, it definitely needs at least > one mfence, after setting the hazard pointer and before beginning to > read the bucket chain.
Yes, I can see that now. I do wonder if that's not going to prove quite expensive... I think I can see some ways around needing that. But I think that needs some benchmarking first - no need to build a even more complex solution if not needed. The solution I'm thinking of is to essentially move away from hazard pointers and store something like a generation counter per backend. Which is updated less often, and in combination with other operations. When a backend need to clean up and sees that there's a straggler with a old generation it sends that backend a signal to ensure it sets the latest generation. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
