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 agree
On Tue, Dec 16, 2014 at 12:21 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 16, 2014 at 12:21 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp 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
Thank you for the answer. That sounds reasonable from the
situation.
On Tue, Dec 16, 2014 at 12:21 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp 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
Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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
(2014/12/16 2:59), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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
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
(2014/12/12 11:33), Etsuro Fujita wrote:
(2014/12/12 11:19), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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
Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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
Hello, this is about the second issue.
SELECT FROM inheritance parent WHERE cond FOR UPDATE may
return results which does not match the cond. 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
Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp 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
(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
Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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
(2014/12/12 11:19), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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
14 matches
Mail list logo
