On Thu, Jan 26, 2017 at 11:16 PM, SCHAUHUBER Hermann
<hermann.schauhuber@sonorys.at> wrote:
> - The client (used libpq in c++ or also psql in a perl) tries to
> insert a counter into testtable
> - Whenever an error is returned to the client, the client tries
> is to write it again
> - the psql client receives an error but the record was inserted
> into the table!
>
> - So the record is finally insertet twice
As I understand your complaint, there is a short time between when
the request to commit modifications to the database is sent and
when the indication of successful commit is received by the client,
during which a broken connection leaves the status of the commit in
doubt. This much is unavoidable.
You further note that `pg_ctl -m fast` has more of a tendency to
cause this indeterminate state than is necessary. That may be
true. There may be room for a feature enhancement here, although I
don't see where it rises to the level of a bug. Such a feature
could never eliminate occurrences of the indeterminate state; it
could only reduce the frequency of them.
Meanwhile, there is a lot you could do to reduce the frequency of
this issue.
- If you use explicit transactions, the indeterminate state
could only occur on a COMMIT request, never on any other request.
You could safely assume that an error on any transaction not
waiting on a COMMIT request was indeed not committed.
- Off-hand, I can't think of where you could see this except
when the error level at the client side was FATAL. I think you
could safely assume that if the level is anything else that the
work was not committed.
- You might try performing a graceful termination of client
applications before shutting down the database.
- I understand that the so-called "smart" shutdown is often
impractical for production environments; however where it is used
the shutdown cannot cause the problem you describe.
- Finally, if you use two-phase commit with a high-quality
transaction manager (which independently keeps track of prepared
transactions, for retry as needed) you should automatically recover
from this condition.
What this definitely does not seem to me to be is a bug, which
makes this the wrong forum for further discussion of the issue.
--
Kevin Grittner
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs