[COMMITTERS] pgsql: Fix inaccurate description of tablespace.
Fix inaccurate description of tablespace. Currently we don't need to update the pg_tablespace catalog after redefining the symbolic links to the tablespaces because pg_tablespace.spclocation column was removed in PostgreSQL 9.2. Back patch to 9.2 where pg_tablespace.spclocation was removed. Ian Barwick, with minor change by me. Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/fe136ba6fc31760efe7ac53e662395a71a92dc03 Modified Files -- doc/src/sgml/manage-ag.sgml | 13 +++-- 1 file changed, 7 insertions(+), 6 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 inaccurate description of tablespace.
Fix inaccurate description of tablespace. Currently we don't need to update the pg_tablespace catalog after redefining the symbolic links to the tablespaces because pg_tablespace.spclocation column was removed in PostgreSQL 9.2. Back patch to 9.2 where pg_tablespace.spclocation was removed. Ian Barwick, with minor change by me. Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/e73357c10b8ca7f38e83e73e57f09d774a83db2f Modified Files -- doc/src/sgml/manage-ag.sgml | 13 +++-- 1 file changed, 7 insertions(+), 6 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 inaccurate description of tablespace.
Fix inaccurate description of tablespace. Currently we don't need to update the pg_tablespace catalog after redefining the symbolic links to the tablespaces because pg_tablespace.spclocation column was removed in PostgreSQL 9.2. Back patch to 9.2 where pg_tablespace.spclocation was removed. Ian Barwick, with minor change by me. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/ee08a78a8104ce4e98ce67dc404b9d6ee3a1425a Modified Files -- doc/src/sgml/manage-ag.sgml | 13 +++-- 1 file changed, 7 insertions(+), 6 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 typo in comment.
Fix typo in comment. Hitoshi Harada Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/c876fb42417739dbb19540ef61f6cd75752eb16e Modified Files -- src/backend/storage/ipc/sinvaladt.c |2 +- 1 file changed, 1 insertion(+), 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 regexp_matches() handling of zero-length matches.
Fix regexp_matches() handling of zero-length matches. We'd find the same match twice if it was of zero length and not immediately adjacent to the previous match. replace_text_regexp() got similar cases right, so adjust this search logic to match that. Note that even though the regexp_split_to_xxx() functions share this code, they did not display equivalent misbehavior, because the second match would be considered degenerate and ignored. Jeevan Chalke, with some cosmetic changes by me. Branch -- REL9_0_STABLE Details --- http://git.postgresql.org/pg/commitdiff/5a27056b31fec62506ba327c7eceee0e875e201b Modified Files -- src/backend/utils/adt/regexp.c| 13 src/backend/utils/adt/varlena.c |5 ++- src/test/regress/expected/strings.out | 58 + src/test/regress/sql/strings.sql |7 4 files changed, 75 insertions(+), 8 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 regexp_matches() handling of zero-length matches.
Fix regexp_matches() handling of zero-length matches. We'd find the same match twice if it was of zero length and not immediately adjacent to the previous match. replace_text_regexp() got similar cases right, so adjust this search logic to match that. Note that even though the regexp_split_to_xxx() functions share this code, they did not display equivalent misbehavior, because the second match would be considered degenerate and ignored. Jeevan Chalke, with some cosmetic changes by me. Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/1346f40b584d8072bdacdf312027c0ef57e4b7c2 Modified Files -- src/backend/utils/adt/regexp.c| 13 src/backend/utils/adt/varlena.c |5 ++- src/test/regress/expected/strings.out | 58 + src/test/regress/sql/strings.sql |7 4 files changed, 75 insertions(+), 8 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 regexp_matches() handling of zero-length matches.
Fix regexp_matches() handling of zero-length matches. We'd find the same match twice if it was of zero length and not immediately adjacent to the previous match. replace_text_regexp() got similar cases right, so adjust this search logic to match that. Note that even though the regexp_split_to_xxx() functions share this code, they did not display equivalent misbehavior, because the second match would be considered degenerate and ignored. Jeevan Chalke, with some cosmetic changes by me. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/d074b4e50d11768ab6da696b13d40ec05e4823fb Modified Files -- src/backend/utils/adt/regexp.c| 13 src/backend/utils/adt/varlena.c |5 ++- src/test/regress/expected/strings.out | 58 + src/test/regress/sql/strings.sql |7 4 files changed, 75 insertions(+), 8 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 regexp_matches() handling of zero-length matches.
Fix regexp_matches() handling of zero-length matches. We'd find the same match twice if it was of zero length and not immediately adjacent to the previous match. replace_text_regexp() got similar cases right, so adjust this search logic to match that. Note that even though the regexp_split_to_xxx() functions share this code, they did not display equivalent misbehavior, because the second match would be considered degenerate and ignored. Jeevan Chalke, with some cosmetic changes by me. Branch -- REL8_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/b2bdb7b76f474d703bcc2656b7a9e7a163e73f48 Modified Files -- src/backend/utils/adt/regexp.c| 13 src/backend/utils/adt/varlena.c |5 ++- src/test/regress/expected/strings.out | 58 + src/test/regress/sql/strings.sql |7 4 files changed, 75 insertions(+), 8 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 regexp_matches() handling of zero-length matches.
Fix regexp_matches() handling of zero-length matches. We'd find the same match twice if it was of zero length and not immediately adjacent to the previous match. replace_text_regexp() got similar cases right, so adjust this search logic to match that. Note that even though the regexp_split_to_xxx() functions share this code, they did not display equivalent misbehavior, because the second match would be considered degenerate and ignored. Jeevan Chalke, with some cosmetic changes by me. Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/5d9951a65037fe2b7bdca8ed20c8775594672e34 Modified Files -- src/backend/utils/adt/regexp.c| 13 src/backend/utils/adt/varlena.c |5 ++- src/test/regress/expected/strings.out | 58 + src/test/regress/sql/strings.sql |7 4 files changed, 75 insertions(+), 8 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 regexp_matches() handling of zero-length matches.
Fix regexp_matches() handling of zero-length matches. We'd find the same match twice if it was of zero length and not immediately adjacent to the previous match. replace_text_regexp() got similar cases right, so adjust this search logic to match that. Note that even though the regexp_split_to_xxx() functions share this code, they did not display equivalent misbehavior, because the second match would be considered degenerate and ignored. Jeevan Chalke, with some cosmetic changes by me. Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/8505ebf31eb50c20afeaca0e0dfa2fbb1cec001f Modified Files -- src/backend/utils/adt/regexp.c| 13 src/backend/utils/adt/varlena.c |5 ++- src/test/regress/expected/strings.out | 58 + src/test/regress/sql/strings.sql |7 4 files changed, 75 insertions(+), 8 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: pg_dump/pg_dumpall: remove unnecessary SQL trailing semicolons
pg_dump/pg_dumpall: remove unnecessary SQL trailing semicolons Patch by Ian Lawrence Barwick Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/8eb29194fc1711308804e8d4238a002a1cd35afe Modified Files -- src/bin/pg_dump/pg_dump.c|1 - src/bin/pg_dump/pg_dumpall.c |2 -- 2 files changed, 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 a couple of inconsequential typos in new header
Fix a couple of inconsequential typos in new header Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/3142cf6dd5c0308633e36fabbd13bb51bdec1ff2 Modified Files -- src/include/postmaster/bgworker_internals.h |4 ++-- 1 file changed, 2 insertions(+), 2 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 mis-indented lines
Fix mis-indented lines Per Coverity Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/a59516b6311a6c2acc89448c94913ebae598f02a Modified Files -- src/backend/utils/misc/guc-file.l |6 +++--- 1 file changed, 3 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 mis-indented lines
Fix mis-indented lines Per Coverity Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/603c4a90c15f601ccf44cad3d3b04b39e4dc34eb Modified Files -- src/backend/utils/misc/guc-file.l |6 +++--- 1 file changed, 3 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: Allow a context to be passed in for error handling
Allow a context to be passed in for error handling As pointed out by Tom Lane, we can allow other users of the error handler callbacks to provide their own memory context by adding the context to use to ErrorData and using that instead of explicitly using ErrorContext. This then allows GetErrorContextStack() to be called from inside exception handlers, so modify plpgsql to take advantage of that and add an associated regression test for it. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/ddef1a39c6798ffae899acd08ff92329dd304085 Modified Files -- src/backend/utils/error/elog.c| 126 - src/include/utils/elog.h |3 + src/pl/plpgsql/src/pl_gram.y |4 +- src/test/regress/expected/plpgsql.out | 98 + src/test/regress/sql/plpgsql.sql | 56 +++ 5 files changed, 221 insertions(+), 66 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: Add locking around SSL_context usage in libpq
Add locking around SSL_context usage in libpq I've been working with Nick Phillips on an issue he ran into when trying to use threads with SSL client certificates. As it turns out, the call in initialize_SSL() to SSL_CTX_use_certificate_chain_file() will modify our SSL_context without any protection from other threads also calling that function or being at some other point and trying to read from SSL_context. To protect against this, I've written up the attached (based on an initial patch from Nick and much subsequent discussion) which puts locks around SSL_CTX_use_certificate_chain_file() and all of the other users of SSL_context which weren't already protected. Nick Phillips, much reworked by Stephen Frost Back-patch to 9.0 where we started loading the cert directly instead of using a callback. Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/55754380f36d098551bd55dd49e27f64dd1c8d2f Modified Files -- src/interfaces/libpq/fe-secure.c | 56 -- 1 file changed, 53 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: Add locking around SSL_context usage in libpq
Add locking around SSL_context usage in libpq I've been working with Nick Phillips on an issue he ran into when trying to use threads with SSL client certificates. As it turns out, the call in initialize_SSL() to SSL_CTX_use_certificate_chain_file() will modify our SSL_context without any protection from other threads also calling that function or being at some other point and trying to read from SSL_context. To protect against this, I've written up the attached (based on an initial patch from Nick and much subsequent discussion) which puts locks around SSL_CTX_use_certificate_chain_file() and all of the other users of SSL_context which weren't already protected. Nick Phillips, much reworked by Stephen Frost Back-patch to 9.0 where we started loading the cert directly instead of using a callback. Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/9d7f66bc6c620f8c7548fc65d0e8e160615d5267 Modified Files -- src/interfaces/libpq/fe-secure.c | 56 -- 1 file changed, 53 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: Add locking around SSL_context usage in libpq
Add locking around SSL_context usage in libpq I've been working with Nick Phillips on an issue he ran into when trying to use threads with SSL client certificates. As it turns out, the call in initialize_SSL() to SSL_CTX_use_certificate_chain_file() will modify our SSL_context without any protection from other threads also calling that function or being at some other point and trying to read from SSL_context. To protect against this, I've written up the attached (based on an initial patch from Nick and much subsequent discussion) which puts locks around SSL_CTX_use_certificate_chain_file() and all of the other users of SSL_context which weren't already protected. Nick Phillips, much reworked by Stephen Frost Back-patch to 9.0 where we started loading the cert directly instead of using a callback. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/aad2a630b1b163038ea904e16a59e409020f5828 Modified Files -- src/interfaces/libpq/fe-secure.c | 56 -- 1 file changed, 53 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: Add locking around SSL_context usage in libpq
Add locking around SSL_context usage in libpq I've been working with Nick Phillips on an issue he ran into when trying to use threads with SSL client certificates. As it turns out, the call in initialize_SSL() to SSL_CTX_use_certificate_chain_file() will modify our SSL_context without any protection from other threads also calling that function or being at some other point and trying to read from SSL_context. To protect against this, I've written up the attached (based on an initial patch from Nick and much subsequent discussion) which puts locks around SSL_CTX_use_certificate_chain_file() and all of the other users of SSL_context which weren't already protected. Nick Phillips, much reworked by Stephen Frost Back-patch to 9.0 where we started loading the cert directly instead of using a callback. Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/0b821b8d7c137fbec215f8da286b4a40e53b13d5 Modified Files -- src/interfaces/libpq/fe-secure.c | 56 -- 1 file changed, 53 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: Add locking around SSL_context usage in libpq
Add locking around SSL_context usage in libpq I've been working with Nick Phillips on an issue he ran into when trying to use threads with SSL client certificates. As it turns out, the call in initialize_SSL() to SSL_CTX_use_certificate_chain_file() will modify our SSL_context without any protection from other threads also calling that function or being at some other point and trying to read from SSL_context. To protect against this, I've written up the attached (based on an initial patch from Nick and much subsequent discussion) which puts locks around SSL_CTX_use_certificate_chain_file() and all of the other users of SSL_context which weren't already protected. Nick Phillips, much reworked by Stephen Frost Back-patch to 9.0 where we started loading the cert directly instead of using a callback. Branch -- REL9_0_STABLE Details --- http://git.postgresql.org/pg/commitdiff/f31016365565e03c3c698554eacc1c897fd35049 Modified Files -- src/interfaces/libpq/fe-secure.c | 56 -- 1 file changed, 53 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
