Tom Lane 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 persisted seems as ba
Robert Haas writes:
> On Sun, Oct 23, 2011 at 6:34 PM, Tom Lane 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 think that emitting a NOTICE or WARN
On Sun, Oct 23, 2011 at 6:34 PM, Tom Lane wrote:
> Robert Haas 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 i
On Mon, Oct 24, 2011 at 10:05 AM, Tom Lane 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 with.
> Also, t
Robert Haas 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 that if we want t
Robert Haas writes:
> On Tue, Oct 18, 2011 at 11:27 PM, Tom Lane 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
>> QueryCancelPendi
Robert Haas writes:
> On Tue, Oct 18, 2011 at 11:27 PM, Tom Lane 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
>> QueryCancelPendi
On Tue, Oct 18, 2011 at 11:27 PM, Tom Lane 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. Another is whethe
Robert Haas writes:
> On Tue, Oct 18, 2011 at 5:18 PM, Tom Lane 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 CHECK_FOR_INTERRUPTS seems like
>> a crock.
On Tue, Oct 18, 2011 at 5:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Oct 17, 2011 at 6:53 AM, Fujii Masao 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
Robert Haas writes:
> On Mon, Oct 17, 2011 at 6:53 AM, Fujii Masao 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 PostgresMain() instead, maybe
> something lik
On Mon, Oct 17, 2011 at 6:53 AM, Fujii Masao 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.
> backend> FATAL:
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
13 matches
Mail list logo
