On Thu, Jan 2, 2020 at 10:26:16PM +0500, Andrey Borodin wrote:
>
>
> > 2 янв. 2020 г., в 19:13, Robert Haas <robertmhaas@gmail.com> написал(а):
> >
> > On Sun, Dec 29, 2019 at 4:13 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> >> Not loosing data - is a nice property of the database either.
> >
> > Sure, but there's more than one way to fix that problem, as I pointed
> > out in my first response.
> Sorry, it took some more reading iterations of your message for me to understand the problem you are writing about.
>
> You proposed two solutions:
> 1. Client analyze warning an understand that data is not actually committed. This, as you pointed out, does not solve
theproblem: data is lost for another client, who never saw the warning.
> Actually, "client" is a stateless number of connections unable to communicate with each other by any means beside
database.They cannot share information about not committed transactions (they would need a database, thus chicken and
theegg problem).
Actually, it might be worse than that. In my reading of
RecordTransactionCommit(), we do this:
write to WAL
flush WAL (durable)
make visible to other backends
replicate
communicate to the client
I think this means we make the transaction commit visible to all
backends _before_ we replicate it, and potentially wait until we get a
replication reply to return SUCCESS to the client. This means other
clients are acting on data that is durable on the local machine, but not
on the replicated machine, even if synchronous_standby_names is set.
I feel this topic needs a lot more thought before we consider changing
anything.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +