> Wow, that is a weird case. In the first test, we count the number of
> days because it is less than a full month. In the second case, we call
> it a full month, but then forget how long it is. Not sure how we could
> improve this.
I do not think this needs to be improved, the problem is given
On Sun, Dec 2, 2012 at 1:02 PM, Tom Lane wrote:
> Jeff Janes writes:
>> On Sat, Dec 1, 2012 at 1:56 PM, Tom Lane wrote:
>>> I'm confused. Are you now saying that this problem only exists in
>>> 9.1.x? I tested current HEAD because you indicated the problem was
>>> still there.
>
>> No, I'm say
Jeff Janes writes:
> I've reproduced it again using the just-tagged 9.2.2, and uploaded a
> 135MB tarball of the /tmp/data_slave2 and /tmp/archivedir to google
> drive. The data directory contains the recovery.conf which is set to
> end recovery between the two critical time points.
Hmmm ... I c
I wrote:
> So apparently this is something we broke since Nov 18. Don't know what
> yet --- any thoughts?
Further experimentation shows that reverting commit
ffc3172e4e3caee0327a7e4126b5e7a3c8a1c8cf makes it work. So there's
something wrong/incomplete about that fix.
This is a bit urgent since
The following bug has been logged on the website:
Bug reference: 7730
Logged by: elein
Email address: el...@varlena.com
PostgreSQL version: 9.2.1
Operating system: Linux
Description:
select NULLIF('{1,2,3}'::integer[] - '{3,2,1}'::integer[], '{}'::integer[]);
This ret
On 2012-12-04 19:35:48 -0500, Tom Lane wrote:
> I wrote:
> > So apparently this is something we broke since Nov 18. Don't know what
> > yet --- any thoughts?
>
> Further experimentation shows that reverting commit
> ffc3172e4e3caee0327a7e4126b5e7a3c8a1c8cf makes it work. So there's
> something wr
On Tue, Dec 4, 2012 at 4:20 PM, Tom Lane wrote:
> Jeff Janes writes:
>> I've reproduced it again using the just-tagged 9.2.2, and uploaded a
>> 135MB tarball of the /tmp/data_slave2 and /tmp/archivedir to google
>> drive. The data directory contains the recovery.conf which is set to
>> end recov
On 2012-12-04 19:20:44 -0500, Tom Lane wrote:
> Jeff Janes writes:
> > I've reproduced it again using the just-tagged 9.2.2, and uploaded a
> > 135MB tarball of the /tmp/data_slave2 and /tmp/archivedir to google
> > drive. The data directory contains the recovery.conf which is set to
> > end reco
On Tue, Dec 4, 2012 at 4:35 PM, Tom Lane wrote:
> I wrote:
>> So apparently this is something we broke since Nov 18. Don't know what
>> yet --- any thoughts?
>
> Further experimentation shows that reverting commit
> ffc3172e4e3caee0327a7e4126b5e7a3c8a1c8cf makes it work. So there's
> something w
On 2012-12-04 18:05:15 -0800, Jeff Janes wrote:
> On Tue, Dec 4, 2012 at 4:20 PM, Tom Lane wrote:
> > Jeff Janes writes:
> >> I've reproduced it again using the just-tagged 9.2.2, and uploaded a
> >> 135MB tarball of the /tmp/data_slave2 and /tmp/archivedir to google
> >> drive. The data directo
Andres Freund writes:
>> But the key is, the database was not actually consistent at that
>> point, and so opening hot standby was a dangerous thing to do.
>>
>> The bug that allowed the database to open early (the original topic if
>> this email chain) was masking this secondary issue.
> Could
On 2012-12-04 21:27:34 -0500, Tom Lane wrote:
> Andres Freund writes:
> >> But the key is, the database was not actually consistent at that
> >> point, and so opening hot standby was a dangerous thing to do.
> >>
> >> The bug that allowed the database to open early (the original topic if
> >> this
Andres Freund writes:
> On 2012-12-04 21:27:34 -0500, Tom Lane wrote:
>> So the upshot is that I propose a patch more like the attached.
> Without having run anything so far it looks good to me.
BTW, while on the theme of the pause feature being several bricks shy of
a load, it looks to me like
13 matches
Mail list logo
