On Mon, Oct 24, 2011 at 10:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
as it seems to me that any
client that is paranoid enough to care about sync rep had better
already be handling the case of a connection loss during commit.
Agreed, but that is a problem that by definition we can't help
On Sun, Oct 23, 2011 at 6:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, there is a general problem that anything which throws an ERROR
too late in the commit path is Evil; and sync rep makes that worse to
the extent that it adds more stuff late in
Robert Haas robertmh...@gmail.com writes:
On Sun, Oct 23, 2011 at 6:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, it strikes me that if we want to do something about that, it ought
to be possible; but it has to be built into error handling, not a
localized hack for sync rep.
I actually
Tom Lane t...@sss.pgh.pa.us wrote:
It might be that it'd work to deal with this by reducing the
reported strength of all such cases from ERROR to WARNING. Not
sure that that's a good idea, but it might work.
Throwing an error on commit of a transaction when its work has
actually been
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 18, 2011 at 11:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
One thing worth asking is why we're willing to violate half a dozen
different coding rules if we see ProcDiePending, yet we're perfectly
happy to rely on the client understanding a
Robert Haas robertmh...@gmail.com writes:
Well, there is a general problem that anything which throws an ERROR
too late in the commit path is Evil; and sync rep makes that worse to
the extent that it adds more stuff late in the commit path, but it
didn't invent the problem.
BTW, it strikes me
On Mon, Oct 17, 2011 at 6:53 AM, Fujii Masao masao.fu...@gmail.com wrote:
WARNING: canceling the wait for synchronous replication and
terminating connection due to administrator command
DETAIL: The transaction has already committed locally, but might not
have been replicated to the standby.
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 17, 2011 at 6:53 AM, Fujii Masao masao.fu...@gmail.com wrote:
The simple fix is to change InteractiveBackend() so that it calls
CHECK_FOR_INTERRUPTS() before it outputs backend . Thought?
I'm tempted to say we should do that in
On Tue, Oct 18, 2011 at 5:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 17, 2011 at 6:53 AM, Fujii Masao masao.fu...@gmail.com wrote:
The simple fix is to change InteractiveBackend() so that it calls
CHECK_FOR_INTERRUPTS() before it outputs
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 18, 2011 at 5:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Another question worth asking is how is it that we're getting to
ReadCommand at all, if we have already determined that the client is
gone. Fixing that with an additional
On Tue, Oct 18, 2011 at 11:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
One thing worth asking is why we're willing to violate half a dozen
different coding rules if we see ProcDiePending, yet we're perfectly
happy to rely on the client understanding a WARNING for the
QueryCancelPending case.
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 18, 2011 at 11:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
One thing worth asking is why we're willing to violate half a dozen
different coding rules if we see ProcDiePending, yet we're perfectly
happy to rely on the client understanding a
Hi,
In 9.1, the following procedure writes a junk message into the server log;
$ initdb -D data
$ cat EOF data/postgresql.conf
wal_level = hot_standby
max_wal_senders = 1
synchronous_standby_names = '*'
EOF
$ pg_ctl -D data start
$ psql -c create table t (i int)
$ pg_ctl -D data -m fast stop
13 matches
Mail list logo
