On Tue, Dec 16, 2014 at 11:57:54AM -0500, Tom Lane wrote:
> > We seem not to have had a new release of 9.2 since July, which is an
> > awfully long time ago. So, hopefully soon?
>
> Nothing's likely to happen during the holidays, so probably mid-January
> is the earliest feasible target.
>
> I a
Thank you for the answer. That sounds reasonable from the
situation.
> > On Tue, Dec 16, 2014 at 12:21 AM, Kyotaro HORIGUCHI
> > wrote:
> >> Then, could you please give me when the next release of 9.2.10 is
> >> to come?
>
> > We seem not to have had a new release of 9.2 since July, which is an
Robert Haas writes:
> On Tue, Dec 16, 2014 at 12:21 AM, Kyotaro HORIGUCHI
> wrote:
>> Then, could you please give me when the next release of 9.2.10 is
>> to come?
> We seem not to have had a new release of 9.2 since July, which is an
> awfully long time ago. So, hopefully soon?
Nothing's like
On Tue, Dec 16, 2014 at 12:21 AM, Kyotaro HORIGUCHI
wrote:
> Hello, I have a favor for you committers.
>
> I confirmed that this issue the another have been fixed in the
> repository, thank you.
>
> Then, could you please give me when the next release of 9.2.10 is
> to come?
>
> The bugs are found
Hello, I have a favor for you committers.
I confirmed that this issue the another have been fixed in the
repository, thank you.
Then, could you please give me when the next release of 9.2.10 is
to come?
The bugs are found in some system under developing, which is to
make use of PG9.2 and it want
(2014/12/16 2:59), Tom Lane wrote:
> Etsuro Fujita writes:
>> (2014/12/13 1:17), Tom Lane wrote:
>>> We should
>>> probably also think about allowing FDWs to change these settings if
>>> they want to.
>
>> This is not clear to me. Maybe I'm missing something, but I think that
>> the FDW only nee
Etsuro Fujita writes:
> (2014/12/13 1:17), Tom Lane wrote:
>> We should
>> probably also think about allowing FDWs to change these settings if
>> they want to.
> This is not clear to me. Maybe I'm missing something, but I think that
> the FDW only needs to look at the original locking strength i
(2014/12/13 1:17), Tom Lane wrote:
> Etsuro Fujita writes:
>>> (2014/12/12 10:37), Tom Lane wrote:
Yeah, this is clearly a thinko: really, nothing in the planner should
be using get_parse_rowmark(). I looked around for other errors of the
same type and found that postgresGetForeign
Etsuro Fujita writes:
>> (2014/12/12 10:37), Tom Lane wrote:
>>> Yeah, this is clearly a thinko: really, nothing in the planner should
>>> be using get_parse_rowmark(). I looked around for other errors of the
>>> same type and found that postgresGetForeignPlan() is also using
>>> get_parse_rowmar
(2014/12/12 11:33), Etsuro Fujita wrote:
> (2014/12/12 11:19), Tom Lane wrote:
>> Etsuro Fujita writes:
>>> (2014/12/12 10:37), Tom Lane wrote:
Yeah, this is clearly a thinko: really, nothing in the planner should
be using get_parse_rowmark(). I looked around for other errors of the
>>>
(2014/12/12 11:19), Tom Lane wrote:
> Etsuro Fujita writes:
>> (2014/12/12 10:37), Tom Lane wrote:
>>> Yeah, this is clearly a thinko: really, nothing in the planner should
>>> be using get_parse_rowmark(). I looked around for other errors of the
>>> same type and found that postgresGetForeignPla
Etsuro Fujita writes:
> (2014/12/12 10:37), Tom Lane wrote:
>> Yeah, this is clearly a thinko: really, nothing in the planner should
>> be using get_parse_rowmark(). I looked around for other errors of the
>> same type and found that postgresGetForeignPlan() is also using
>> get_parse_rowmark().
(2014/12/12 10:37), Tom Lane wrote:
> Yeah, this is clearly a thinko: really, nothing in the planner should
> be using get_parse_rowmark(). I looked around for other errors of the
> same type and found that postgresGetForeignPlan() is also using
> get_parse_rowmark(). While that's harmless at the
Kyotaro HORIGUCHI writes:
> This is caused by that IndexRecheck examines the test tuple with
> a qual "c = '0'" without "b IN ('0', '1')". The part has been
> removed in create_indexscan_plan. It decieds whether to remove a
> qual or not using get_parse_rowmark(root->parse(->rowMarks)) and
> predi
Hello, this is about the second issue.
SELECT FROM WHERE FOR UPDATE may
return results which does not match the . The following
steps will reproduce the problematic behavior (A and B are
individual sessions) on master and back to 9.0 but 8.4 gives
correct result. I haven't checked on 8.3.
- Rep
15 matches
Mail list logo
