Re: postgresql and process titles - Mailing list pgsql-hackers

From Greg Stark
Subject Re: postgresql and process titles
Date
Msg-id 878xnzbd4k.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: postgresql and process titles  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Jim C. Nasby" <jnasby@pervasive.com> writes:

> Even if what's being written is a single byte/word and we're taking
> intentional steps to make sure that reading a pointer that's off by 1
> isn't an issue? Is the issue that if CPU A writes a pointer and CPU B
> immediately tries to read it that it could get old data from it's cache?

Well for applications like this you don't care whether you get the old data or
the new data. You just want to be sure you don't get half of each.

However:

Tom Lane <tgl@sss.pgh.pa.us> writes:

> Do I need to point out that sig_atomic_t can't portably be assumed to be
> wider than char?

I didn't actually realize that. That would mean EXPLAIN ANALYZE would be
limited to counting times for 256 plan nodes and wouldn't really be much of an
improvement over the existing infrastructure.

> In any case, speculating about whether we can do something useful with
> atomic types ignores the main real problem the thread is about.  Anybody
> remember process titles and current command strings?

Oops, I thought this was the ANALYZE patch thread.

-- 
greg



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: PQescapeIdentifier
Next
From: Tom Lane
Date:
Subject: Re: libpq's pollution of application namespace