On 8 May 2012 22:35, Tom Lane <t...@sss.pgh.pa.us> wrote: > Now that I've actually read the patch, rather than just responding to > your description of it, I find myself entirely unhappy with the proposed > changes in the walwriter's sleep logic. You have introduced race > conditions (it is NOT okay to reset the latch somewhere below the top of > the loop)
Yes, there is some checking of flags before the potential ResetLatch() call, which may be acted on. The code there is almost identical to that of the extant bgwriter code. I was under the impression that this did not amount to a race, though it's rather late now, and I'm feeling under the weather, so I have not taken steps to verify that I have it right. Arguably, you'd want somebody's SetLatch call to be ignored if > and degraded the walwriter's signal response time in normal > non-hibernation state, to solve a problem not in evidence; to wit that > backends spend too much time signaling the walwriter. Given the > location of the only existing SetLatch call for the purpose, I find that > proposition more than a bit doubtful. I do too. The elaborate logic to reduce that overhead was nothing more than a vestige of the first version. I apologise for making such a basic error. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
