From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Aleksander Alekseev <aleksander(at)timescale(dot)com>, Ondřej Žižka <ondrej(dot)zizka(at)stratox(dot)cz> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Synchronous commit behavior during network outage |
Date: | 2021-04-20 16:38:01 |
Message-ID: | 0e45e7cd-7e93-8ea5-6d1b-0dd2c88857ad@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4/20/21 6:23 PM, Aleksander Alekseev wrote:
> Hi Ondřej,
>
> Thanks for the report. It seems to be a clear violation of what is
> promised in the docs. Although it's unlikely that someone implemented
> an application which deals with important data and "pressed Ctr+C" as
> it's done in psql. So this might be not such a critical issue after
> all. BTW what version of PostgreSQL are you using?
>
Which part of the docs does this contradict?
With Ctrl+C the application *did not* receive confirmation - the commit
was interrupted before fully completing. In a way, it's about the same
situation as if a regular commit was interrupted randomly. It might have
happened before the commit log got updated, or maybe right after it,
which determines the outcome.
What I find a bit strange is that this inserts 1, 2, 2, 2 locally, and
yet we end up with just two rows with 2 (before the update). I don't see
why a network outage should have such consequence.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2021-04-20 16:56:05 | Re: pg_amcheck option to install extension |
Previous Message | Daniel Carter | 2021-04-20 16:28:46 | Re: PATCH: Add GSSAPI ccache_name option to libpq |