I'd like to propose the attached patch, which initializes each PGPROC's myProcLocks just once at postmaster startup, rather than every time the PGPROC is handed out to a backend. These lists should always be emptied before a backend shuts down, so a newly initialized backend will find the lists empty anyway. Not reinitializing them shaves a few cycles. In my testing, it saves about 1% of the cost of setting up and tearing down a connection, which is not a ton, but a cycle saved is a cycle earned.
Of course, we have a few outstanding reports, like this one from Dave Gould, indicating that maybe we have a bug in there somewhere: http://archives.postgresql.org/message-id/20110822073131.gc3...@sonic.net ...but in that case it seems to me that this doesn't make anything worse than it already is. If the myProcLocks pointers are pointing to random garbage, we're just kidding ourselves whatever we do; the system is screwed, and we ought to PANIC, and anything we do here is laughably inadequate. OTOH, if it just so happens that a backend found a sneaky way through the exit path that doesn't involve calling LockReleaseAll(), then overwriting the shm queue pointers removes our last hope that the next backend can clean up the mess. I'm not putting a lot of faith in that actually working, just saying that the current code doesn't seem to be accomplishing anything in the robustness department. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
init-myproclocks-once.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
