Sent from my iPad
On 28-Jul-2013, at 5:53, Marko Tiikkaja wrote:
> Hi,
>
> Yesterday an interesting scenario was diagnosed on IRC. If you're running a
> synchronous slave and the connection to the slave is lost momentarily, your
> backends start naturally waiting for the slave to reconnect
On Thu, Jul 25, 2013 at 10:33:54AM -0700, David Fetter wrote:
> On Wed, Jul 24, 2013 at 09:38:15PM +, Andrew Gierth wrote:
> > Tom Lane said:
> > > If we did it with a WithOrdinality expression node, the result would
> > > always be of type RECORD, and we'd have to use blessed tuple
> > > descr
On Friday, July 26, 2013 6:18 PM Tom Lane wrote:
Alvaro Herrera writes:
>> The main contention point I see is where conf.d lives;
>> the two options are in $PGDATA or together with postgresql.conf. Tom
>> and Robert, above, say it should be in $PGDATA; but this goes against
>> Debian packaging an
While going through below commit, few doubts/observations:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7f7485a0cde92aa4ba235a1ffe4dda0ca0b6cc9a
1. Bgworker.c -
FindRegisteredWorkerBySlotNumber()
{
..
/*
* Copy contents of worke
Hi,
Yesterday an interesting scenario was diagnosed on IRC. If you're
running a synchronous slave and the connection to the slave is lost
momentarily, your backends start naturally waiting for the slave to
reconnect. If then your application keeps trying to create new
connections, it can us
On Wed, Jul 24, 2013 at 04:16:28AM +, Andrew Gierth wrote:
> Noah Misch said:
> > Other aggregates based on this syntax might not desire such type
> > unification.
>
> Then there would have to be some way to distinguish that. Maybe those could
> have -1 and the standard hypothetical set funct
Hello,
I'm sorry I've been touching several things recently before fixing any of
them.
I've noticed undesirable disk space increase while performing archive
recovery with PostgreSQL 9.3. This happens with 9.2, too.
I just performed archived recovery with the following parameters in
recove
On 27-07-2013 06:57, Tomonari Katsumata wrote:
> 1. replicating 3 servers(A,B,C)
> A->B->C
> ("trigger_file = /tmp/trig" is set in recovery_recovery.conf on B and C.)
>
> 2. stop server A and promoting server B with "touch /tmp/trig;pg_ctl
> promote"
> B->C
> (/tmp/trig file remains on server B)
>
On Fri, Jul 26, 2013 at 01:31:45PM -0400, Bruce Momjian wrote:
> On Fri, Jul 26, 2013 at 01:27:34PM -0400, Bruce Momjian wrote:
> > On Thu, Jul 25, 2013 at 10:57:28AM -0400, Bruce Momjian wrote:
> > > Everyone should be aware that the 9.3 pg_upgrade -j/--jobs option on
> > > Windows is currently br
Tom Lane writes:
> Come to think of it, maybe part of the reason we're having such a hard
> time getting to consensus is that people are conflating the "snippet"
> part with the "writable" part? I mean, if you are thinking you want
> system-management tools to be able to drop in configuration fra
Hi,
>>> Yes, it prevents PROMOTE_SIGNAL_FILE from remaining even if
>>> both promote files exist.
>>>
>> The command("unlink(PROMOTE_SIGNAL_FILE)") here is for
>> unusualy case.
>> Because the case is when done both procedures below.
>> - user create "promote" file on PGDATA
>> - user issue "pg_
11 matches
Mail list logo
