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
On Sat, Jul 15, 2017 at 3:36 PM, Alexander Korotkov
> 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
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
On Fri, Jul 14, 2017 at 11:04 PM, Magnus Hagander wrote:
> On Thu, Jul 13, 2017 at 9:31 AM, Thomas Munro
>> A post on planet.postgresql.org today reminded me that a colleague had
>> asked me to post this POC patch here for discussion.
On Sat, Jul 15, 2017 at 5:14 AM, Robert Haas wrote:
> On Thu, Jun 22, 2017 at 9:30 AM, Alexander Korotkov
> > If #1 is only about changing tuple and page formats, then could be much
> > simpler than the patch upthread? We can implement
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.
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
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!'
> 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
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:
On Fri, Jul 14, 2017 at 12:39 PM, Michael Paquier
> 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
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.
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
Mail list logo