Fix crash bug in RestoreSnapshot.
If serialized_snapshot->subxcnt > 0 and serialized_snapshot->xcnt == 0,
the old coding would do the wrong thing and crash. This can happen
on standby servers.
Report by Andreas Seltenreich. Patch by Thomas Munro, reviewed by
Amit Kapila and tested by Andreas Se
Fix crash bug in RestoreSnapshot.
If serialized_snapshot->subxcnt > 0 and serialized_snapshot->xcnt == 0,
the old coding would do the wrong thing and crash. This can happen
on standby servers.
Report by Andreas Seltenreich. Patch by Thomas Munro, reviewed by
Amit Kapila and tested by Andreas Se
On 1 July 2016 at 15:04, Robert Haas wrote:
> Fix crash bug in RestoreSnapshot.
>
> If serialized_snapshot->subxcnt > 0 and serialized_snapshot->xcnt == 0,
> the old coding would do the wrong thing and crash. This can happen
> on standby servers.
>
> Report by Andreas Seltenreich. Patch by Thom
On Fri, Jul 1, 2016 at 9:34 AM, Simon Riggs wrote:
> "This can happen on standby servers"
>
> The commit message doesn't mention, but it applies only to parallel query?
>
> Why then is this backpatched to 9.5?
Because that's where the code was added. In 9.5, it would only matter
for extensions u
postgres_fdw: Remove schema-qualification from cast to text.
As pointed out by Ashutosh Bapat, the header comments for this file
say that schema-qualification is needed for all and only those types
outside pg_catalog. pg_catalog.text is not outside pg_catalog.
Branch
--
master
Details
-
On 1 July 2016 at 16:04, Robert Haas wrote:
> On Fri, Jul 1, 2016 at 9:34 AM, Simon Riggs wrote:
> > "This can happen on standby servers"
> >
> > The commit message doesn't mention, but it applies only to parallel
> query?
> >
> > Why then is this backpatched to 9.5?
>
> Because that's where the
Simon Riggs writes:
> On 1 July 2016 at 16:04, Robert Haas wrote:
>> Because that's where the code was added. In 9.5, it would only matter
>> for extensions using the ParallelContext machinery.
> It seems strange to me to make an unnecessary change to a production
> release, that's all.
> My un
postgres_fdw: Fix cache lookup failure while creating error context.
This is fallout from join pushdown; get_relid_attribute_name can't
handle an attribute number of 0, indicating a whole-row reference,
and shouldn't be called in that case.
Etsuro Fujita, reviewed by Ashutosh Bapat
Branch
--
On Fri, Jul 1, 2016 at 10:43 AM, Tom Lane wrote:
> Simon Riggs writes:
>> On 1 July 2016 at 16:04, Robert Haas wrote:
>>> Because that's where the code was added. In 9.5, it would only matter
>>> for extensions using the ParallelContext machinery.
>
>> It seems strange to me to make an unnecess
Be more paranoid in ruleutils.c's get_variable().
We were merely Assert'ing that the Var matched the RTE it's supposedly
from. But if the user passes incorrect information to pg_get_expr(),
the RTE might in fact not match; this led either to Assert failures
or core dumps, as reported by Chris Han
Be more paranoid in ruleutils.c's get_variable().
We were merely Assert'ing that the Var matched the RTE it's supposedly
from. But if the user passes incorrect information to pg_get_expr(),
the RTE might in fact not match; this led either to Assert failures
or core dumps, as reported by Chris Han
Be more paranoid in ruleutils.c's get_variable().
We were merely Assert'ing that the Var matched the RTE it's supposedly
from. But if the user passes incorrect information to pg_get_expr(),
the RTE might in fact not match; this led either to Assert failures
or core dumps, as reported by Chris Han
Be more paranoid in ruleutils.c's get_variable().
We were merely Assert'ing that the Var matched the RTE it's supposedly
from. But if the user passes incorrect information to pg_get_expr(),
the RTE might in fact not match; this led either to Assert failures
or core dumps, as reported by Chris Han
Set consider_parallel correctly for upper planner rels.
Commit 3fc6e2d7f5b652b417fa6937c34de2438d60fa9f introduced new "upper"
RelOptInfo structures but didn't set consider_parallel for them
correctly, a point I completely missed when reviewing it. Later,
commit e06a38965b3bcdaa881e7e06892d4d8ab6
On 1 July 2016 at 17:38, Robert Haas wrote:
> I think it's our standard practice to back-patch bug fixes to the
> point at which the code was introduced, even if in that release the
> code can only be reached by an extension.
If that's what we do then I'm happy with that.
--
Simon Riggs
Rethink the GetForeignUpperPaths API (again).
In the previous design, the GetForeignUpperPaths FDW callback hook was
called before we got around to labeling upper relations with the proper
consider_parallel flag; this meant that any upper paths created by an FDW
would be marked not-parallel-safe.
walreceiver: tweak pg_stat_wal_receiver behavior
There are two problems in the original coding: one is that if one
walreceiver process exits, the ready_to_display flag remains set in
shared memory, exposing the conninfo of the next walreceiver before
obfuscating. Fix by having WalRcvDie reset the
Provide and use a makefile target to build all generated headers.
As of 9.6, pg_regress doesn't build unless storage/lwlocknames.h has been
created; but there was nothing forcing that to happen if you just went into
src/test/regress/ and built there. We previously had a similar complaint
about pl
Improve WritebackContextInit() comment and prototype argument names.
Author: Masahiko Sawada
Discussion: CAD21AoBD=Of1OzL90Xx4Q-3j=-2q7=S87cs75HfutE=ecda...@mail.gmail.com
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/48bfeb244ff280bad9a81c67442065ae8fcda6b8
Modif
Fix some interrelated planner issues with initPlans and Param munging.
In commit 68fa28f77 I tried to teach SS_finalize_plan() to cope with
initPlans attached anywhere in the plan tree, by dint of moving its
handling of those into the recursion in finalize_plan(). It turns out that
that doesn't r
20 matches
Mail list logo
