Skip site navigation (1) Skip section navigation (2)

Re: myProcLocks initialization

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: myProcLocks initialization
Date: 2011-10-31 19:54:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sun, Oct 30, 2011 at 11:26 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sun, Oct 30, 2011 at 11:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> 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.
>> That's not really enough to excite me, and the prospect of problems in
>> one session corrupting an unrelated later one is pretty scary from a
>> debugging standpoint.  How about at least an Assert that the lock is in
>> a clean state?
> I can go for that.

Revised patch attached.  I think it would be useful to assert this
both at process startup time and at process shutdown, since it would
really be much nicer to have the process that didn't clean up fail the
assertion, rather than the new one that innocently inherited its slot;
so the attached patch takes that approach.

Robert Haas
The Enterprise PostgreSQL Company

Attachment: init-myproclocks-once-v2.patch
Description: application/octet-stream (3.4 KB)

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-10-31 19:58:48
Subject: Re: LDAP server docs
Previous:From: Robert HaasDate: 2011-10-31 19:51:16
Subject: Re: LDAP server docs

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group