FWIW a fix for this has been posted to all active branches:
Author: Andres Freund and...@anarazel.de
Branch: master [fd6a3f3ad] 2015-02-26 12:50:07 +0100
Branch: REL9_4_STABLE [d72115112] 2015-02-26 12:50:07 +0100
Branch: REL9_3_STABLE [abce8dc7d] 2015-02-26 12:50:07 +0100
Branch: REL9_2_STABLE
From: Amit Kapila amit.kapil...@gmail.com
On Fri, Jul 4, 2014 at 7:29 PM, MauMau maumau...@gmail.com wrote:
[Hypothesis]
Why does the connection processing emit WAL?
Probably, it did page-at-a-time vacuum during access to pg_database and
pg_authid for client authentication.
From: Rajeev rastogi rajeev.rast...@huawei.com
As of now there is no solution for this in PostgreSQL but I had submitted a
patch Standalone synchronous master in
9.4 2014-01 CommitFest, which was rejected because of some issues. This
patch was meant to degrade the synchronous
level of master,
From: Tom Lane t...@sss.pgh.pa.us
problem, the user might not realize he's got one until he starts to wonder
why autovac/autoanalyze aren't working.
In autovacuum.c, autovacuum workers avoid waiting for the standby by doing:
/*
* Force synchronous replication off to allow regular maintenance
From: Tom Lane t...@sss.pgh.pa.us
Andres Freund and...@2ndquadrant.com writes:
On 2014-07-07 09:57:20 -0400, Tom Lane wrote:
Well, see the comment that explains why the logic is like this now:
I think we should 'simply' make sequences assign a toplevel xid - then
we can get rid of that
Hi,
On 2014-07-04 22:59:15 +0900, MauMau wrote:
My customer reported a strange connection hang problem. He and I couldn't
reproduce it. I haven't been able to understand the cause, but I can think
of one hypothesis. Could you give me your opinions on whether my hypothesis
is correct, and a
On Mon, Jul 7, 2014 at 4:14 PM, Andres Freund and...@2ndquadrant.com wrote:
Hi,
On 2014-07-04 22:59:15 +0900, MauMau wrote:
My customer reported a strange connection hang problem. He and I couldn't
reproduce it. I haven't been able to understand the cause, but I can think
of one
Andres Freund and...@2ndquadrant.com writes:
I think we should rework RecordTransactionCommit() to only wait for the
standby if `markXidCommitted' and not if `wrote_xlog'. There really
isn't a reason to make a readonly transaction's commit wait just because
it did some hot pruning.
Well, see
On 2014-07-07 09:57:20 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
I think we should rework RecordTransactionCommit() to only wait for the
standby if `markXidCommitted' and not if `wrote_xlog'. There really
isn't a reason to make a readonly transaction's commit wait
Andres Freund and...@2ndquadrant.com writes:
On 2014-07-07 09:57:20 -0400, Tom Lane wrote:
Well, see the comment that explains why the logic is like this now:
I think we should 'simply' make sequences assign a toplevel xid - then
we can get rid of that special case in
On Tue, Jul 8, 2014 at 1:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-07-07 09:57:20 -0400, Tom Lane wrote:
Well, see the comment that explains why the logic is like this now:
I think we should 'simply' make sequences assign a toplevel xid -
On 2014-07-07 12:06:14 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-07-07 09:57:20 -0400, Tom Lane wrote:
Well, see the comment that explains why the logic is like this now:
I think we should 'simply' make sequences assign a toplevel xid - then
we can get
On Fri, Jul 4, 2014 at 7:29 PM, MauMau maumau...@gmail.com wrote:
Hello,
When requesting synchronous replication, each commit of a write
transaction will wait until confirmation is received that the commit has
been written to the transaction log on disk of both the primary and standby
server.
On 04 July 2014 19:29, MauMau Wrote:
[How to fix]
Of course, adding -o '-c synchronous_commit=local' or -o '-c
synchronous_standby_names=' to pg_ctl start in the recovery script
would prevent the problem.
But isn't there anything to fix in PostgreSQL? I think the doc needs
improvement
On 2014-07-07 04:20:12 +, Rajeev rastogi wrote:
On 04 July 2014 19:29, MauMau Wrote:
[How to fix]
Of course, adding -o '-c synchronous_commit=local' or -o '-c
synchronous_standby_names=' to pg_ctl start in the recovery script
would prevent the problem.
But isn't there
Hello,
My customer reported a strange connection hang problem. He and I couldn't
reproduce it. I haven't been able to understand the cause, but I can think
of one hypothesis. Could you give me your opinions on whether my hypothesis
is correct, and a direction on how to fix the problem?
16 matches
Mail list logo
