Re: [HACKERS] Logical Replication WIP

today. > > How should these patches be applied (and at what level)? > > 20161208: 0001-Add-support-for-temporary-replication-slots__petere.patch > # petere > 20161202: 0002-Add-PUBLICATION-catalogs-and-DDL-v11.patch # PJ > 20161209: 0001-fixup-Add-PUBLICATION-catalogs-

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On Fri, Dec 9, 2016 at 10:01 PM, Robert Haas wrote: > On Fri, Dec 9, 2016 at 5:55 PM, Keith Fiske wrote: > > Another suggestion I had was for handling when data is inserted that > doesn't > > match any defined child tables. Right now it just errors out,

Re: [HACKERS] proposal: psql statements \gstore \gstore_binary (instead COPY RAW)

2016-12-10 2:27 GMT+01:00 Jim Nasby : > On 12/9/16 9:39 AM, Pavel Stehule wrote: > >> >> SELECT image FROM accounts WHERE id = xxx >> \gstore_binary ~/image.png >> >> What do you think about this proposal? >> > > Seems reasonable. > > I've lost track at this point... is

Re: [HACKERS] Patch to implement pg_current_logfile() function

Hi Gilles, On Fri, 9 Dec 2016 23:41:25 +0100 Gilles Darold wrote: > /* extract log format and log file path from the line */ > log_filepath = strchr(lbuffer, ' '); > log_filepath++; >

Re: [HACKERS] Time to retire Windows XP buildfarm host?

On 12/05/2016 11:38 AM, Andrew Dunstan wrote: On 12/05/2016 11:17 AM, Tom Lane wrote: Andrew Dunstan writes: Windows XP has been past end of life for quite some time. Nevertheless I have kept my instance running with three buildfarm members: frogmouth, currawong and

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On Fri, Dec 9, 2016 at 5:55 PM, Keith Fiske wrote: > Another suggestion I had was for handling when data is inserted that doesn't > match any defined child tables. Right now it just errors out, but in > pg_partman I'd had it send the data to the parent instead to avoid data >

Re: [HACKERS] proposal: psql statements \gstore \gstore_binary (instead COPY RAW)

On 12/09/2016 08:27 PM, Jim Nasby wrote: On 12/9/16 9:39 AM, Pavel Stehule wrote: SELECT image FROM accounts WHERE id = xxx \gstore_binary ~/image.png What do you think about this proposal? Seems reasonable. I've lost track at this point... is there a way to go the other direction with

Re: [HACKERS] proposal: psql statements \gstore \gstore_binary (instead COPY RAW)

On 12/9/16 9:39 AM, Pavel Stehule wrote: SELECT image FROM accounts WHERE id = xxx \gstore_binary ~/image.png What do you think about this proposal? Seems reasonable. I've lost track at this point... is there a way to go the other direction with that as well? Namely, stick the contents of

Re: [HACKERS] Macro customizable hashtable / bitmapscan & aggregation perf

Hi, On 2016-12-09 15:21:36 -0800, Mark Dilger wrote: > Andres, > > Your patch, below, appears to have been applied to master in commit > 5dfc198146b49ce7ecc8a1fc9d5e171fb75f6ba5. It makes mention of a > function, tuplehash_start_iterate, in a macro, but the function is not > defined or

Re: [HACKERS] Macro customizable hashtable / bitmapscan & aggregation perf

Andres, Your patch, below, appears to have been applied to master in commit 5dfc198146b49ce7ecc8a1fc9d5e171fb75f6ba5. It makes mention of a function, tuplehash_start_iterate, in a macro, but the function is not defined or declared, and its signature and intention is not clear. Is there any

Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument

On Fri, Oct 21, 2016 at 4:45 PM, Peter Geoghegan wrote: > More importantly, there are no remaining cases where > tuplesort_gettuple_common() sets "*should_free = true", because there > is no remaining need for caller to *ever* pfree() tuple. Moreover, I > don't anticipate any

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On Fri, Dec 9, 2016 at 1:23 PM, Keith Fiske wrote: > > > On Fri, Dec 9, 2016 at 1:13 PM, Amit Langote > wrote: > >> Hi Keith, >> >> On Sat, Dec 10, 2016 at 3:00 AM, Keith Fiske wrote: >> > Being that table partitioning is something

Re: [HACKERS] Patch to implement pg_current_logfile() function

Le 08/12/2016 à 00:52, Robert Haas a écrit : > On Tue, Dec 6, 2016 at 6:11 PM, Gilles Darold > wrote: >> It seems that all fixes have been included in this patch. > Yikes. This patch has certainly had a lot of review, but it has lots > of basic inconsistencies with

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation

On Fri, Dec 9, 2016 at 12:26 PM, Ian Jackson wrote: > In summary: PostgreSQL only provides transaction serialisability for > successful transactions. Even with SERIALIZABLE, transactions may > fail due to spurious and "impossible" constraint violations. > > As a

Re: [HACKERS] Logical Replication WIP

-slots__petere.patch # petere 20161202: 0002-Add-PUBLICATION-catalogs-and-DDL-v11.patch # PJ 20161209: 0001-fixup-Add-PUBLICATION-catalogs-and-DDL.patch # petere 20161202: 0003-Add-SUBSCRIPTION-catalog-and-DDL-v11.patch # PJ 20161202: 0004-Define-logical-replication-protocol-and-output-plugi-v11

Re: [HACKERS] Fix for segfault in plpython's exception handling

I wrote: > Rafa de la Torre writes: >> exc = PyErr_NewException(exception_map[i].name, base, dict); >> +Py_INCREF(exc); >> PyModule_AddObject(mod, exception_map[i].classname, exc); > Hm. Seems like if this is a problem, the code for the

Re: [HACKERS] new table partitioning breaks \d table to older versions

On Fri, Dec 9, 2016 at 10:18 AM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > > On Fri, Dec 9, 2016 at 3:59 PM, Jeff Janes wrote: > > > > Since: > > > > commit f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 > > Author: Robert Haas > > Date:

Re: [HACKERS] proposal: psql statements \gstore \gstore_binary (instead COPY RAW)

2016-12-09 19:48 GMT+01:00 Oleksandr Shulgin : > On Dec 9, 2016 18:40, "Pavel Stehule" wrote: > > Hi > > Long time I am pushing a COPY RAW - without success. > > Now I propose functionally similar solution - reduced to only to psql > console

Re: [HACKERS] proposal: psql statements \gstore \gstore_binary (instead COPY RAW)

On Dec 9, 2016 18:40, "Pavel Stehule" wrote: Hi Long time I am pushing a COPY RAW - without success. Now I propose functionally similar solution - reduced to only to psql console Now we have a statement \g for execution query, \gset for exec and store result in memory

[HACKERS] [OSSTEST PATCH 1/1] PostgreSQL db: Retry transactions on constraint failures

This is unfortunate but appears to be necessary. Signed-off-by: Ian Jackson CC: pgsql-hackers@postgresql.org --- Osstest/JobDB/Executive.pm | 45 - tcl/JobDB-Executive.tcl| 6 -- 2 files changed, 48 insertions(+), 3

[HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation

Hi. This message is going to xen-devel (because that's where the osstest project is) and to pgsql-hackers (because I hope they may be able to advise about the scope of the PostgreSQL SERIALIZABLE constraint problem). In summary: PostgreSQL only provides transaction serialisability for successful

Re: [HACKERS] new table partitioning breaks \d table to older versions

On Sat, Dec 10, 2016 at 2:59 AM, Jeff Janes wrote: > Since: > > commit f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 > Author: Robert Haas > Date: Wed Dec 7 13:17:43 2016 -0500 > > Implement table partitioning. > > If I use psql compiled from 10devel

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On Fri, Dec 9, 2016 at 1:13 PM, Amit Langote wrote: > Hi Keith, > > On Sat, Dec 10, 2016 at 3:00 AM, Keith Fiske wrote: > > Being that table partitioning is something I'm slightly interested in, > > figured I'd give it a whirl. > > > > This example in

Re: [HACKERS] new table partitioning breaks \d table to older versions

On Fri, Dec 9, 2016 at 3:59 PM, Jeff Janes wrote: > > Since: > > commit f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 > Author: Robert Haas > Date: Wed Dec 7 13:17:43 2016 -0500 > > Implement table partitioning. > > If I use psql compiled from 10devel

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

Hi Keith, On Sat, Dec 10, 2016 at 3:00 AM, Keith Fiske wrote: > Being that table partitioning is something I'm slightly interested in, > figured I'd give it a whirl. > > This example in the docs has an extraneous comma after the second column > > CREATE TABLE cities ( >

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On Wed, Dec 7, 2016 at 1:30 PM, Robert Haas wrote: > On Wed, Dec 7, 2016 at 1:20 PM, Robert Haas wrote: > > Implement table partitioning. > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your

[HACKERS] new table partitioning breaks \d table to older versions

Since: commit f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 Author: Robert Haas Date: Wed Dec 7 13:17:43 2016 -0500 Implement table partitioning. If I use psql compiled from 10devel to connect to a 9.6.1 server, then \d fails: psql (10devel-f0e4475, server

Re: [HACKERS] jsonb problematic operators

On 2016-12-09 12:17:32 -0500, Robert Haas wrote: > As Geoff says, you don't have to use the operators; you could use the > equivalent functions instead. Every operator just gets turned into a > function call internally, so this is always possible. Well, except that only operators support

Re: [HACKERS] jsonb problematic operators

On Fri, Dec 9, 2016 at 10:17 AM, Robert Haas wrote: > > As Geoff says, you don't have to use the operators; you could use the > equivalent functions instead. Every operator just gets turned into a > function call internally, so this is always possible. > In most cases -

[HACKERS] proposal: psql statements \gstore \gstore_binary (instead COPY RAW)

Hi Long time I am pushing a COPY RAW - without success. Now I propose functionally similar solution - reduced to only to psql console Now we have a statement \g for execution query, \gset for exec and store result in memory and I propose \gstore for storing result in file and \gstore_binary for

Re: [HACKERS] jsonb problematic operators

On Fri, Dec 9, 2016 at 5:50 AM, Jordan Gigov wrote: > There is this problem with the jsonb operators "? text" "?| text[]" > and "?& text[]" that the question mark is typically used for prepared > statement parameters in the most used abstraction APIs in Java and > PHP. > >

Re: [HACKERS] jsonb problematic operators

On Fri, Dec 9, 2016 at 6:50 AM, Jordan Gigov wrote: > It's not a good idea to expect everyone else to make for workarounds > for problems you choose to create. True. I actually kinda agree that the use of ? wasn't a great choice here, precisely because a number of drivers do

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Daniel Verite wrote: > My tests are OK too but I see an issue with the code in > enlargeStringInfo(), regarding integer overflow. > The bit of comment that says: > > Note we are assuming here that limit <= INT_MAX/2, else the above > loop could overflow. > > is obsolete, it's now INT_MAX

Re: [HACKERS] Logical Replication WIP

Here is a "fixup" patch for 0002-Add-PUBLICATION-catalogs-and-DDL-v11.patch.gz with some minor fixes. Two issues that should be addressed: 1. I think ALTER PUBLICATION does not need to require CREATE privilege on the database. That should be easy to change. 2. By requiring only SELECT

Re: [HACKERS] building HEAD on macos fails with #error no source of random numbers configured

On 12/09/2016 05:43 PM, Tom Lane wrote: Dave Cramer writes: Looking at src/port/pg_strong_random.c this would be a bug in autoconf It looks more like self-inflicted damage from here: ./configure --prefix=/usr/local/pgsql/10 --enable-debug --with-python --with-openssl

Re: [HACKERS] Fix for segfault in plpython's exception handling

Rafa de la Torre writes: > exc = PyErr_NewException(exception_map[i].name, base, dict); > + Py_INCREF(exc); > PyModule_AddObject(mod, exception_map[i].classname, exc); Hm. Seems like if this is a problem, the code for the other three

Re: [HACKERS] jsonb problematic operators

On Fri, Dec 9, 2016 at 4:50 AM, Jordan Gigov wrote: > There is this problem with the jsonb operators "? text" "?| text[]" > and "?& text[]" that the question mark is typically used for prepared > statement parameters in the most used abstraction APIs in Java and > PHP. >

Re: [HACKERS] building HEAD on macos fails with #error no source of random numbers configured

That will teach me to copy and paste a config from somewhere ... Thanks Dave Cramer On 9 December 2016 at 10:43, Tom Lane wrote: > Dave Cramer writes: > > Looking at src/port/pg_strong_random.c this would be a bug in autoconf > > It looks more like

Re: [HACKERS] `array_position...()` causes SIGSEGV

Junseok Yang wrote: > Hello hackers, > > I met SIGSEGV when using `array_position()` with record type > arguments, so I've written a patch which corrects this problem. It > seems that `array_position...()` sets wrong memory context for the > cached function (in this case `record_eq()`) which is

Re: [HACKERS] building HEAD on macos fails with #error no source of random numbers configured

Dave Cramer writes: > Looking at src/port/pg_strong_random.c this would be a bug in autoconf It looks more like self-inflicted damage from here: > ./configure --prefix=/usr/local/pgsql/10 --enable-debug --with-python > --with-openssl

Re: [HACKERS] Re: [COMMITTERS] pgsql: Permit dump/reload of not-too-large >1GB tuples

Alvaro Herrera wrote: > Tom Lane wrote: > > Alvaro Herrera writes: > > > Permit dump/reload of not-too-large >1GB tuples > > > > I apologize for not having paid close enough attention earlier, but: > > this patch is absolutely unacceptable for the back branches and MUST

Re: [HACKERS] tzdata 2016j

David Fetter wrote: > On Tue, Dec 06, 2016 at 10:52:47AM -0500, Tom Lane wrote: > > Vladimir Borodin writes: > > > Any chance to get tzdata 2016j in supported branches? > > > > When the next scheduled releases come around (February), we'll update > > to whatever tzdata is

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Alvaro Herrera wrote: > > I have now pushed this to 9.5, 9.6 and master. It could be backpatched > to 9.4 with ease (just a small change in heap_form_tuple); anything > further back would require much more effort. I had to revert this on 9.5 and 9.6 -- it is obvious (in hindsight) that changing

[HACKERS] Fix for segfault in plpython's exception handling

The patch attached (a one-liner) includes information about how to reproduce the issue and why it happens. We applied it to our production servers (9.5) and has been working as expected for a while. I've also checked that it can be applied cleanly to current master. Could it make its way into

[HACKERS] building HEAD on macos fails with #error no source of random numbers configured

Looking at src/port/pg_strong_random.c this would be a bug in autoconf #else /* The autoconf script should not have allowed this */ #error no source of random numbers configured My configure line is: ./configure --prefix=/usr/local/pgsql/10 --enable-debug --with-python --with-openssl

Re: [HACKERS] Do we need use more meaningful variables to replace 0 in catalog head files?

On 11/13/16 12:19 PM, Tom Lane wrote: >> It'd also be very pg_proc specific, which isn't where I think this >> should go.. > > The presumption is that we have a CREATE command for every type of > object that we need to put into the system catalogs. But yes, the > other problem with this approach

Re: [HACKERS] pg_background contrib module proposal

On Wed, Nov 23, 2016 at 10:46 PM, amul sul wrote: > I would like to take over pg_background patch and repost for > discussion and review. > > Initially Robert Haas has share this for parallelism demonstration[1] > and abandoned later with > summary of open issue[2] with this

Re: [HACKERS] pg_background contrib module proposal

2016-12-09 13:48 GMT+01:00 Andrew Borodin : > I've read the code and now I have more suggestions. > > 1. Easy one. The case of different natts of expected and acutal result > throws same errmsg as the case of wrong types. > I think we should assist the user more here > > if

Re: [HACKERS] Time to drop old-style (V0) functions?

On Thu, Dec 8, 2016 at 5:53 PM, Andres Freund wrote: > I mean throwing an error. Silently assuming V1 seems like a horrible > idea to me. It doesn't seem unlikely that we want to introduce a new > call interface at some point given the runtime cost of the current one, > and

Re: [HACKERS] pg_background contrib module proposal

I've read the code and now I have more suggestions. 1. Easy one. The case of different natts of expected and acutal result throws same errmsg as the case of wrong types. I think we should assist the user more here if (natts != tupdesc->natts) ereport(ERROR,

Re: [HACKERS] Declarative partitioning - another take

On Fri, Dec 9, 2016 at 3:16 PM, Venkata B Nagothi wrote: > Hi, > > I am testing the partitioning feature from the latest master and got the > following error while loading the data - > > db01=# create table orders_y1993 PARTITION OF orders FOR VALUES FROM > ('1993-01-01') TO

Re: [HACKERS] jsonb problematic operators

On 9 December 2016 at 11:50, Jordan Gigov wrote: > There is this problem with the jsonb operators "? text" "?| text[]" > and "?& text[]" that the question mark is typically used for prepared > statement parameters in the most used abstraction APIs in Java and > PHP. > > This

Re: [HACKERS] `array_position...()` causes SIGSEGV

Michael Paquier wrote: > On Fri, Dec 9, 2016 at 3:14 PM, Junseok Yang wrote: > > I met SIGSEGV when using `array_position()` with record type > > arguments, so I've written a patch which corrects this problem. It > > seems that `array_position...()` sets wrong memory context

[HACKERS] jsonb problematic operators

There is this problem with the jsonb operators "? text" "?| text[]" and "?& text[]" that the question mark is typically used for prepared statement parameters in the most used abstraction APIs in Java and PHP. This really needs an alternative. Something like "HAS text", "HAS ANY(text[])" and "HAS

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Fri, Dec 09, 2016 at 11:51:45AM +0200, Heikki Linnakangas wrote: > On 12/09/2016 05:58 AM, Michael Paquier wrote: > > > > One thing is: when do we look up at pg_authid? After receiving the > > first message from client or before beginning the exchange? As the > > first message from client has

Re: [HACKERS] Declarative partitioning - another take

Hi, everyone! 08.12.16 18:25, Robert Haas wrote: Of course, this is the beginning, not the end. I've been thinking about next steps -- here's an expanded list: - more efficient plan-time partition pruning (constraint exclusion is too slow) - run-time partition pruning - partition-wise join

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 12/09/2016 05:58 AM, Michael Paquier wrote: One thing is: when do we look up at pg_authid? After receiving the first message from client or before beginning the exchange? As the first message from client has the user name, it would make sense to do the lookup after receiving it, but from PG

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Fri, Dec 9, 2016 at 5:11 PM, Heikki Linnakangas wrote: > Couple of things I should write down before I forget: > > 1. It's a bit cumbersome that the scram verifiers stored in > pg_authid.rolpassword don't have any clear indication that they're scram > verifiers. MD5 hashes are

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

Couple of things I should write down before I forget: 1. It's a bit cumbersome that the scram verifiers stored in pg_authid.rolpassword don't have any clear indication that they're scram verifiers. MD5 hashes are readily identifiable by the "md5" prefix. I think we should use a

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 12/09/2016 05:58 AM, Michael Paquier wrote: On Thu, Dec 8, 2016 at 10:05 PM, Michael Paquier wrote: On Thu, Dec 8, 2016 at 5:55 PM, Heikki Linnakangas wrote: Actually, we don't give away that information currently. If you try to log in with