This routine was calling ecpg_alloc to allocate to memory but did not
actually check the returned pointer allocated, potentially NULL which
could be the result of a malloc call.
Issue noted by Coverity, fixed by Michael Paquier
Branch
--
REL9_1_STABLE
Details
---
http://git.postgresql.o
This routine was calling ecpg_alloc to allocate to memory but did not
actually check the returned pointer allocated, potentially NULL which
could be the result of a malloc call.
Issue noted by Coverity, fixed by Michael Paquier
Branch
--
REL9_2_STABLE
Details
---
http://git.postgresql.o
This routine was calling ecpg_alloc to allocate to memory but did not
actually check the returned pointer allocated, potentially NULL which
could be the result of a malloc call.
Issue noted by Coverity, fixed by Michael Paquier
Branch
--
REL9_4_STABLE
Details
---
http://git.postgresql.o
This routine was calling ecpg_alloc to allocate to memory but did not
actually check the returned pointer allocated, potentially NULL which
could be the result of a malloc call.
Issue noted by Coverity, fixed by Michael Paquier
Branch
--
REL9_3_STABLE
Details
---
http://git.postgresql.o
This routine was calling ecpg_alloc to allocate to memory but did not
actually check the returned pointer allocated, potentially NULL which
could be the result of a malloc call.
Issue noted by Coverity, fixed by Michael Paquier
Branch
--
REL9_0_STABLE
Details
---
http://git.postgresql.o
On 23.07.2015 09:19, Michael Paquier wrote:
> On Thu, Feb 5, 2015 at 11:14 PM, Michael Meskes wrote:
>> This routine was calling ecpg_alloc to allocate to memory but did not
>> actually check the returned pointer allocated, potentially NULL which
>> could be the result of a malloc call.
>>
>> Issu
On Wed, Aug 12, 2015 at 8:59 PM, Michael Meskes wrote:
> On 23.07.2015 09:19, Michael Paquier wrote:
>> On Thu, Feb 5, 2015 at 11:14 PM, Michael Meskes
>> wrote:
>>> This routine was calling ecpg_alloc to allocate to memory but did not
>>> actually check the returned pointer allocated, potential
Hi Heikki,
On 2015-07-08 17:42:24 +, Heikki Linnakangas wrote:
> Replace our hacked version of ax_pthread.m4 with latest upstream version.
> Modified Files
> --
> aclocal.m4|2 +-
> config/acx_pthread.m4 | 170 -
> config/ax_pthread.m4 | 332
Remove duplicated assignment in pg_create_physical_replication_slot.
Reported-By: Gurjeet Singh
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/a4b059fddecefd5f473e539b28277874ab83f32f
Modified Files
--
src/backend/replication/slotfuncs.c |1 -
1 file
Fix two off-by-one errors in bufmgr.c.
In 4b4b680c I passed a buffer index number (starting from 0) instead of
a proper Buffer id (which start from 1 for shared buffers) in two
places.
This wasn't noticed so far as one of those locations isn't compiled at
all (PrintPinnedBufs) and the other one (
Handle PQresultErrorField(PG_DIAG_SQLSTATE) returning NULL in streamutil.c.
In ff27db5d I missed that PQresultErrorField() may return NULL if
there's no sqlstate associated with an error.
Spotted-By: Coverity
Reported-By: Michael Paquier
Discussion: cab7npqq3o10sy6nvdu4pjq85gqtn5tbbkq2gnnuh2fbnu3
Handle PQresultErrorField(PG_DIAG_SQLSTATE) returning NULL in streamutil.c.
In ff27db5d I missed that PQresultErrorField() may return NULL if
there's no sqlstate associated with an error.
Spotted-By: Coverity
Reported-By: Michael Paquier
Discussion: cab7npqq3o10sy6nvdu4pjq85gqtn5tbbkq2gnnuh2fbnu3
Fix two off-by-one errors in bufmgr.c.
In 4b4b680c I passed a buffer index number (starting from 0) instead of
a proper Buffer id (which start from 1 for shared buffers) in two
places.
This wasn't noticed so far as one of those locations isn't compiled at
all (PrintPinnedBufs) and the other one (
On 2015-08-12 15:09:21 +0900, Michael Paquier wrote:
> Andres, Coverity is pointing out that this commit missed the shot when
> sqlstate is NULL in CreateReplicationSlot and this would crash.
> Something like the patch attached look adapted to me, vacuumdb.c doing
> the necessary checks similarly.
Close some holes in BRIN page assignment
In some corner cases, it is possible for the BRIN index relation to be
extended by brin_getinsertbuffer but the new page not be used
immediately for anything by its callers; when this happens, the page is
initialized and the FSM is updated (by brin_getinser
Close some holes in BRIN page assignment
In some corner cases, it is possible for the BRIN index relation to be
extended by brin_getinsertbuffer but the new page not be used
immediately for anything by its callers; when this happens, the page is
initialized and the FSM is updated (by brin_getinser
On 08/06/2015 03:36 PM, Tom Lane wrote:
Further fixes for degenerate outer join clauses.
Further testing revealed that commit f69b4b9495269cc4 was still a few
bricks shy of a load: minor tweaking of the previous test cases resulted
in the same wrong-outer-join-order problem coming back. After
Andrew Dunstan writes:
> On 08/06/2015 03:36 PM, Tom Lane wrote:
>> Further fixes for degenerate outer join clauses.
> Looks like this might have upset brolga on 9.0 and 9.1 - it's coming up
> with a different plan from what's expected.
Yeah, I saw that, but haven't had time yet to investigate
Undo mistaken tightening in join_is_legal().
One of the changes I made in commit 8703059c6b55c427 turns out not to have
been such a good idea: we still need the exception in join_is_legal() that
allows a join if both inputs already overlap the RHS of the special join
we're checking. Otherwise we
Undo mistaken tightening in join_is_legal().
One of the changes I made in commit 8703059c6b55c427 turns out not to have
been such a good idea: we still need the exception in join_is_legal() that
allows a join if both inputs already overlap the RHS of the special join
we're checking. Otherwise we
Undo mistaken tightening in join_is_legal().
One of the changes I made in commit 8703059c6b55c427 turns out not to have
been such a good idea: we still need the exception in join_is_legal() that
allows a join if both inputs already overlap the RHS of the special join
we're checking. Otherwise we
Undo mistaken tightening in join_is_legal().
One of the changes I made in commit 8703059c6b55c427 turns out not to have
been such a good idea: we still need the exception in join_is_legal() that
allows a join if both inputs already overlap the RHS of the special join
we're checking. Otherwise we
Undo mistaken tightening in join_is_legal().
One of the changes I made in commit 8703059c6b55c427 turns out not to have
been such a good idea: we still need the exception in join_is_legal() that
allows a join if both inputs already overlap the RHS of the special join
we're checking. Otherwise we
Undo mistaken tightening in join_is_legal().
One of the changes I made in commit 8703059c6b55c427 turns out not to have
been such a good idea: we still need the exception in join_is_legal() that
allows a join if both inputs already overlap the RHS of the special join
we're checking. Otherwise we
Undo mistaken tightening in join_is_legal().
One of the changes I made in commit 8703059c6b55c427 turns out not to have
been such a good idea: we still need the exception in join_is_legal() that
allows a join if both inputs already overlap the RHS of the special join
we're checking. Otherwise we
Fix unitialized variables
As complained by clang, reported by Andres Freund. Brown paper bag bug
in ccc4c074994d.
Add some comments, too.
Backpatch to 9.5, like that one.
Branch
--
REL9_5_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/652ca927ca4d9553691b9c6385111bea353070
Fix unitialized variables
As complained by clang, reported by Andres Freund. Brown paper bag bug
in ccc4c074994d.
Add some comments, too.
Backpatch to 9.5, like that one.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/fcbf455842eac10c331a866f559bb3875bcb8c37
Mod
27 matches
Mail list logo
