On Wednesday, May 24, 2017 9:38:36 PM EDT Tsunakawa, Takayuki wrote:
> The clients will know the change of session_read_only when they do
> something that calls RecoveryInProgress(). Currently,
> RecoveryInProgress() seems to be the only place where the sessions
> notice the promotion, so I set se
On Thursday, March 23, 2017 4:50:20 AM EDT Magnus Hagander wrote:
> We should probably consider if there is some way we can implement
> these two things the same way. If we're inventing a new variable that
> gets pushed on each connection, perhaps we can use that one and avoid
> the SHOW command? I
On Wednesday, March 22, 2017 4:28:18 PM EDT Robert Haas wrote:
> On Wed, Mar 22, 2017 at 4:00 PM, Peter Eisentraut
> > I think we could use "in_recovery", which would be consistent with
> > existing naming.
>
> True.
Ironically, that was the name I originally used. I'll update the patch.
> (J
On Wednesday, March 22, 2017 2:17:27 PM EDT Jaime Casanova wrote:
> On 18 March 2017 at 14:01, Elvis Pranskevichus wrote:
> > On Saturday, March 18, 2017 3:33:16 AM EDT Michael Paquier wrote:
> >> Why adding a good chunk of code instead of using
> >> pg_is_in_recover
On Tuesday, March 21, 2017 11:50:38 PM EDT Peter Eisentraut wrote:
> On 3/17/17 13:56, Elvis Pranskevichus wrote:
> > Currently, clients wishing to know when the server exits hot standby
> > have to resort to polling, which is often suboptimal.
> >
> > This adds t
On Saturday, March 18, 2017 3:33:16 AM EDT Michael Paquier wrote:
> On Sat, Mar 18, 2017 at 2:56 AM, Elvis Pranskevichus
wrote:
> > Currently, clients wishing to know when the server exits hot standby
> > have to resort to polling, which is often suboptimal.
> >
00:00:00 2001
From: Elvis Pranskevichus
Date: Fri, 17 Mar 2017 13:25:08 -0400
Subject: [PATCH v1] Add and report the new "in_hot_standby" GUC
pseudo-variable.
Currently, clients wishing to know when the server exits hot standby
have to resort to polling, which is suboptimal.
This adds
On January 22, 2016 08:09:36 PM Alvaro Herrera wrote:
> Michael Paquier wrote:
> > On Tue, Jan 12, 2016 at 7:56 AM, Elvis Pranskevichus
wrote:
> > > It looks like pg_dump emits incorrect text for domain constraint
> > > comments:
> > >
> > > Assuming
issue of the domain name.
Attached patch fixes that.
Elvis
>From ce1d4984dc0fb12082d89282acb674f5597404f1 Mon Sep 17 00:00:00 2001
From: Elvis Pranskevichus
Date: Mon, 11 Jan 2016 17:30:54 -0500
Subject: [PATCH] pg_dump: Fix dumping of comments on domain constraints
---
src/bin/pg_dump
Hello,
I may be totally missing something, but there seems to be no way
to create a COMMENT on a domain constraint. There is
COMMENT ON CONSTRAINT constraint_name ON table_name
but no such thing for domain constraints, which seems like a
weird omission.
I couldn't find any relevant discuss
On September 21, 2010 11:47:30 pm Tom Lane wrote:
> Bruce Momjian writes:
> > However, keep in mind that creating a branch in every existing backpatch
> > branch is going to create even more backpatching monkey-work.
>
> Monkey-work is scriptable though. It'll all be worth it if git
> cherry-pic
On September 21, 2010 07:32:57 pm Kevin Grittner wrote:
> Elvis Pranskevichus wrote:
> > # apply the "patch mailbox"
> > $ git am ../postgresql.old/patches.mbox
>
> That's not working for me.
>
> Applying: Provide two macros for categori
On September 21, 2010 12:08:49 pm Kevin Grittner wrote:
> Andrew Dunstan wrote:
> > Basically, AIUI, you have to move the old repo aside and freshly
> > clone the new repo.
>
> I was assuming that, but it's good to have confirmation. What about
> my repo at
>
> http://git.postgresql.org/gitweb?
13 matches
Mail list logo
