Re: [COMMITTERS] pgsql: Replace our hacked version of ax_pthread.m4 with latest upstream
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 + configure | 310 - configure.in |2 +- 5 files changed, 583 insertions(+), 233 deletions(-) Since this commit I get additional diffs to pg_config.h.in when running autoconf. Namely +/* Define if you have POSIX threads libraries and header files. */ +#undef HAVE_PTHREAD + +/* Have PTHREAD_PRIO_INHERIT. */ +#undef HAVE_PTHREAD_PRIO_INHERIT + +/* Define to necessary symbol if this constant uses a non-standard name on + your system. */ +#undef PTHREAD_CREATE_JOINABLE + afaics they're newly emitted by the updated scripts. Was there any reason not to commit them? If not I'll push those. - Andres -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Handle PQresultErrorField(PG_DIAG_SQLSTATE) returning NULL in st
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: cab7npqq3o10sy6nvdu4pjq85gqtn5tbbkq2gnnuh2fbnu3r...@mail.gmail.com Backpatch: 9.5, like ff27db5d Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/2e6f6f3abe6fd249cc8a4d5eb194295ac3988b19 Modified Files -- src/bin/pg_basebackup/streamutil.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Remove duplicated assignment in pg_create_physical_replication_s
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 changed, 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix two off-by-one errors in bufmgr.c.
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 (InvalidBuffer) requires a unlikely, but possible, set of circumstances to trigger a symptom. To reduce the likelihood of such incidents a bit also convert existing open coded mappings from buffer descriptors to buffer ids with BufferDescriptorGetBuffer(). Author: Qingqing Zhou Reported-By: Qingqing Zhou Discussion: cajjs0u2ai9oouisktkv8cuvutekmtsbk8c7junajv8k11ze...@mail.gmail.com Backpatch: 9.5 where the private ref count infrastructure was introduced Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/d25fbf9f3ecffb5c80a9201a6310e74da24556a4 Modified Files -- src/backend/storage/buffer/bufmgr.c | 36 ++- 1 file changed, 19 insertions(+), 17 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix two off-by-one errors in bufmgr.c.
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 (InvalidBuffer) requires a unlikely, but possible, set of circumstances to trigger a symptom. To reduce the likelihood of such incidents a bit also convert existing open coded mappings from buffer descriptors to buffer ids with BufferDescriptorGetBuffer(). Author: Qingqing Zhou Reported-By: Qingqing Zhou Discussion: cajjs0u2ai9oouisktkv8cuvutekmtsbk8c7junajv8k11ze...@mail.gmail.com Backpatch: 9.5 where the private ref count infrastructure was introduced Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/43a8ed26c97e36d971b6018d1bc94ad5c52d169b Modified Files -- src/backend/storage/buffer/bufmgr.c | 36 ++- 1 file changed, 19 insertions(+), 17 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Optionally don't error out due to preexisting slots in commandli
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. Thanks, fixed! -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Handle PQresultErrorField(PG_DIAG_SQLSTATE) returning NULL in st
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: cab7npqq3o10sy6nvdu4pjq85gqtn5tbbkq2gnnuh2fbnu3r...@mail.gmail.com Backpatch: 9.5, like ff27db5d Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/7685963eeb16c377c2e0ff7b1852b7a8bc527270 Modified Files -- src/bin/pg_basebackup/streamutil.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Further fixes for degenerate outer join clauses.
Andrew Dunstan and...@dunslane.net 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 what's up. Odd that it's just the one critter though ... regards, tom lane -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Undo mistaken tightening in join_is_legal().
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 can miss valid plans, and might indeed fail to find a plan at all, as in recent report from Andreas Seltenreich. That code was added way back in commit c17117649b9ae23d, but I failed to include a regression test case then; my bad. Put it back with a better explanation, and a test this time. The logic does end up a bit different than before though: I now believe it's appropriate to make this check first, thereby allowing such a case whether or not we'd consider the previous SJ(s) to commute with this one. (Presumably, we already decided they did; but it was confusing to have this consideration in the middle of the code that was handling the other case.) Back-patch to all active branches, like the previous patch. Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/4390ba7bf937f56f647359b52e6ba04f31b21901 Modified Files -- src/backend/optimizer/path/joinrels.c | 29 + src/test/regress/expected/join.out| 46 + src/test/regress/sql/join.sql | 19 ++ 3 files changed, 89 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Undo mistaken tightening in join_is_legal().
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 can miss valid plans, and might indeed fail to find a plan at all, as in recent report from Andreas Seltenreich. That code was added way back in commit c17117649b9ae23d, but I failed to include a regression test case then; my bad. Put it back with a better explanation, and a test this time. The logic does end up a bit different than before though: I now believe it's appropriate to make this check first, thereby allowing such a case whether or not we'd consider the previous SJ(s) to commute with this one. (Presumably, we already decided they did; but it was confusing to have this consideration in the middle of the code that was handling the other case.) Back-patch to all active branches, like the previous patch. Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/ec94bc1473475128ef4e7b62636e66effd314102 Modified Files -- src/backend/optimizer/path/joinrels.c | 29 + src/test/regress/expected/join.out| 46 + src/test/regress/sql/join.sql | 19 ++ 3 files changed, 89 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Undo mistaken tightening in join_is_legal().
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 can miss valid plans, and might indeed fail to find a plan at all, as in recent report from Andreas Seltenreich. That code was added way back in commit c17117649b9ae23d, but I failed to include a regression test case then; my bad. Put it back with a better explanation, and a test this time. The logic does end up a bit different than before though: I now believe it's appropriate to make this check first, thereby allowing such a case whether or not we'd consider the previous SJ(s) to commute with this one. (Presumably, we already decided they did; but it was confusing to have this consideration in the middle of the code that was handling the other case.) Back-patch to all active branches, like the previous patch. Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/7950657a92d108458508eb690e0aa6322640e5e5 Modified Files -- src/backend/optimizer/path/joinrels.c | 29 + src/test/regress/expected/join.out| 46 + src/test/regress/sql/join.sql | 19 ++ 3 files changed, 89 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Undo mistaken tightening in join_is_legal().
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 can miss valid plans, and might indeed fail to find a plan at all, as in recent report from Andreas Seltenreich. That code was added way back in commit c17117649b9ae23d, but I failed to include a regression test case then; my bad. Put it back with a better explanation, and a test this time. The logic does end up a bit different than before though: I now believe it's appropriate to make this check first, thereby allowing such a case whether or not we'd consider the previous SJ(s) to commute with this one. (Presumably, we already decided they did; but it was confusing to have this consideration in the middle of the code that was handling the other case.) Back-patch to all active branches, like the previous patch. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/cfe30a72fa80528997357cb0780412736767e8c4 Modified Files -- src/backend/optimizer/path/joinrels.c | 29 + src/test/regress/expected/join.out| 46 + src/test/regress/sql/join.sql | 19 ++ 3 files changed, 89 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Undo mistaken tightening in join_is_legal().
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 can miss valid plans, and might indeed fail to find a plan at all, as in recent report from Andreas Seltenreich. That code was added way back in commit c17117649b9ae23d, but I failed to include a regression test case then; my bad. Put it back with a better explanation, and a test this time. The logic does end up a bit different than before though: I now believe it's appropriate to make this check first, thereby allowing such a case whether or not we'd consider the previous SJ(s) to commute with this one. (Presumably, we already decided they did; but it was confusing to have this consideration in the middle of the code that was handling the other case.) Back-patch to all active branches, like the previous patch. Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/8cd3a7adabcd1837a1aca80f11257ef11589630f Modified Files -- src/backend/optimizer/path/joinrels.c | 29 + src/test/regress/expected/join.out| 46 + src/test/regress/sql/join.sql | 19 ++ 3 files changed, 89 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix unitialized variables
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/652ca927ca4d9553691b9c6385111bea353070d8 Modified Files -- src/backend/access/brin/brin_pageops.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix unitialized variables
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 Modified Files -- src/backend/access/brin/brin_pageops.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Undo mistaken tightening in join_is_legal().
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 can miss valid plans, and might indeed fail to find a plan at all, as in recent report from Andreas Seltenreich. That code was added way back in commit c17117649b9ae23d, but I failed to include a regression test case then; my bad. Put it back with a better explanation, and a test this time. The logic does end up a bit different than before though: I now believe it's appropriate to make this check first, thereby allowing such a case whether or not we'd consider the previous SJ(s) to commute with this one. (Presumably, we already decided they did; but it was confusing to have this consideration in the middle of the code that was handling the other case.) Back-patch to all active branches, like the previous patch. Branch -- REL9_0_STABLE Details --- http://git.postgresql.org/pg/commitdiff/7b4b57fc484ab8edb4c921cd4b18f2b5b379ef44 Modified Files -- src/backend/optimizer/path/joinrels.c | 29 + src/test/regress/expected/join.out| 46 + src/test/regress/sql/join.sql | 19 ++ 3 files changed, 89 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Undo mistaken tightening in join_is_legal().
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 can miss valid plans, and might indeed fail to find a plan at all, as in recent report from Andreas Seltenreich. That code was added way back in commit c17117649b9ae23d, but I failed to include a regression test case then; my bad. Put it back with a better explanation, and a test this time. The logic does end up a bit different than before though: I now believe it's appropriate to make this check first, thereby allowing such a case whether or not we'd consider the previous SJ(s) to commute with this one. (Presumably, we already decided they did; but it was confusing to have this consideration in the middle of the code that was handling the other case.) Back-patch to all active branches, like the previous patch. Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/866197d828a85d80886871801b1d084dd3116936 Modified Files -- src/backend/optimizer/path/joinrels.c | 29 + src/test/regress/expected/join.out| 46 + src/test/regress/sql/join.sql | 19 ++ 3 files changed, 89 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Optionally don't error out due to preexisting slots in commandli
On Mon, Jul 13, 2015 at 5:17 AM, Andres Freund and...@anarazel.de wrote:
Optionally don't error out due to preexisting slots in commandline utilities.
pg_receivexlog and pg_recvlogical error out when --create-slot is
specified and a slot with the same name already exists. In some cases,
especially with pg_receivexlog, that's rather annoying and requires
additional scripting.
Backpatch to 9.5 as slot control functions have newly been added to
pg_receivexlog, and there doesn't seem much point leaving it in a less
useful state.
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.
Regards,
--
Michael
diff --git a/src/bin/pg_basebackup/streamutil.c b/src/bin/pg_basebackup/streamutil.c
index 91f919c..ccc6108 100644
--- a/src/bin/pg_basebackup/streamutil.c
+++ b/src/bin/pg_basebackup/streamutil.c
@@ -340,7 +340,9 @@ CreateReplicationSlot(PGconn *conn, const char *slot_name, const char *plugin,
{
const char *sqlstate = PQresultErrorField(res, PG_DIAG_SQLSTATE);
- if (slot_exists_ok strcmp(sqlstate, ERRCODE_DUPLICATE_OBJECT) == 0)
+ if (sqlstate
+ slot_exists_ok
+ strcmp(sqlstate, ERRCODE_DUPLICATE_OBJECT) == 0)
{
destroyPQExpBuffer(query);
PQclear(res);
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: This routine was calling ecpg_alloc to allocate to memory but di
On 23.07.2015 09:19, Michael Paquier wrote: On Thu, Feb 5, 2015 at 11:14 PM, Michael Meskes mes...@postgresql.org 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. Issue noted by Coverity, fixed by Michael Paquier mich...@otacoo.com Coming back to it, perhaps this meritates a backpatch? Even if that's unlikely to happen... cherry-picked and pushed to all back branches. Sorry, the disadvantage of testing in master for a while, I simply forgot about this change. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: This routine was calling ecpg_alloc to allocate to memory but di
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 mich...@otacoo.com Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/157d40640cdd885b72f27db358ba66d12feaec7d Modified Files -- src/interfaces/ecpg/ecpglib/descriptor.c |6 ++ src/interfaces/ecpg/ecpglib/execute.c|6 ++ src/interfaces/ecpg/ecpglib/extern.h |4 ++-- src/interfaces/ecpg/ecpglib/memory.c | 22 +- 4 files changed, 27 insertions(+), 11 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: This routine was calling ecpg_alloc to allocate to memory but di
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 mich...@otacoo.com Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/ed089d2fec8dde61d169f1f67a96e099425e77c7 Modified Files -- src/interfaces/ecpg/ecpglib/descriptor.c |6 ++ src/interfaces/ecpg/ecpglib/execute.c|6 ++ src/interfaces/ecpg/ecpglib/extern.h |4 ++-- src/interfaces/ecpg/ecpglib/memory.c | 22 +- 4 files changed, 27 insertions(+), 11 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: This routine was calling ecpg_alloc to allocate to memory but di
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 mich...@otacoo.com Branch -- REL9_0_STABLE Details --- http://git.postgresql.org/pg/commitdiff/d4215954747e5463ea5c161aa776040ec45c40e4 Modified Files -- src/interfaces/ecpg/ecpglib/descriptor.c |6 ++ src/interfaces/ecpg/ecpglib/execute.c|6 ++ src/interfaces/ecpg/ecpglib/extern.h |4 ++-- src/interfaces/ecpg/ecpglib/memory.c | 22 +- 4 files changed, 27 insertions(+), 11 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: This routine was calling ecpg_alloc to allocate to memory but di
On Wed, Aug 12, 2015 at 8:59 PM, Michael Meskes mes...@postgresql.org wrote: On 23.07.2015 09:19, Michael Paquier wrote: On Thu, Feb 5, 2015 at 11:14 PM, Michael Meskes mes...@postgresql.org 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. Issue noted by Coverity, fixed by Michael Paquier mich...@otacoo.com Coming back to it, perhaps this meritates a backpatch? Even if that's unlikely to happen... cherry-picked and pushed to all back branches. Sorry, the disadvantage of testing in master for a while, I simply forgot about this change. No pb. Thanks! I forgot myself... -- Michael -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: This routine was calling ecpg_alloc to allocate to memory but di
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 mich...@otacoo.com Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/a2b2565fc9318b8903ef4821bc0be40a64810aec Modified Files -- src/interfaces/ecpg/ecpglib/descriptor.c |6 ++ src/interfaces/ecpg/ecpglib/execute.c|6 ++ src/interfaces/ecpg/ecpglib/extern.h |4 ++-- src/interfaces/ecpg/ecpglib/memory.c | 22 +- 4 files changed, 27 insertions(+), 11 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: This routine was calling ecpg_alloc to allocate to memory but di
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 mich...@otacoo.com Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/e0ca86aa98de9c60815d3717b92b62a9f2c0c07d Modified Files -- src/interfaces/ecpg/ecpglib/descriptor.c |6 ++ src/interfaces/ecpg/ecpglib/execute.c|6 ++ src/interfaces/ecpg/ecpglib/extern.h |4 ++-- src/interfaces/ecpg/ecpglib/memory.c | 22 +- 4 files changed, 27 insertions(+), 11 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Further fixes for degenerate outer join clauses.
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 study I concluded that my previous changes in make_outerjoininfo() were just accidentally masking the problem, and should be reverted in favor of forcing syntactic join order whenever an upper outer join's predicate doesn't mention a lower outer join's LHS. This still allows the chained-outer-joins style that is the normally optimizable case. I also tightened things up some more in join_is_legal(). It seems to me on review that what's really happening in the exception case where we ignore a mismatched special join is that we're allowing the proposed join to associate into the RHS of the outer join we're comparing it to. As such, we should *always* insist that the proposed join be a left join, which eliminates a bunch of rather dubious argumentation. The case where we weren't enforcing that was the one that was already known buggy anyway (it had a violatable Assert before the aforesaid commit) so it hardly deserves a lot of deference. Back-patch to all active branches, like the previous patch. The added regression test case failed in all branches back to 9.1, and I think it's only an unrelated change in costing calculations that kept 9.0 from choosing a broken plan. 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. cheers andrew -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Close some holes in BRIN page assignment
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_getinsertbuffer) with the info about that page, but these actions are not WAL-logged. A later index insert/update can use the page, but since the page is already initialized, the initialization itself is not WAL-logged then either. Replay of this sequence of events causes recovery to fail altogether. There is a related corner case within brin_getinsertbuffer itself, in which we extend the relation to put a new index tuple there, but later find out that we cannot do so, and do not return the buffer; the page obtained from extension is not even initialized. The resulting page is lost forever. To fix, shuffle the code so that initialization is not the responsibility of brin_getinsertbuffer anymore, in normal cases; instead, the initialization is done by its callers (brin_doinsert and brin_doupdate) once they're certain that the page is going to be used. When either those functions determine that the new page cannot be used, before bailing out they initialize the page as an empty regular page, enter it in FSM and WAL-log all this. This way, the page is usable for future index insertions, and WAL replay doesn't find trying to insert tuples in pages whose initialization didn't make it to the WAL. The same strategy is used in brin_getinsertbuffer when it cannot return the new page. Additionally, add a new step to vacuuming so that all pages of the index are scanned; whenever an uninitialized page is found, it is initialized as empty and WAL-logged. This closes the hole that the relation is extended but the system crashes before anything is WAL-logged about it. We also take this opportunity to update the FSM, in case it has gotten out of date. Thanks to Heikki Linnakangas for finding the problem that kicked some additional analysis of BRIN page assignment code. Backpatch to 9.5, where BRIN was introduced. Discussion: https://www.postgresql.org/message-id/20150723204810.gy5...@postgresql.org Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/fc0a6402306db3cc93a5f760acabab687998be1d Modified Files -- src/backend/access/brin/brin.c | 43 ++ src/backend/access/brin/brin_pageops.c | 234 +--- src/include/access/brin_page.h |1 + src/include/access/brin_pageops.h |2 + 4 files changed, 258 insertions(+), 22 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Close some holes in BRIN page assignment
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_getinsertbuffer) with the info about that page, but these actions are not WAL-logged. A later index insert/update can use the page, but since the page is already initialized, the initialization itself is not WAL-logged then either. Replay of this sequence of events causes recovery to fail altogether. There is a related corner case within brin_getinsertbuffer itself, in which we extend the relation to put a new index tuple there, but later find out that we cannot do so, and do not return the buffer; the page obtained from extension is not even initialized. The resulting page is lost forever. To fix, shuffle the code so that initialization is not the responsibility of brin_getinsertbuffer anymore, in normal cases; instead, the initialization is done by its callers (brin_doinsert and brin_doupdate) once they're certain that the page is going to be used. When either those functions determine that the new page cannot be used, before bailing out they initialize the page as an empty regular page, enter it in FSM and WAL-log all this. This way, the page is usable for future index insertions, and WAL replay doesn't find trying to insert tuples in pages whose initialization didn't make it to the WAL. The same strategy is used in brin_getinsertbuffer when it cannot return the new page. Additionally, add a new step to vacuuming so that all pages of the index are scanned; whenever an uninitialized page is found, it is initialized as empty and WAL-logged. This closes the hole that the relation is extended but the system crashes before anything is WAL-logged about it. We also take this opportunity to update the FSM, in case it has gotten out of date. Thanks to Heikki Linnakangas for finding the problem that kicked some additional analysis of BRIN page assignment code. Backpatch to 9.5, where BRIN was introduced. Discussion: https://www.postgresql.org/message-id/20150723204810.gy5...@postgresql.org Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/ccc4c074994d734aefb9810af79a762df3c0e974 Modified Files -- src/backend/access/brin/brin.c | 43 ++ src/backend/access/brin/brin_pageops.c | 234 +--- src/include/access/brin_page.h |1 + src/include/access/brin_pageops.h |2 + 4 files changed, 258 insertions(+), 22 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
