Re: [COMMITTERS] pgsql: Generic Messages for Logical Decoding

On 2016-04-07 12:26:28 +0900, Fujii Masao wrote: > In my example, the WAL record of INSERT that I executed last should be in > 00010005. But pg_xlogdump could not display that. > The output of pg_xlogdump was: > > $ pg_xlogdump data/pg_xlog/00010005 > pg_xlogdump:

[COMMITTERS] pgsql: Remove redundant message in AddUserToTokenDacl().

Remove redundant message in AddUserToTokenDacl(). GetTokenUser() will have reported an adequate error message. These error conditions almost can't happen, so users are unlikely to observe this change. Reviewed by Tom Lane and Stephen Frost. Branch -- master Details ---

[COMMITTERS] pgsql: Standardize GetTokenInformation() error reporting.

Standardize GetTokenInformation() error reporting. Commit c22650cd6450854e1a75064b698d7dcbb4a8821a sparked a discussion about diverse interpretations of "token user" in error messages. Expel old and new specimens of that phrase by making all GetTokenInformation() callers report errors the way

Re: [COMMITTERS] pgsql: Generic Messages for Logical Decoding

On Thu, Apr 7, 2016 at 12:06 AM, Andres Freund wrote: > > > On April 6, 2016 5:00:54 PM GMT+02:00, Fujii Masao > wrote: >>On Wed, Apr 6, 2016 at 6:08 PM, Simon Riggs >>wrote: >>> Generic Messages for Logical Decoding >>> >>> API

Re: [COMMITTERS] pgsql: Use GRANT system to manage access to sensitive functions

On Thu, Apr 7, 2016 at 10:45 AM, Stephen Frost wrote: > Use GRANT system to manage access to sensitive functions > > Now that pg_dump will properly dump out any ACL changes made to > functions which exist in pg_catalog, switch to using the GRANT system > to manage access to

[COMMITTERS] pgsql: Bump catversion for pg_dump dump catalog ACL patches

Bump catversion for pg_dump dump catalog ACL patches Pointed out by Tom. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/29dd1504a12f324c75f6b5ce8863505e499633ec Modified Files -- src/include/catalog/catversion.h | 2 +- 1 file changed, 1 insertion(+), 1

Re: [COMMITTERS] pgsql: Use GRANT system to manage access to sensitive functions

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Use GRANT system to manage access to sensitive functions > > This patch series seems approximately three catversion bumps > shy of a load ... Blargh. I told myself at three different times tonight to

Re: [COMMITTERS] pgsql: Use GRANT system to manage access to sensitive functions

Stephen Frost writes: > Use GRANT system to manage access to sensitive functions This patch series seems approximately three catversion bumps shy of a load ... regards, tom lane -- Sent via pgsql-committers mailing list

Re: [COMMITTERS] pgsql: Use GRANT system to manage access to sensitive functions

On Thu, Apr 7, 2016 at 10:45 AM, Stephen Frost wrote: > Use GRANT system to manage access to sensitive functions > > Now that pg_dump will properly dump out any ACL changes made to > functions which exist in pg_catalog, switch to using the GRANT system > to manage access to

[COMMITTERS] pgsql: In pg_dump, split "dump" into "dump" and "dump_contains"

In pg_dump, split "dump" into "dump" and "dump_contains" Historically, the "dump" component of the namespace has been used to decide if the objects inside of the namespace should be dumped also. Given that "dump" is now a bitmask and may be partial, and we may want to dump out all components of

[COMMITTERS] pgsql: Add new catalog called pg_init_privs

Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on

[COMMITTERS] pgsql: In pg_dump, use a bitmap to represent what to include

In pg_dump, use a bitmap to represent what to include pg_dump has historically used a simple boolean 'dump' value to indicate if a given object should be included in the dump or not. Instead, use a bitmap which breaks down the components of an object into their distinct pieces and use that

[COMMITTERS] pgsql: In pg_dump, include pg_catalog and extension ACLs, if changed

In pg_dump, include pg_catalog and extension ACLs, if changed Now that all of the infrastructure exists, add in the ability to dump out the ACLs of the objects inside of pg_catalog or the ACLs for objects which are members of extensions, but only if they have been changed from their original

[COMMITTERS] pgsql: Use GRANT system to manage access to sensitive functions

Use GRANT system to manage access to sensitive functions Now that pg_dump will properly dump out any ACL changes made to functions which exist in pg_catalog, switch to using the GRANT system to manage access to those functions. This means removing 'if (!superuser()) ereport()' checks from the

Re: [COMMITTERS] pgsql: Implement backup API functions for non-exclusive backups

On Wed, Apr 6, 2016 at 6:38 PM, Tom Lane wrote: > Magnus Hagander writes: > > Implement backup API functions for non-exclusive backups > > Shouldn't the CF entry for this be closed? The docs rewrite > seems like a separate task. > > It should. I forgot,

Re: [COMMITTERS] pgsql: Implement backup API functions for non-exclusive backups

Magnus Hagander writes: > Implement backup API functions for non-exclusive backups Shouldn't the CF entry for this be closed? The docs rewrite seems like a separate task. regards, tom lane -- Sent via pgsql-committers mailing list

[COMMITTERS] pgsql: Add jsonb_insert

Add jsonb_insert It inserts a new value into an jsonb array at arbitrary position or a new key to jsonb object. Author: Dmitry Dolgov Reviewers: Petr Jelinek, Vitaly Burovoy, Andrew Dunstan Branch -- master Details ---

[COMMITTERS] pgsql: pg_dump: Add table qualifications to some tags

pg_dump: Add table qualifications to some tags Some object types have names that are only unique for one table. But for those we generally didn't put the table name into the dump TOC tag. So it was impossible to identify these objects if the same name was used for multiple tables. This affects

[COMMITTERS] pgsql: Run pgindent on a batch of (mostly-planner-related) source files

Run pgindent on a batch of (mostly-planner-related) source files. Getting annoyed at the amount of unrelated chatter I get from pgindent'ing Rowley's unique-joins patch. Re-indent all the files it touches. Branch -- master Details ---

Re: [COMMITTERS] pgsql: Generic Messages for Logical Decoding

On April 6, 2016 5:00:54 PM GMT+02:00, Fujii Masao wrote: >On Wed, Apr 6, 2016 at 6:08 PM, Simon Riggs >wrote: >> Generic Messages for Logical Decoding >> >> API and mechanism to allow generic messages to be inserted into WAL >that are >> intended

Re: [COMMITTERS] pgsql: Generic Messages for Logical Decoding

On Wed, Apr 6, 2016 at 6:08 PM, Simon Riggs wrote: > Generic Messages for Logical Decoding > > API and mechanism to allow generic messages to be inserted into WAL that are > intended to be read by logical decoding plugins. This commit adds an optional > new callback to the

[COMMITTERS] pgsql: Modify test_decoding/messages to remove non-ascii chars

Modify test_decoding/messages to remove non-ascii chars Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/d25379eb23383f1d2f969e65e0332b47c19aea94 Modified Files -- contrib/test_decoding/expected/messages.out | 14 +++---

Re: [COMMITTERS] pgsql: Generic Messages for Logical Decoding

On 6 April 2016 at 14:35, Tom Lane wrote: > Simon Riggs writes: > > Generic Messages for Logical Decoding > > The buildfarm thinks this was a remarkably poor choice of random data > payload: > > SELECT 'žluťoučký kůň' FROM pg_logical_emit_message(true,

Re: [COMMITTERS] pgsql: Generic Messages for Logical Decoding

Simon Riggs writes: > Generic Messages for Logical Decoding The buildfarm thinks this was a remarkably poor choice of random data payload: SELECT 'žluťoučký kůň' FROM pg_logical_emit_message(true, 'test', 'žluťoučký kůň'); ?column? ---

Re: [HACKERS] [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 2016-04-06 14:00:20 +0100, Simon Riggs wrote: > On 6 April 2016 at 13:48, Michael Paquier wrote: > > > > > Yeah... We have reached a clear consensus about the way things should > > be done after quite a lot of discussions that has gone for a couple of > > months.

[COMMITTERS] pgsql: Use proper format specifier %X/%X for LSN, again.

Use proper format specifier %X/%X for LSN, again. Commit cee31f5 fixed this problem, but commit 989be08 accidentally reverted the fix. Thomas Munro Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/ead9963c471ccde50ff220e8294ea11a57eee91c Modified Files

Re: [HACKERS] [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 2016-04-06 13:50:24 +0100, Simon Riggs wrote: > On 6 April 2016 at 13:27, Andres Freund wrote: > > > On 2016-04-06 13:11:40 +0100, Simon Riggs wrote: > > > On 6 April 2016 at 10:09, Andres Freund wrote: > > > > On 2016-04-06 10:04:42 +0100, Simon Riggs

[COMMITTERS] pgsql: Revert bf08f2292ffca14fd133aa0901d1563b6ecd6894

Revert bf08f2292ffca14fd133aa0901d1563b6ecd6894 Remove recent changes to logging XLOG_RUNNING_XACTS by request. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/cac0e36682970ec1276d3da3d3ee37325544a2bb Modified Files -- src/backend/postmaster/bgwriter.c

Re: [HACKERS] [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 6 April 2016 at 13:48, Michael Paquier wrote: > > Yeah... We have reached a clear consensus about the way things should > be done after quite a lot of discussions that has gone for a couple of > months. And Andres' design on the matter is what is getting approval >

Re: [COMMITTERS] pgsql: Generic Messages for Logical Decoding

On Wed, Apr 6, 2016 at 6:08 PM, Simon Riggs wrote: > Generic Messages for Logical Decoding > > API and mechanism to allow generic messages to be inserted into WAL that are > intended to be read by logical decoding plugins. This commit adds an optional > new callback to the

Re: [HACKERS] [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 6 April 2016 at 13:27, Andres Freund wrote: > On 2016-04-06 13:11:40 +0100, Simon Riggs wrote: > > On 6 April 2016 at 10:09, Andres Freund wrote: > > > On 2016-04-06 10:04:42 +0100, Simon Riggs wrote: > > > The issue there is that we continue to issue

Re: [HACKERS] [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On Wed, Apr 6, 2016 at 9:27 PM, Andres Freund wrote: > On 2016-04-06 13:11:40 +0100, Simon Riggs wrote: >> On 6 April 2016 at 10:09, Andres Freund wrote: >> > On 2016-04-06 10:04:42 +0100, Simon Riggs wrote: >> > The issue there is that we continue to

Re: [HACKERS] [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 2016-04-06 13:11:40 +0100, Simon Riggs wrote: > On 6 April 2016 at 10:09, Andres Freund wrote: > > On 2016-04-06 10:04:42 +0100, Simon Riggs wrote: > > The issue there is that we continue to issue checkpoints if the only > > activity since the last checkpoint was emitting a

Re: [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On Wed, Apr 6, 2016 at 8:02 AM, Simon Riggs wrote: >> > We can, if you wish, revert this patch. If we do, we will have nothing, >> > since I object to the other patch(es). >> >> I don't think you have an absolute veto over other patches > > Huh? My understanding is I have

Re: [HACKERS] [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 6 April 2016 at 10:09, Andres Freund wrote: > On 2016-04-06 10:04:42 +0100, Simon Riggs wrote: > > On 6 April 2016 at 09:45, Andres Freund wrote: > > > > > On 2016-04-06 09:18:54 +0100, Simon Riggs wrote: > > > > Rather than take that option, I went to

Re: [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 6 April 2016 at 12:24, Robert Haas wrote: > On Wed, Apr 6, 2016 at 4:18 AM, Simon Riggs wrote: > >> FWIW, I vote also for reverting this patch. This has been committed > >> without any real discussions.. > > > > Michael, its a shame to hear you

Re: [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On Wed, Apr 6, 2016 at 4:18 AM, Simon Riggs wrote: >> FWIW, I vote also for reverting this patch. This has been committed >> without any real discussions.. > > Michael, its a shame to hear you say that, so let me give full context. > > The patches under review in the CF are

Re: [HACKERS] [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 2016-04-06 10:04:42 +0100, Simon Riggs wrote: > On 6 April 2016 at 09:45, Andres Freund wrote: > > > On 2016-04-06 09:18:54 +0100, Simon Riggs wrote: > > > Rather than take that option, I went to the trouble of writing a patch > > that > > > does the same thing but

[COMMITTERS] pgsql: Generic Messages for Logical Decoding

Generic Messages for Logical Decoding API and mechanism to allow generic messages to be inserted into WAL that are intended to be read by logical decoding plugins. This commit adds an optional new callback to the logical decoding API. Messages are either text or bytea. Messages can be

Re: [HACKERS] [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 6 April 2016 at 09:45, Andres Freund wrote: > On 2016-04-06 09:18:54 +0100, Simon Riggs wrote: > > Rather than take that option, I went to the trouble of writing a patch > that > > does the same thing but simpler, less invasive and more maintainable. > > Primarily, I did

Re: [HACKERS] [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 2016-04-06 09:18:54 +0100, Simon Riggs wrote: > Rather than take that option, I went to the trouble of writing a patch that > does the same thing but simpler, less invasive and more maintainable. > Primarily, I did that for you, to avoid you having wasted your time and to > allow you to

[COMMITTERS] pgsql: Support multiple synchronous standby servers.

Support multiple synchronous standby servers. Previously synchronous replication offered only the ability to confirm that all changes made by a transaction had been transferred to at most one synchronous standby server. This commit extends synchronous replication so that it supports multiple

Re: [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 5 April 2016 at 01:18, Michael Paquier wrote: > On Mon, Apr 4, 2016 at 4:50 PM, Andres Freund wrote: > > On 2016-04-04 08:44:47 +0100, Simon Riggs wrote: > >> That patch does exactly the same thing as the patch you prefer, just > >> does it