Alvaro Herrera writes:
> Marko Tiikkaja wrote:
>> Any chance to get this fixed in time for 9.1.16?
> I hope you had pinged some days earlier. Here's a patch, but I will
> wait until this week's releases have been tagged before pushing.
BTW, I meant to update this thread but forgot until now: th
Simon Riggs wrote:
> On 15 May 2015 at 19:03, Alvaro Herrera wrote:
>
> > Andres Freund wrote:
> >
> > > Alternatively we could make MultiXactIdIsRunning() return false < 9.3
> > > when in recovery. I think that'd end up fixing things, but it seems
> > > awfully fragile to me.
> >
> > Hm, why fra
Andres Freund wrote:
> On 2015-05-18 14:13:51 -0300, Alvaro Herrera wrote:
> > Hmm, AFAICS the problematic check was introduced by this commit:
> >
> > commit 9f1e051adefb2f29e757cf426b03db20d3f8a26d
> > Author: Alvaro Herrera
> > Date: Fri Nov 29 11:26:41 2013 -0300
> >
> > so it isn't hot of
On 18 May 2015 at 12:59, Tom Lane wrote:
> Alvaro Herrera writes:
> > Marko Tiikkaja wrote:
> >> Any chance to get this fixed in time for 9.1.16?
>
> > I hope you had pinged some days earlier. Here's a patch, but I will
> > wait until this week's releases have been tagged before pushing.
>
> Is
On 2015-05-18 14:13:51 -0300, Alvaro Herrera wrote:
> Hmm, AFAICS the problematic check was introduced by this commit:
>
> commit 9f1e051adefb2f29e757cf426b03db20d3f8a26d
> Author: Alvaro Herrera
> Date: Fri Nov 29 11:26:41 2013 -0300
>
> so it isn't hot off the oven, but it is a regression.
Tom Lane wrote:
> Alvaro Herrera writes:
> > Marko Tiikkaja wrote:
> >> Any chance to get this fixed in time for 9.1.16?
>
> > I hope you had pinged some days earlier. Here's a patch, but I will
> > wait until this week's releases have been tagged before pushing.
>
> Is this a recent regression
On 2015-05-18 12:59:47 -0400, Tom Lane wrote:
> If the former, maybe we should take the risk of fixing it today
> (the patch certainly looks safe enough). But if it's been this
> way a long time and nobody noticed till now, I'd agree with waiting.
It's a old regression, and nobody noticed it unti
Alvaro Herrera writes:
> Marko Tiikkaja wrote:
>> Any chance to get this fixed in time for 9.1.16?
> I hope you had pinged some days earlier. Here's a patch, but I will
> wait until this week's releases have been tagged before pushing.
Is this a recent regression, or has it been busted all alon
Marko Tiikkaja wrote:
> Hi hackers,
>
> Any chance to get this fixed in time for 9.1.16?
I hope you had pinged some days earlier. Here's a patch, but I will
wait until this week's releases have been tagged before pushing.
I checked 9.2, and it doesn't look like it's subject to the same
problem:
On 15 May 2015 at 19:03, Alvaro Herrera wrote:
> Andres Freund wrote:
>
> > Alternatively we could make MultiXactIdIsRunning() return false < 9.3
> > when in recovery. I think that'd end up fixing things, but it seems
> > awfully fragile to me.
>
> Hm, why fragile? It seems a pretty decent answe
Andres Freund wrote:
> Alternatively we could make MultiXactIdIsRunning() return false < 9.3
> when in recovery. I think that'd end up fixing things, but it seems
> awfully fragile to me.
Hm, why fragile? It seems a pretty decent answer -- pre-9.3, it's not
possible for a tuple to be "locked" in
Hi hackers,
Any chance to get this fixed in time for 9.1.16?
.m
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
On 2015-02-23 15:00:35 +0100, Marko Tiikkaja wrote:
> Andres asked me on IRC to report this here. Since we upgraded our standby
> servers to 9.1.15 (though the master is still running 9.1.14), we've seen
> the error in $SUBJECT a number of times.
FWIW, I think this is just as borked in 9.1.1
Hi,
Andres asked me on IRC to report this here. Since we upgraded our
standby servers to 9.1.15 (though the master is still running 9.1.14),
we've seen the error in $SUBJECT a number of times. I managed to
reproduce it today by running the same query over and over again, and
attached is the
14 matches
Mail list logo