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
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?
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.
>
On Wednesday, March 22, 2017 2:17:27 PM EDT Jaime Casanova wrote:
> On 18 March 2017 at 14:01, Elvis Pranskevichus <elpr...@gmail.com> wrote:
> > On Saturday, March 18, 2017 3:33:16 AM EDT Michael Paquier wrote:
> >> Why adding a good chunk of code instead of usin
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
<elpr...@gmail.com> wrote:
> > Currently, clients wishing to know when the server exits hot standby
> > have to resort to polling, which is often suboptima
00:00:00 2001
From: Elvis Pranskevichus <el...@magic.io>
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 s
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 <elpr...@gmail.com>
wrote:
> > > It looks like pg_dump emits incorrect text for domain constraint
> > > comments:
> > &g
name.
Attached patch fixes that.
Elvis
>From ce1d4984dc0fb12082d89282acb674f5597404f1 Mon Sep 17 00:00:00 2001
From: Elvis Pranskevichus <el...@magic.io>
Date: Mon, 11 Jan 2016 17:30:54 -0500
Subject: [PATCH] pg_dump: Fix dumping of comments on domain constraints
---
src/bin/p
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
On September 21, 2010 12:08:49 pm Kevin Grittner wrote:
Andrew Dunstan and...@dunslane.net 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
On September 21, 2010 07:32:57 pm Kevin Grittner wrote:
Elvis Pranskevichus e...@prans.net wrote:
# apply the patch mailbox
$ git am ../postgresql.old/patches.mbox
That's not working for me.
Applying: Provide two macros for categorizing current transaction
isolation level
On September 21, 2010 11:47:30 pm Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
13 matches
Mail list logo
