Re: profiling connection overhead

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: profiling connection overhead
Date: 2010-11-24 16:33:47
Message-ID: 20294.1290616427@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Nov 24, 2010 at 10:25 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Or make it execute only in assert-enabled mode, perhaps.

> But making the check execute only in assert-enabled more
> doesn't seem right, since the check actually acts to mask other coding
> errors, rather than reveal them. Maybe we replace the check with one
> that only occurs in an Assert-enabled build and just loops through and
> does Assert(PrivateRefCount[i] == 0).

Yeah, that would be sensible. There is precedent for this elsewhere
too; I think there's a similar setup for checking buffer refcounts
during transaction cleanup.

> I'm not sure exactly where this
> gets called in the shutdown sequence, though - is it sensible to
> Assert() here?

Assert is sensible anywhere.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-11-24 16:34:37 Re: Suggested "easy" TODO: pg_dump --from-list
Previous Message Robert Haas 2010-11-24 16:20:38 Re: profiling connection overhead