Re: BUG #10189: Limit in 9.3.4 no longer works when ordering using a composite multi-type index - Mailing list pgsql-bugs

From Nick Rupley
Subject Re: BUG #10189: Limit in 9.3.4 no longer works when ordering using a composite multi-type index
Date
Msg-id CAMi1eSGe8atvs8Pg=mf9EVD9e-AqEOLujWsDPMZpznv4JGJ_yA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #10189: Limit in 9.3.4 no longer works when ordering using a composite multi-type index  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-bugs
Thanks for the input Alvaro.

Actually we do have another question as well. Are there any implications we
should be aware of, if we decide to take 9.3.4 and the aforementioned
patch, and use the patched version of 9.3.4 on all future production boxes?
To be honest the commit log of that bug is mostly over my head, so I'm not
sure if the commit itself is dependent on any other post-9.3.4 commits.


On Mon, May 5, 2014 at 11:24 AM, Alvaro Herrera <alvherre@2ndquadrant.com>w=
rote:

> Nick Rupley wrote:
> > Hey guys, so we applied that patch, and it *appears* to have fixed the
> > issue! Through our application, we basically have it to the point where
> we
> > are able to reliably reproduce the issue within 5 minutes or so. Howeve=
r
> we
> > applied the patch, ran the same tests, and it no longer happened at all=
,
> > even after an hour of testing.
> >
> > We attempted to reproduce the issue in a standalone way, doing all the
> same
> > inserts/updates in all the same transactions, but unfortunately we
> haven't
> > yet been able to reproduce it there. I'm thinking it's likely a very
> > timing-sensitive issue, and it just happens to manifest for our
> application
> > because of race conditions, etc.
>
> Yes, it's extremely timing-sensitive.
>
> > Not sure if this is relevant or not, but it looks like the duplicate ro=
ws
> > continue to be inserted here and there on our production box (to which =
we
> > haven't yet applied the hotfix). As I stated before that production box
> did
> > have some server crashes before, but actually it hasn't had any recentl=
y
> > (in the past week), and yet the duplicate rows continue to happen.
>
> This bug is not dependent on a crash; the corruption occurs to the live
> data.  Only the previous bug mentioned by Tom manifested itself during
> crash recovery.
>
> > At one point we did identify and reindex the tables that were needed,
> > which worked great. But then *after* that, new duplicate rows cropped
> > up, even without the server having crashed. Does that still make sense
> > within the context of this bug?
>
> Yes.  Upgrading to a fixed binary is, of course, strongly recommended.
>
> > If we're able to create that self-contained test case (we're trying)
> we'll
> > be sure to let you know.
>
> Be sure to let us know if you find other bugs, too!
>
> --
> =C3=81lvaro Herrera                http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>

--=20
CONFIDENTIALITY NOTICE: The information contained in this electronic=20
transmission may be confidential. If you are not an intended recipient, be=
=20
aware that any disclosure, copying, distribution or use of the information=
=20
contained in this transmission is prohibited and may be unlawful. If you=20
have received this transmission in error, please notify us by email reply=
=20
and then erase it from your computer system.

pgsql-bugs by date:

Previous
From: Nick Rupley
Date:
Subject: Re: BUG #10189: Limit in 9.3.4 no longer works when ordering using a composite multi-type index
Next
From: Jamie Koceniak
Date:
Subject: Re: BUG #9635: Wal sender process is using 100% CPU