Re: [HACKERS] identity columns

On Thu, Apr 06, 2017 at 10:26:16PM -0700, Vitaly Burovoy wrote: > On 4/6/17, Peter Eisentraut wrote: > > On 4/4/17 22:53, Vitaly Burovoy wrote: > >> The next nitpickings to the last patch. I try to get places with > >> lacking of variables' initialization. > >>

Re: [HACKERS] Allowing extended stats on foreign and partitioned tables

On Mon, Apr 10, 2017 at 09:39:22PM +1200, David Rowley wrote: > While reviewing extended stats I noticed that it was possible to > create extended stats on many object types, including sequences. I > mentioned that this should be disallowed. Statistics were then changed > to be only allowed on

Re: [HACKERS] Tuplesort merge pre-reading

On Thu, Apr 13, 2017 at 10:19 PM, Peter Geoghegan wrote: > I actually think Heikki's work here would particularly help on > spinning rust, especially when less memory is available. He > specifically justified it on the basis of it resulting in a more > sequential read pattern,

Re: [HACKERS] [pgsql-www] Small issue in online devel documentation build

On Wed, Apr 05, 2017 at 01:43:42PM -0400, Peter Eisentraut wrote: > On 4/5/17 02:56, Noah Misch wrote: > > On Thu, Mar 23, 2017 at 11:21:39PM -0400, Peter Eisentraut wrote: > >> I think the fix belongs into the web site CSS, so there is nothing to > >> commit into PostgreSQL here. I will close

Re: [HACKERS] Tuplesort merge pre-reading

On Thu, Apr 13, 2017 at 9:51 PM, Tom Lane wrote: > I'm fairly sure that the point was exactly what it said, ie improve > locality of access within the temp file by sequentially reading as many > tuples in a row as we could, rather than grabbing one here and one there. > > It

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

Hi Stephen, On 2017/04/14 0:05, Stephen Frost wrote: > Robert, > > * Robert Haas (robertmh...@gmail.com) wrote: >> So I think I was indeed confused before, and I think you're basically >> right here, but on one point I think you are not right -- ALTER TABLE >> ONLY .. CHECK () doesn't work on a

Re: [HACKERS] Tuplesort merge pre-reading

I wrote: > Heikki Linnakangas writes: >> I'm talking about the code that reads a bunch of from each tape, loading >> them into the memtuples array. That code was added by Tom Lane, back in >> 1999: >> So apparently there was a benefit back then, but is it still worthwhile? >

Re: [HACKERS] Tuplesort merge pre-reading

Heikki Linnakangas writes: > I'm talking about the code that reads a bunch of from each tape, loading > them into the memtuples array. That code was added by Tom Lane, back in > 1999: > commit cf627ab41ab9f6038a29ddd04dd0ff0ccdca714e > Author: Tom Lane >

Re: [HACKERS] Foreign Join pushdowns not working properly for outer joins

On Thu, Apr 13, 2017 at 7:35 AM, David Rowley wrote: > On 13 April 2017 at 11:22, Peter Eisentraut > wrote: >> Is this patch considered ready for review as a backpatch candidate? > > Yes, however, the v5 patch is based on master.

Re: [HACKERS] Logical replication and inheritance

On 2017/04/14 10:57, Petr Jelinek wrote: > I don't think inheritance and partitioning should behave the same in > terms of logical replication. I see. > > For me the current behavior with inherited tables is correct. OK. By the way, what do you think about the pg_dump example/issue I

Re: [HACKERS] [PATCH] Remove trailing spaces

On 3/29/17 04:11, Alexander Law wrote: > Please consider committing the attached patches to remove trailing > spaces in strings in the source code. > One patch is for localizable messages, and the other is just for > consistency (less important). committed -- Peter Eisentraut

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add COMMENT and SECURITY LABEL support for publications and subs

On 4/4/17 09:59, Stephen Frost wrote: >> Attached is a patch that adds the pg_dump support, but I'm struggling to >> make the tests work. Could you take a look? Problem one I'm seeing is >> that the tests assert that there are no comments in the post-data >> section, which is no longer the case

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On Fri, Apr 14, 2017 at 1:37 AM, Heikki Linnakangas wrote: > On 04/13/2017 05:53 AM, Michael Paquier wrote: >> +* Parse the list of SASL authentication mechanisms in the >> +* AuthenticationSASL message, and select the best mechanism that we >> +* support. (Only

Re: [HACKERS] Logical replication and inheritance

I don't think inheritance and partitioning should behave the same in terms of logical replication. For me the current behavior with inherited tables is correct. What I would like partitioned tables support to look like is that if we add partitioned table, the data decoded from any of the

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

On 4/13/17 12:11, Robert Haas wrote: > I wonder if we should have an --no-subscriptions option, now that they > are dumped by default, just like we have --no-blobs, --no-owner, > --no-password, --no-privileges, --no-acl, --no-tablespaces, and > --no-security-labels. It seems like there is

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Fri, Apr 14, 2017 at 9:38 AM, Michael Paquier wrote: > On Fri, Apr 14, 2017 at 2:47 AM, Fujii Masao wrote: >> I'm thinking that it's less confusing to report always 0 as the priority of >> async standby whatever the setting of

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

On 13/04/17 18:11, Robert Haas wrote: > On Thu, Apr 13, 2017 at 12:05 PM, Peter Eisentraut > wrote: >> On 4/12/17 18:31, Peter Eisentraut wrote: >>> On 4/11/17 23:41, Noah Misch wrote: On Tue, Apr 11, 2017 at 11:21:24PM -0400, Peter Eisentraut wrote: >

Re: [HACKERS] Declarative partitioning vs. information_schema

On 2017/04/14 5:28, Robert Haas wrote: > On Thu, Apr 6, 2017 at 3:14 AM, Amit Langote > wrote: >>> The bulk of operations that work on traditional tables also work on >>> partitions >>> and partitioned tables. The next closest kind of relation, a materialized >>>

Re: [HACKERS] identity columns

On Thu, Apr 13, 2017 at 7:40 PM, Vitaly Burovoy wrote: > On 4/6/17, Vitaly Burovoy wrote: >> On 4/6/17, Peter Eisentraut wrote: >>> As I tried to mention earlier, it is very difficult to implement the IF >>>

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Fri, Apr 14, 2017 at 2:47 AM, Fujii Masao wrote: > I'm thinking that it's less confusing to report always 0 as the priority of > async standby whatever the setting of synchronous_standby_names is. > Thought? Or we could have priority being reported to NULL for async

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Mon, Apr 3, 2017 at 3:32 PM, Daniel Verite wrote: In interactive mode, the warning in untaken branches is misleading when \endif is on the same line as the commands that are skipped. For instance: postgres=# \if false \echo NOK \endif \echo command ignored;

Re: [HACKERS] logical replication and PANIC during shutdown checkpoint in publisher

On Fri, Apr 14, 2017 at 3:03 AM, Fujii Masao wrote: > On Thu, Apr 13, 2017 at 12:36 PM, Michael Paquier > wrote: >> On Thu, Apr 13, 2017 at 12:28 PM, Fujii Masao wrote: >>> On Thu, Apr 13, 2017 at 5:25 AM, Peter Eisentraut

Re: [HACKERS] Small patch for pg_basebackup argument parsing

On Fri, Apr 14, 2017 at 6:32 AM, Pierre Ducroquet wrote: > Yesterday while doing a few pg_basebackup, I realized that the integer > parameters were not properly checked against invalid input. > It is not a critical issue, but this could be misleading for an user who > writes

Re: [HACKERS] Undefined psql variables

Hello Robert, Calling the server is already available: SELECT AS varname \gset Sure, but people are going to want to do it inline with the \if. Yes... and my changed opinion is that the answer to this approach should be "no", only client side after if. Anything that can be done

Re: [HACKERS] Interval for launching the table sync worker

On 13/04/17 12:23, Masahiko Sawada wrote: > On Thu, Apr 13, 2017 at 11:53 AM, Masahiko Sawada > wrote: >> On Wed, Apr 12, 2017 at 11:46 PM, Peter Eisentraut >> wrote: >>> On 4/12/17 00:48, Masahiko Sawada wrote: On Wed, Apr 12, 2017

Re: [HACKERS] logical replication apply to run with sync commit off by default

On 12/04/17 06:10, Peter Eisentraut wrote: > On 3/24/17 10:49, Petr Jelinek wrote: >> Rebase after table copy patch got committed. > > You could please sent another rebase of this, perhaps with some more > documentation, as discussed downthread. > > Also, I wonder why we don't offer the other

[HACKERS] Small patch for pg_basebackup argument parsing

Hi Yesterday while doing a few pg_basebackup, I realized that the integer parameters were not properly checked against invalid input. It is not a critical issue, but this could be misleading for an user who writes -z max or -s 0.5… I've attached the patch to this mail. Should I add it to the next

Re: [HACKERS] Row Level Security UPDATE Confusion

Rod, all, * Joe Conway (m...@joeconway.com) wrote: > On 04/13/2017 01:31 PM, Stephen Frost wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > >> On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor wrote: > >> > I'm a little confused on why a SELECT policy fires against the

Re: [HACKERS] Row Level Security UPDATE Confusion

On 04/13/2017 01:31 PM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor wrote: >> > I'm a little confused on why a SELECT policy fires against the NEW record >> > for an UPDATE when using multiple FOR

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

On 2017-04-13 14:05:43 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-04-13 12:56:14 -0400, Tom Lane wrote: > >> Andres Freund writes: > >>> Cool. I wonder if we also should remove AtEOXact_CatCache()'s > >>> cross-checks - the resowner

Re: [HACKERS] [POC] hash partitioning

On Fri, Mar 17, 2017 at 7:57 AM, Yugo Nagata wrote: > I also understanded that my design has a problem during pg_dump and > pg_upgrade, and that some information to identify the partition > is required not depending the command order. However, I feel that > Amul's design is a

Re: [HACKERS] Quals not pushed down into lateral

On 2017-04-13 16:34:12 -0400, Robert Haas wrote: > On Thu, Mar 16, 2017 at 4:45 AM, Andres Freund wrote: > > During citus development we noticed that restrictions aren't pushed down > > into lateral subqueries, even if they semantically could. For example, > > in this dumbed

Re: [HACKERS] Quals not pushed down into lateral

On Thu, Mar 16, 2017 at 4:45 AM, Andres Freund wrote: > During citus development we noticed that restrictions aren't pushed down > into lateral subqueries, even if they semantically could. For example, > in this dumbed down example: > > postgres[31776][1]=# CREATE TABLE

Re: [HACKERS] Row Level Security UPDATE Confusion

* Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor wrote: > > I'm a little confused on why a SELECT policy fires against the NEW record > > for an UPDATE when using multiple FOR policies. The ALL policy doesn't seem > > to have that

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Mon, Apr 3, 2017 at 3:32 PM, Daniel Verite wrote: > In interactive mode, the warning in untaken branches is misleading > when \endif is on the same line as the commands that > are skipped. For instance: > > postgres=# \if false \echo NOK \endif > \echo command

Re: [HACKERS] Declarative partitioning vs. information_schema

On Thu, Apr 6, 2017 at 3:14 AM, Amit Langote wrote: >> The bulk of operations that work on traditional tables also work on >> partitions >> and partitioned tables. The next closest kind of relation, a materialized >> view, is far less table-like. Therefore, I

Re: [HACKERS] pg_upgrade vs extension upgrades

On Thu, Apr 13, 2017 at 3:48 PM, Magnus Hagander wrote: >> Well, pg_upgrade creates ./analyze_new_cluster.sh, but that just >> contains: >> >> "/u/pgsql/bin/vacuumdb" --all --analyze-in-stages >> >> Seems like we should just get rid of ./analyze_new_cluster.sh and

Re: [HACKERS] Row Level Security UPDATE Confusion

On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor wrote: > I'm a little confused on why a SELECT policy fires against the NEW record > for an UPDATE when using multiple FOR policies. The ALL policy doesn't seem > to have that restriction. My guess is that you have found a bug. --

Re: [HACKERS] pg_upgrade vs extension upgrades

On Thu, Apr 13, 2017 at 9:13 PM, Bruce Momjian wrote: > On Thu, Apr 13, 2017 at 09:02:27PM +0200, Magnus Hagander wrote: > > On Thu, Apr 13, 2017 at 12:30 AM, Peter Eisentraut < > > peter.eisentr...@2ndquadrant.com> wrote: > > > > On 4/10/17 11:30, Magnus Hagander wrote: >

[HACKERS] some review comments on logical rep code

Hi, Though I've read only a part of the logical rep code yet, I'd like to share some (relatively minor) review comments that I got so far. In ApplyWorkerMain(), DatumGetInt32() should be used to get integer value from the argument, instead of DatumGetObjectId(). No one resets

Re: [HACKERS] pg_upgrade vs extension upgrades

On Thu, Apr 13, 2017 at 09:02:27PM +0200, Magnus Hagander wrote: > On Thu, Apr 13, 2017 at 12:30 AM, Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: > > On 4/10/17 11:30, Magnus Hagander wrote: > > After you've run pg_upgrade, you have to loop through all your databases >

Re: [HACKERS] pg_upgrade vs extension upgrades

On Thu, Apr 13, 2017 at 6:06 PM, Robert Haas wrote: > On Thu, Apr 13, 2017 at 11:48 AM, Peter Eisentraut > wrote: > > On 4/12/17 22:56, Bruce Momjian wrote: > >> Is pg_upgrade the right place for an extension upgrade script? When > >>

Re: [HACKERS] pg_upgrade vs extension upgrades

On Thu, Apr 13, 2017 at 12:30 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 4/10/17 11:30, Magnus Hagander wrote: > > After you've run pg_upgrade, you have to loop through all your databases > > and do an "ALTER EXTENSION abc UPDATE" once for each extension. > > > > Is

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

Andres Freund writes: > On 2017-04-13 12:56:14 -0400, Tom Lane wrote: >> Andres Freund writes: >>> Cool. I wonder if we also should remove AtEOXact_CatCache()'s >>> cross-checks - the resowner replacement has been in place for a while, >>> and seems

Re: [HACKERS] Undefined psql variables

2017-04-13 19:46 GMT+02:00 Corey Huinker : > >> > I suggest to reuse pgbench expression engine, developed by Haas >> Robert:-) >> >> Not a bad idea (though I'm sure there are other reasonable options, too). >> >> > I don't want to stand in the way of any progress in

Re: [HACKERS] logical replication and PANIC during shutdown checkpoint in publisher

On Thu, Apr 13, 2017 at 12:36 PM, Michael Paquier wrote: > On Thu, Apr 13, 2017 at 12:28 PM, Fujii Masao wrote: >> On Thu, Apr 13, 2017 at 5:25 AM, Peter Eisentraut >> wrote: >>> On 4/12/17 09:55, Fujii Masao

Re: [HACKERS] Interval for launching the table sync worker

On 13/04/17 13:01, Kyotaro HORIGUCHI wrote: > Ouch! I replied to wrong mail. > > At Thu, 13 Apr 2017 19:55:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > wrote in > <20170413.195504.89348773.horiguchi.kyot...@lab.ntt.co.jp> >> I confused sync and apply

Re: [HACKERS] snapbuild woes

On 13/04/17 07:02, Andres Freund wrote: > > On April 12, 2017 9:58:12 PM PDT, Noah Misch wrote: >> On Wed, Apr 12, 2017 at 10:21:51AM -0700, Andres Freund wrote: >>> On 2017-04-12 11:03:57 -0400, Peter Eisentraut wrote: On 4/12/17 02:31, Noah Misch wrote: >>> But I

Re: [HACKERS] snapbuild woes

Thanks for looking at this! On 13/04/17 02:29, Andres Freund wrote: > Hi, > On 2017-03-03 01:30:11 +0100, Petr Jelinek wrote: > >> From 7d5b48c8cb80e7c867b2096c999d08feda50b197 Mon Sep 17 00:00:00 2001 >> From: Petr Jelinek >> Date: Fri, 24 Feb 2017 21:39:03 +0100 >>

Re: [HACKERS] Undefined psql variables

> > > I suggest to reuse pgbench expression engine, developed by Haas Robert:-) > > Not a bad idea (though I'm sure there are other reasonable options, too). > I checked the pgbench code - and I think it can work well - just add logical operators and compare operators. Don't need to create more

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Thu, Apr 13, 2017 at 9:23 PM, Masahiko Sawada wrote: > On Thu, Apr 13, 2017 at 5:17 PM, Kyotaro HORIGUCHI > wrote: >> Hello, >> >> At Thu, 6 Apr 2017 16:17:31 +0900, Masahiko Sawada >> wrote in

Re: [HACKERS] Undefined psql variables

> > > > I suggest to reuse pgbench expression engine, developed by Haas Robert:-) > > Not a bad idea (though I'm sure there are other reasonable options, too). > > I don't want to stand in the way of any progress in getting expressions into \if and some subspecies of \set. But, assuming we don't

Re: [HACKERS] bugfix: xpath encoding issue

2017-04-13 17:19 GMT+02:00 Alvaro Herrera : > Pavel Stehule wrote: > > Hi > > > > When I tested XMLTABLE function I found a bug of XPATH function - > > xpath_internal > > > > There xmltype is not correctly encoded to xmlChar due possible invalid > > encoding info in

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On Fri, Apr 14, 2017 at 1:28 AM, Peter Eisentraut wrote: > On 4/10/17 13:28, Fujii Masao wrote: >> src/backend/replication/logical/launcher.c >> * Worker started and attached to our shmem. This check is safe >> * because only launcher

Re: [HACKERS] Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

Robert Haas writes: > So I'm not sure what the right thing to do here is. Andres' points about composite vs noncomposite function result types seem pretty compelling: we could make the behavior better for scalar results, but if it then diverges from what happens for

Re: [HACKERS] Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

On 2017-04-13 12:53:27 -0400, Robert Haas wrote: > On Wed, Apr 12, 2017 at 6:58 PM, Andres Freund wrote: > > This yields plenty weird behaviour in < v10. E.g. the following is > > disallowed: > > SELECT * FROM int4mul(generate_series(1,3), 1); > > ERROR: 0A000: set-valued

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

On 2017-04-13 12:56:14 -0400, Tom Lane wrote: > Andres Freund writes: > > Cool. I wonder if we also should remove AtEOXact_CatCache()'s > > cross-checks - the resowner replacement has been in place for a while, > > and seems robust enough. They're now the biggest user of

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On Thu, Apr 21, 2016 at 10:53 AM, Robert Haas wrote: > On Thu, Apr 21, 2016 at 8:44 AM, Michael Paquier > wrote: >> On Thu, Apr 21, 2016 at 5:22 PM, Etsuro Fujita >> wrote: >>> Attached is an updated version of the

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

Andres Freund writes: > Cool. I wonder if we also should remove AtEOXact_CatCache()'s > cross-checks - the resowner replacement has been in place for a while, > and seems robust enough. They're now the biggest user of time. Hm, biggest user of time in what workload? I've

Re: [HACKERS] Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

On Wed, Apr 12, 2017 at 6:58 PM, Andres Freund wrote: > This yields plenty weird behaviour in < v10. E.g. the following is > disallowed: > SELECT * FROM int4mul(generate_series(1,3), 1); > ERROR: 0A000: set-valued function called in context that cannot accept a > set >

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

On 2017-04-13 12:13:30 -0400, Tom Lane wrote: > Andreas Karlsson writes: > > Here is my proof of concept patch. It does basically the same thing as > > Andres's patch except that it handles quoted values a bit better and > > does not try to support anything other than the

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 04/13/2017 05:53 AM, Michael Paquier wrote: Thanks for the updated patches! I had a close look at them. Let's begin with 0001... /* * Negotiation generated data to be sent to the client. */ - elog(DEBUG4, "sending SASL response token of length

Re: [HACKERS] pg_statistic_ext.staenabled might not be the best column name

Tom Lane wrote: > Peter Eisentraut writes: > > On 4/13/17 08:37, Heikki Linnakangas wrote: > >> We have a bunch of > 3-character prefixes already: amop*, amproc*, > >> enum*, cast*. But I think I nevertheless like "ste" better. > > > "stx" perhaps? > > > I

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 4/10/17 13:28, Fujii Masao wrote: > src/backend/replication/logical/launcher.c > * Worker started and attached to our shmem. This check is safe > * because only launcher ever starts the workers, so nobody can steal > * the worker slot. > > The tablesync

Re: [HACKERS] Undefined psql variables

On Thu, Apr 13, 2017 at 8:56 AM, Fabien COELHO wrote: > Calling the server is already available: > > SELECT AS varname \gset Sure, but people are going to want to do it inline with the \if. Anything that can be done that way can also be done this way, but people will want

Re: [HACKERS] pg_statistic_ext.staenabled might not be the best column name

Peter Eisentraut writes: > On 4/13/17 08:37, Heikki Linnakangas wrote: >> We have a bunch of > 3-character prefixes already: amop*, amproc*, >> enum*, cast*. But I think I nevertheless like "ste" better. > "stx" perhaps? > I would also be in favor of changing

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

Andreas Karlsson writes: > Here is my proof of concept patch. It does basically the same thing as > Andres's patch except that it handles quoted values a bit better and > does not try to support anything other than the regproc type. > The patch speeds up initdb without fsync

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

On Thu, Apr 13, 2017 at 12:05 PM, Peter Eisentraut wrote: > On 4/12/17 18:31, Peter Eisentraut wrote: >> On 4/11/17 23:41, Noah Misch wrote: >>> On Tue, Apr 11, 2017 at 11:21:24PM -0400, Peter Eisentraut wrote: On 4/9/17 22:16, Noah Misch wrote: >

Re: [HACKERS] pg_upgrade vs extension upgrades

On Thu, Apr 13, 2017 at 11:48 AM, Peter Eisentraut wrote: > On 4/12/17 22:56, Bruce Momjian wrote: >> Is pg_upgrade the right place for an extension upgrade script? When >> pg_upgrade started creating an incremental-analyze script, people >> thought it should be

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

On 4/12/17 18:31, Peter Eisentraut wrote: > On 4/11/17 23:41, Noah Misch wrote: >> On Tue, Apr 11, 2017 at 11:21:24PM -0400, Peter Eisentraut wrote: >>> On 4/9/17 22:16, Noah Misch wrote: [Action required within three days. This is a generic notification.] >>> >>> Patches have been posted.

Re: [HACKERS] pg_statistic_ext.staenabled might not be the best column name

On 4/13/17 08:37, Heikki Linnakangas wrote: >> We could go with "ste" perhaps, or break the convention of 3-character >> prefixes and go with "stae". > We have a bunch of > 3-character prefixes already: amop*, amproc*, > enum*, cast*. But I think I nevertheless like "ste" better. "stx" perhaps?

Re: [HACKERS] pg_upgrade vs extension upgrades

On 4/12/17 22:56, Bruce Momjian wrote: > Is pg_upgrade the right place for an extension upgrade script? When > pg_upgrade started creating an incremental-analyze script, people > thought it should be more generic so it was moved to vacuumdb > --analyze-in-stages. Seems we should do the same

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

On Thu, Apr 13, 2017 at 11:05 AM, Stephen Frost wrote: > Sure, though I won't be able to today and I've got some doubts about the > other patches. I'll have more time tomorrow though. OK, cool. I'll mark you down as the owner on the open items list. -- Robert Haas

Re: [HACKERS] bugfix: xpath encoding issue

Pavel Stehule wrote: > Hi > > When I tested XMLTABLE function I found a bug of XPATH function - > xpath_internal > > There xmltype is not correctly encoded to xmlChar due possible invalid > encoding info in header. It is possible when XML was loaded with recv > function and has not UTF8

Re: [HACKERS] Small doc fix for xmltable

Arjen Nienhuis wrote: > Hi, > > In the devel docs for xmltable there should be a comma after XMLNAMESPACES() Thanks, pushed. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing

Re: [HACKERS] example for xmltable with XMLNAMESPACES

Arjen Nienhuis wrote: > It wasn't completely clear for me how to use namespaces in xmltable(). > Maybe add this to the documentation. It shows the default namespace > and quoting the namespace name. Thanks, pushed. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] xmltable doc fix and example for XMLNAMESPACES

Pavel Stehule wrote: > Hi > > I am sending a patch with changes in XMLTABLE documentation proposed by > Arjen. Thanks, pushed with some rewording. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > So I think I was indeed confused before, and I think you're basically > right here, but on one point I think you are not right -- ALTER TABLE > ONLY .. CHECK () doesn't work on a table with inheritance children > regardless of whether the

Re: [HACKERS] pg_stats_ext view does not seem all that useful

Tomas Vondra wrote: > On 04/10/2017 12:12 PM, David Rowley wrote: > > During my review and time spent working on the functional dependencies > > part of extended statistics I wondered what was the use for the > > pg_stats_ext view. I was unsure why the length of the serialised > > dependencies was

Re: [HACKERS] Shouldn't duplicate addition to publication be a no-op?

On Thu, Apr 13, 2017 at 9:33 PM, Tom Lane wrote: > Amit Langote writes: >> I wonder if trying to add a relation to a publication that it is already a >> part should be considered a no-op, instead of causing an error (which >> happens in the

Re: [HACKERS] Undefined psql variables

Hello Robert, My 0.02€ about your interesting questions and points. On Sun, Apr 2, 2017 at 3:56 PM, Tom Lane wrote: So my view of this is that "send the expression to the server" ought to be just one option for \if, not the only way to do it. I heartily agree. There

Re: [HACKERS] pg_statistic_ext.staenabled might not be the best column name

On 04/13/2017 03:28 PM, Tom Lane wrote: Tomas Vondra writes: On 04/12/2017 03:36 PM, David Rowley wrote: "stakind" seems like a better name. I'd have personally gone with "statype" but pg_statistic already thinks stakind is better. +1 to stakind I agree with

Re: [HACKERS] Shouldn't duplicate addition to publication be a no-op?

Amit Langote writes: > I wonder if trying to add a relation to a publication that it is already a > part should be considered a no-op, instead of causing an error (which > happens in the ALTER PUBLICATION ADD TABLES case). On what grounds? The equivalent case for

Re: [HACKERS] [PATCH] Document the order of changing certain settings when using hot-standby servers

Aleksander, > What you actually meant probably was "do so on ALL standby servers > first", right? Good point, right now it can give you the idea that applying it to just 1 standby (instead of all of them) is good enough, when instead you need to apply it to all of them. Attached is an adjusted

Re: [HACKERS] pg_statistic_ext.staenabled might not be the best column name

Tomas Vondra writes: > On 04/12/2017 03:36 PM, David Rowley wrote: >> "stakind" seems like a better name. I'd have personally gone with >> "statype" but pg_statistic already thinks stakind is better. > +1 to stakind I agree with that, but as long as we're

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Thu, Apr 13, 2017 at 5:17 PM, Kyotaro HORIGUCHI wrote: > Hello, > > At Thu, 6 Apr 2017 16:17:31 +0900, Masahiko Sawada > wrote in

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

My only desire would be to have a final spec and implement the full parser now, not have to change it in the future. We already know today all the requirements, so please pick one and I will follow it :) On Apr 13, 2017 13:47, "Heikki Linnakangas" wrote: > On 04/13/2017 02:35

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 04/13/2017 02:35 PM, Álvaro Hernández Tortosa wrote: On 13/04/17 13:24, Heikki Linnakangas wrote: Right, when we get channel binding, the server will list "SCRAM-SHA-256" and "SCRAM-SHA-256-PLUS" as the list of mechanisms. And if we get channel binding using something else than tls-unique,

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 13/04/17 04:54, Michael Paquier wrote: On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa wrote: By looking at the them, and unless I'm missing something, I don't see how the extra information for the future implementation of channel binding would be added

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 13/04/17 13:24, Heikki Linnakangas wrote: On 04/13/2017 05:54 AM, Michael Paquier wrote: On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa wrote: By looking at the them, and unless I'm missing something, I don't see how the extra information for the future

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 04/13/2017 05:54 AM, Michael Paquier wrote: On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa wrote: By looking at the them, and unless I'm missing something, I don't see how the extra information for the future implementation of channel binding would be added

Re: [HACKERS] Interval for launching the table sync worker

Ouch! I replied to wrong mail. At Thu, 13 Apr 2017 19:55:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20170413.195504.89348773.horiguchi.kyot...@lab.ntt.co.jp> > I confused sync and apply workers. > sync worker failure at start causes immediate

Re: [HACKERS] Interval for launching the table sync worker

I confused sync and apply workers. sync worker failure at start causes immediate retries. At Thu, 13 Apr 2017 11:53:27 +0900, Masahiko Sawada wrote in > On Wed, Apr 12, 2017 at 11:46 PM, Peter Eisentraut

Re: [HACKERS] Logical replication and inheritance

On 2017/04/13 0:10, Robert Haas wrote: > On Wed, Apr 5, 2017 at 8:25 AM, Peter Eisentraut > wrote: >> After thinking about it some more, I think the behavior we want would be >> that changes to inheritance would reflect in the publication membership. >> So if

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Thu, Apr 13, 2017 at 10:04 PM, Oleg Golovanov wrote: > bash-4.2$ grep Hunk *.log | grep FAILED > 0005-hj-leader-gate-v11.patch.log:Hunk #1 FAILED at 14. > 0010-hj-parallel-v11.patch.log:Hunk #2 FAILED at 2850. > 0010-hj-parallel-v11.patch.log:Hunk #1 FAILED at 21. >

Re: [HACKERS] sequence data type

On 4/4/17, Peter Eisentraut wrote: > On 3/30/17 22:47, Vitaly Burovoy wrote: >> It seemed not very hard to fix it. >> Please find attached patch to be applied on top of your one. >> >> I've added more tests to cover different cases of changing bounds when >> data

Re: [HACKERS] identity columns

On 4/6/17, Vitaly Burovoy wrote: > On 4/6/17, Peter Eisentraut wrote: >> As I tried to mention earlier, it is very difficult to implement the IF >> NOT EXISTS behavior here, because we need to run the commands the create >> the sequence

Re: [HACKERS] Interval for launching the table sync worker

On Thu, Apr 13, 2017 at 11:53 AM, Masahiko Sawada wrote: > On Wed, Apr 12, 2017 at 11:46 PM, Peter Eisentraut > wrote: >> On 4/12/17 00:48, Masahiko Sawada wrote: >>> On Wed, Apr 12, 2017 at 1:28 PM, Peter Eisentraut Perhaps instead

[HACKERS] Shouldn't duplicate addition to publication be a no-op?

I wonder if trying to add a relation to a publication that it is already a part should be considered a no-op, instead of causing an error (which happens in the ALTER PUBLICATION ADD TABLES case). create table bar (a int); create publication mypub for table bar; alter publication mypub add table

[HACKERS] Re: [HACKERS] WIP: [[Parallel] Shared] Hash

Hi. I got errors of patching on CentOS 7: bash-4.2$ grep Hunk *.log | grep FAILED 0005-hj-leader-gate-v11.patch.log:Hunk #1 FAILED at 14. 0010-hj-parallel-v11.patch.log:Hunk #2 FAILED at 2850. 0010-hj-parallel-v11.patch.log:Hunk #1 FAILED at 21. 0010-hj-parallel-v11.patch.log:Hunk #3 FAILED at

  1   2   >