h of
> 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
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, but in
> > pg_partman I'd had it send the
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 there a way to go the other
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++;
> lbuffer[log_filepath-lbuffer-1] = '\0';
>
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 brolga. Howeever, a re
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
> loss. I know that's n
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 t
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 a
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 declared,
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 chanc
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 future need for this
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 I'm slightly interested in,
>> > figured I'd give it a whirl.
>
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 PostgreSQL coding style, which
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 result, I need to make osstest re
eplication-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
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 other three
> excepti
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: Wed Dec 7 13:17:43 2016 -0500
> >
> >
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
>
> Now we have a statement \g for execution query, \gs
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 and I propose \gstore for
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 deletions(-)
diff --git a/
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
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 to connect to a 9.6.1 server, then \d
> fails
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 the docs has an extraneous comma after the s
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 to connect to a 9.6.1 server, then \d
fails:
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 (
> name text not
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 subscription:
> http://www.postgresql.org/mailpref/pgs
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 9.6.1-16e7c02)
Type "help" for help.
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 indexing
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 - the decision to tie inde
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
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.
>
> This really needs an alt
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 use it to indicate a
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 ins
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 privilege
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 --with-libraries=/usr/
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
exceptions is being a
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.
>
Unfortunately true. Th
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 self-inflicted damage from here:
>
> > ./co
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 us
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 --with-libraries=/usr/local/opt/openssl/lib
> --with-includes
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
> > be reverted there. Ad
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 current at that time.
>
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
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 mas
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 --
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
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 pg_background patch ne
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 (natts != tupdesc->natt
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 that'd just bring bac
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,
(errcode(ERRCODE_DATATYPE_M
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 ('1993-12-31');
> CREA
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 really needs an altern
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 for the
> > cached fun
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
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 t
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 (A
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 p
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 readily identifia
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 "scram-sha-256:
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 password or MD5 authentication, and the user does
60 matches
Mail list logo
