Re: [HACKERS] New partitioning - some feedback

2017-07-15 Thread Mark Kirkwood
On 16/07/17 05:24, David Fetter wrote: On Fri, Jul 14, 2017 at 09:49:25PM -0500, Robert Haas wrote: On Mon, Jul 10, 2017 at 5:46 PM, David Fetter wrote: With utmost respect, it's less messy than adding '!' to the already way too random and mysterious syntax of psql's \ commands. What should

Re: [HACKERS] SCRAM auth and Pgpool-II

2017-07-15 Thread Jeff Janes
On Fri, Jul 14, 2017 at 7:48 AM, Vladimir Borodin wrote: > > 14 июля 2017 г., в 1:33, Stephen Frost написал(а): > > What would be really nice for such cases is support for Kerberos and > delegated Kerberos credentials. Having pgpool support that would remove > the need to deal with passwords at

Re: [HACKERS] Pluggable storage

2017-07-15 Thread Peter Geoghegan
On Sat, Jul 15, 2017 at 3:36 PM, Alexander Korotkov wrote: > I think that pruning and vacuum are artifacts of not only current heap > formats, but they are also artifacts of current index AM API. And this is > more significant circumstance given that we're going to preserve > compatibility of new

Re: [HACKERS] segfault in HEAD when too many nested functions call

2017-07-15 Thread Julien Rouhaud
On 15/07/2017 17:22, Tom Lane wrote: > Julien Rouhaud writes: >> Since b8d7f053c5c2bf2a7e8734fe3327f6a8bc711755 (Andres in Cc), if you >> write queries which result in infinite recursion (or just too many >> nested function calls), execution ends with segfault instead of intended >> exhausted max_

Re: [HACKERS] More flexible LDAP auth search filters?

2017-07-15 Thread Thomas Munro
On Fri, Jul 14, 2017 at 11:04 PM, Magnus Hagander wrote: > On Thu, Jul 13, 2017 at 9:31 AM, Thomas Munro > wrote: >> A post on planet.postgresql.org today reminded me that a colleague had >> asked me to post this POC patch here for discussion. It allows custom >> filters with ldapsearchprefix an

Re: [HACKERS] Pluggable storage

2017-07-15 Thread Alexander Korotkov
On Sat, Jul 15, 2017 at 5:14 AM, Robert Haas wrote: > On Thu, Jun 22, 2017 at 9:30 AM, Alexander Korotkov > wrote: > > If #1 is only about changing tuple and page formats, then could be much > > simpler than the patch upthread? We can implement "page format access > > methods" with routines for

[HACKERS] Something for the TODO list: deprecating abstime and friends

2017-07-15 Thread Tom Lane
The types abstime, reltime, and tinterval need to go away, or be reimplemented, sometime well before 2038 when they will overflow. It's not too soon to start having a plan for that, especially seeing that it seems to take a decade or more for us to actually get rid of anything we've deprecated. Ri

Re: [HACKERS] More race conditions in logical replication

2017-07-15 Thread Alvaro Herrera
After going over this a bunch more times, I found other problems. For example, I noticed that if I create a temporary slot in one session, then another session would rightly go to sleep if it tries to drop that slot. But the slot goes away when the first session disconnects, so I'd expect the sle

Re: [HACKERS] New partitioning - some feedback

2017-07-15 Thread David Fetter
On Fri, Jul 14, 2017 at 09:49:25PM -0500, Robert Haas wrote: > On Mon, Jul 10, 2017 at 5:46 PM, David Fetter wrote: > > With utmost respect, it's less messy than adding '!' to the already > > way too random and mysterious syntax of psql's \ commands. What > > should '\det!' mean? What about '\dT

Re: [HACKERS] segfault in HEAD when too many nested functions call

2017-07-15 Thread Tom Lane
I wrote: > I still think that we really need to add a check in ExecProcNode(). Actually ... to what extent could a check in ExecInitNode() substitute for that? Or do we need both? How about ExecEndNode() and ExecReScan()? You could argue that the latter two tree traversals are unlikely either t

Re: [HACKERS] segfault in HEAD when too many nested functions call

2017-07-15 Thread Tom Lane
Julien Rouhaud writes: > Since b8d7f053c5c2bf2a7e8734fe3327f6a8bc711755 (Andres in Cc), if you > write queries which result in infinite recursion (or just too many > nested function calls), execution ends with segfault instead of intended > exhausted max_stack_depth: Yes. We discussed this befor

Re: [HACKERS] Adding -E switch to pg_dumpall

2017-07-15 Thread Michael Paquier
On Fri, Jul 14, 2017 at 12:39 PM, Michael Paquier wrote: > While looking at a user problem, I got surprised that pg_dumpall does > not have a -E switch. This has been discussed a bit in the past like > here: > https://www.postgresql.org/message-id/75e4c42d37e6a74e9fb57c2e9f1300d601070...@tiger.nex

Re: [HACKERS] hash index on unlogged tables doesn't behave as expected

2017-07-15 Thread Michael Paquier
On Sat, Jul 15, 2017 at 6:27 AM, Ashutosh Sharma wrote: > I do agree with Amit. I think hash index is slightly trickier (in > terms of how it is organised) than other indexes and that could be the > reason for maintaining common code for hashbuild and hashbuildempty. Well, you both and Robert wor

Re: [HACKERS] SCRAM auth and Pgpool-II

2017-07-15 Thread Michael Paquier
On Sat, Jul 15, 2017 at 12:15 AM, Stephen Frost wrote: > While this might be possible by having some kind of special trusted > connection between the pooler and PG, I actually don't particularly like > the notion of inventing a bunch of complicated logic and pain so that a > connection pooler can