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