From: | Noah Misch <noah(at)2ndQuadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: sinval synchronization considered harmful |
Date: | 2011-07-27 17:58:11 |
Message-ID: | 20110727175811.GF18910@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 27, 2011 at 01:30:47PM -0400, Robert Haas wrote:
> On Wed, Jul 27, 2011 at 12:55 PM, Noah Misch <noah(at)2ndquadrant(dot)com> wrote:
> > [wrong objection]
>
> Eh, how can this possibly happen? You have to hold msgNumLock to to
> set maxMsgNum and msgNumLock to read maxMsgNum. If that's not enough
> to guarantee that we never read a stale value, what is?
Indeed, my analysis was all wrong.
> > I think a benchmark is in order, something like 900 idle connections and 80
> > connections running small transactions that create a few temporary tables. If
> > that shows no statistically significant regression, then we're probably fine
> > here. I'm not sure what result to expect, honestly.
>
> That's setting the bar pretty high. I don't mind doing the
> experiment, but I'm not sure that's the case we should be optimizing
> for.
Granted. How about 32 clients running the temporary table transaction, no idle
connections? Given the meager benefit of this patch compared to your previous
version, it would be hard to justify a notable performance drop in return.
> > What did you think of making the message number a uint64, removing wraparound
> > handling, and retaining SISeg.msgnumLock for 32-bit only? You could isolate the
> > variant logic in READ_MSGNUM and WRITE_MSGNUM macros.
>
> Well, what you really need to know is whether the platform has 8-byte
> atomic stores, which doesn't seem trivial to figure out, plus you need
> a memory fence. If that's the only method of fixing this problem we
> can agree on, I'm willing to work on it, but an
> architecture-independent fix would be nicer.
Fair enough.
Thanks,
nm
--
Noah Misch http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2011-07-27 18:05:10 | Re: PQescapeByteaConn - returns wrong string for PG9.1 Beta3 |
Previous Message | Florian Pflug | 2011-07-27 17:57:44 | Re: PQescapeByteaConn - returns wrong string for PG9.1 Beta3 |