[COMMITTERS] pgsql: Improve documentation about pg_stat_replication view.
Improve documentation about pg_stat_replication view. Add the descriptions of possible values in "state" and "sync_state" columns of pg_stat_replication view. Author: Michael Paquier, slightly modified by me Discussion: Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/dfe530a09226a9de80f2b4c3d5f667bf51481c49 Modified Files -- doc/src/sgml/high-availability.sgml | 6 + doc/src/sgml/monitoring.sgml| 51 +++-- 2 files changed, 55 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Bump catversion for restrictive RLS changes
Bump catversion for restrictive RLS changes Mea culpa. Pointed out by Andres. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/cb9dcbc1eebd8cccf98d7236b2c9bb82caf8b45d Modified Files -- src/include/catalog/catversion.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Add support for restrictive RLS policies
Andres, * Andres Freund ([email protected]) wrote: > On 2016-12-05 20:51:02 +, Stephen Frost wrote: > > Add support for restrictive RLS policies > This is missing a catversion bump. Ewps, apologies and thanks for pointing it out. Fixed. Stephen signature.asc Description: Digital signature
[COMMITTERS] pgsql: Revert "Permit dump/reload of not-too-large >1GB tuples"
Revert "Permit dump/reload of not-too-large >1GB tuples" This reverts commit 646655d264f17cf7fdbc6425ef8bc9a2f9f9ee41. Per Tom Lane, changing the definition of StringInfoData amounts to an ABI break, which is unacceptable in back branches. Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/f858524ee4f0e7249959ee0ee8dd9f00b3e8d107 Modified Files -- src/backend/access/common/heaptuple.c | 4 +-- src/backend/commands/copy.c | 8 ++--- src/backend/lib/stringinfo.c | 66 +++ src/include/lib/stringinfo.h | 18 +++--- 4 files changed, 22 insertions(+), 74 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Revert "Permit dump/reload of not-too-large >1GB tuples"
Revert "Permit dump/reload of not-too-large >1GB tuples" This reverts commit 4e01ecae98275298c680c92fdba62daf603dc98e. Per Tom Lane, changing the definition of StringInfoData amounts to an ABI break, which is unacceptable in back branches. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/e9e44a0953fa4ca54ace9500596c2ef930dbd1de Modified Files -- src/backend/access/common/heaptuple.c | 4 +-- src/backend/commands/copy.c | 8 ++--- src/backend/lib/stringinfo.c | 66 +++ src/include/lib/stringinfo.h | 18 +++--- 4 files changed, 22 insertions(+), 74 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix interaction of parallel query with prepared statements.
Fix interaction of parallel query with prepared statements. Previously, a prepared statement created via a Parse message could get a parallel plan, but one created with a PREPARE statement could not. This state of affairs was due to confusion on my (rhaas) part: I erroneously believed that a CREATE TABLE .. AS EXECUTE statement could only be performed with a prepared statement by PREPARE, but in fact one created by a Prepare message works just as well. Therefore, it makes no sense to allow parallel query in one case but not the other. To fix, allow parallel query with all prepared statements, but run the parallel plan serially (i.e. without workers) in the case of CREATE TABLE .. AS EXECUTE. Also, document this. Amit Kapila and Tobias Bussman, plus an extra sentence of documentation by me. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/ebe5dc9e02a6464713bd48e266eee48351d23062 Modified Files -- doc/src/sgml/parallel.sgml | 9 + src/backend/commands/prepare.c | 2 +- src/backend/executor/execMain.c | 7 --- 3 files changed, 14 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix interaction of parallel query with prepared statements.
Fix interaction of parallel query with prepared statements. Previously, a prepared statement created via a Parse message could get a parallel plan, but one created with a PREPARE statement could not. This state of affairs was due to confusion on my (rhaas) part: I erroneously believed that a CREATE TABLE .. AS EXECUTE statement could only be performed with a prepared statement by PREPARE, but in fact one created by a Prepare message works just as well. Therefore, it makes no sense to allow parallel query in one case but not the other. To fix, allow parallel query with all prepared statements, but run the parallel plan serially (i.e. without workers) in the case of CREATE TABLE .. AS EXECUTE. Also, document this. Amit Kapila and Tobias Bussman, plus an extra sentence of documentation by me. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/4212cb73262bbdd164727beffa4c4744b4ead92d Modified Files -- doc/src/sgml/parallel.sgml | 9 + src/backend/commands/prepare.c | 2 +- src/backend/executor/execMain.c | 7 --- 3 files changed, 14 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger source, second attemp
On 2016-12-05 11:44:37 +, Heikki Linnakangas wrote: > Replace PostmasterRandom() with a stronger source, second attempt. Since this went in I've seen 2016-12-06 14:42:17.005 PST [23658][] LOG: wrong key in cancel request for process 23657 2016-12-06 14:42:19.010 PST [23662][] LOG: wrong key in cancel request for process 23657 a couple times. I've not yet started debugging it. But it seems to only happen in the first (few?) queries in a new connection. Andres -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger source, second attemp
On Tue, Dec 6, 2016 at 12:44 AM, Heikki Linnakangas wrote: > src/backend/storage/lmgr/lwlocknames.txt | 1 + Missing one tab? -- Thomas Munro http://www.enterprisedb.com whitespace.patch Description: Binary data -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger source, second attemp
On Wed, Dec 7, 2016 at 7:46 AM, Andres Freund wrote: > On 2016-12-05 11:44:37 +, Heikki Linnakangas wrote: >> Replace PostmasterRandom() with a stronger source, second attempt. > > Since this went in I've seen > 2016-12-06 14:42:17.005 PST [23658][] LOG: wrong key in cancel request for > process 23657 > 2016-12-06 14:42:19.010 PST [23662][] LOG: wrong key in cancel request for > process 23657 > a couple times. > > I've not yet started debugging it. But it seems to only happen in the > first (few?) queries in a new connection. Hm. I recall testing this patch if cancel keys are working or not, but connecting with pgbench -C runnung in parallel I am seeing the following spurious error: =# select pg_sleep(10); ^CCancel request sent Time: 10001.496 ms (00:10.001) With the logs complaining as well: [1-1] db=[unknown],user=[unknown],app=[unknown],client=[local] LOG: wrong key in cancel request for process 57361 As far as I can see processCancelRequest uses a long variable, and it gets compared with an int32. MyCancelKey has been changed to an int32 in globals.c with the above commit. So on 64b machines the current code is aimed to fail. Attached is a patch to fix the issue. It is taking me at most 10 times to reproduce the failure without the patch, after trying 20~ times with the patch I am still able to cancel the queries. -- Michael fix-cancel-key.patch Description: application/download -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Put AC_MSG_RESULT() call in the right place.
Put AC_MSG_RESULT() call in the right place. Thinko in ecb0d20a9 --- this needs to go one level further out in the "if" nest. As it stood, nothing got printed in the case of selecting named POSIX semaphores. Cosmetic issue only, but a bug. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/c648f058319a59ad591dd9d1b0c48dfd655d063a Modified Files -- configure| 2 +- configure.in | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix unsafe assumption that struct timeval.tv_sec is a "long".
Fix unsafe assumption that struct timeval.tv_sec is a "long". It typically is a "long", but it seems possible that on some platforms it wouldn't be. In any case, this silences a compiler warning on OpenBSD (cf buildfarm member curculio). While at it, use snprintf not sprintf. This format string couldn't possibly overrun the supplied buffer, but that doesn't seem like a good reason not to use the safer style. Oversight in commit f828654e1. Back-patch to 9.6 where that came in. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/81f3c20a65e683ee235a5d3aa6146db84eb75ebf Modified Files -- src/backend/utils/error/elog.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix unsafe assumption that struct timeval.tv_sec is a "long".
Fix unsafe assumption that struct timeval.tv_sec is a "long". It typically is a "long", but it seems possible that on some platforms it wouldn't be. In any case, this silences a compiler warning on OpenBSD (cf buildfarm member curculio). While at it, use snprintf not sprintf. This format string couldn't possibly overrun the supplied buffer, but that doesn't seem like a good reason not to use the safer style. Oversight in commit f828654e1. Back-patch to 9.6 where that came in. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/0645dacc371da6169b06934e3bd238c5f770fe25 Modified Files -- src/backend/utils/error/elog.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Silence compiler warnings
Silence compiler warnings Rearrange a bit of code to ensure that 'mode' in LWLockRelease is obviously always set, which seems a bit cleaner and avoids a compiler warning (thanks to Robert for the suggestion!). In GetCachedPlan(), initialize 'plan' to silence a compiler warning, but also add an Assert() to make sure we don't ever actually fall through with 'plan' still being set to NULL, since we are about to dereference it. Neither of these appear to be live bugs but at least gcc 5.4.0-6ubuntu1~16.04.4 doesn't quite have the smarts to realize that. Discussion: https://www.postgresql.org/message-id/20161129152102.GR13284%40tamriel.snowman.net Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/d97b14ddab2059e1d73c0cd17f26bac4ef13e682 Modified Files -- src/backend/storage/lmgr/lwlock.c | 9 - src/backend/utils/cache/plancache.c | 4 +++- 2 files changed, 7 insertions(+), 6 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix whitespace.
Fix whitespace. Thomas Munro Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/9790b87f594565c11599b2004466169b8c2fd4af Modified Files -- src/backend/storage/lmgr/lwlocknames.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger source, second attemp
On 12/07/2016 01:56 AM, Thomas Munro wrote: On Tue, Dec 6, 2016 at 12:44 AM, Heikki Linnakangas wrote: src/backend/storage/lmgr/lwlocknames.txt | 1 + Missing one tab? Fixed, thanks. I missed this because my editor is set up to use 4-space tabs for .c and .h files, but not for .txt files. With 8-space tabs, it seemed to align with the previous lines. - Heikki -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix query cancellation.
Fix query cancellation. In commit fe0a0b59, the datatype used for MyCancelKey and other variables that store cancel keys were changed from long to uint32, but I missed this one. That broke query cancellation on platforms where long is wider than 32 bits. Report by Andres Freund, fix by Michael Paquier. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/81f2e514a9b2d813bb5fd6b62523757aa7a6517f Modified Files -- src/backend/postmaster/postmaster.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger source, second attemp
On 12/07/2016 02:30 AM, Michael Paquier wrote: With the logs complaining as well: [1-1] db=[unknown],user=[unknown],app=[unknown],client=[local] LOG: wrong key in cancel request for process 57361 As far as I can see processCancelRequest uses a long variable, and it gets compared with an int32. MyCancelKey has been changed to an int32 in globals.c with the above commit. So on 64b machines the current code is aimed to fail. Attached is a patch to fix the issue. Pushed, thanks! - Heikki -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
