Re: postgresql and process titles

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Kris Kennaway <kris(at)obsecurity(dot)org>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: postgresql and process titles
Date: 2006-06-14 22:12:27
Message-ID: 878xnzbd4k.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


"Jim C. Nasby" <jnasby(at)pervasive(dot)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(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-06-14 22:15:34 Re: libpq's pollution of application namespace
Previous Message Bruce Momjian 2006-06-14 22:09:13 Re: PQescapeIdentifier