Re: [HACKERS] myProcLocks initialization

2011-10-31 Thread Robert Haas
On Sun, Oct 30, 2011 at 11:26 PM, Robert Haas robertmh...@gmail.com wrote:
 On Sun, Oct 30, 2011 at 11:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@gmail.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
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


init-myproclocks-once-v2.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


Re: [HACKERS] myProcLocks initialization

2011-10-31 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes:
 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.

+1

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] myProcLocks initialization

2011-10-31 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com writes:
 On Mon, Oct 31, 2011 at 7:54 PM, Robert Haas robertmh...@gmail.com wrote:
 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.

 Something stronger than an assertion at shutdown? Run-time test?

There's currently no evidence to suggest this will ever fire at all,
especially not in non-development builds, so an assert seems enough
to me.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] myProcLocks initialization

2011-10-31 Thread Simon Riggs
On Mon, Oct 31, 2011 at 7:54 PM, Robert Haas robertmh...@gmail.com wrote:

 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.

Something stronger than an assertion at shutdown? Run-time test?

-- 
 Simon Riggs   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


Re: [HACKERS] myProcLocks initialization

2011-10-30 Thread Tom Lane
Robert Haas robertmh...@gmail.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?

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] myProcLocks initialization

2011-10-30 Thread Robert Haas
On Sun, Oct 30, 2011 at 11:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@gmail.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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers