From: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: 8.1.2 select for update issue |
Date: | 2007-08-06 19:36:33 |
Message-ID: | 200708061336.33654.pgsql@bluepolka.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Monday 06 August 2007 1:22 pm, you wrote:
> "Ed L." <pgsql(at)bluepolka(dot)net> writes:
> > We're seeing some unexpected behavior in one particular
> > 64-bit Pgsql 8.1.2 running on HP-UX 11.23 and Itanium 2,
> > built with --enable-thread-safety. We think we are seeing
> > concurrent select-for-updates of the same rows by multiple
> > concurrent backends, contrary to our understanding of
> > select-for-update semantics.
>
> You really ought to be using something newer than 8.1.2.
Perhaps. But we have yet to find a way to make major version
upgrades of 100+ GB, 100+ tps databases sufficiently inexpensive
and painless in terms of SAN space, performance costs, and
customer downtime on heavily loaded systems. So we put them off
until there is a clear, directly compelling reason to upgrade.
> You do have a transaction block established around this whole
> process? Row locks only last as long as the current
> transaction ...
Of course. This is grasping at straws, but I was wondering if
perhaps anyone saw anything in this behavior that might suggest
a threadsafe-related anomaly?
TIA.
Ed
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Glaesemann | 2007-08-06 19:40:59 | Re: pg_dump of only the structure from a client such as ruby |
Previous Message | Lewis Cunningham | 2007-08-06 19:31:09 | Re: Procedural Code Profiling |