| From: | Ilya Matveychikov <matvejchikov(at)gmail(dot)com> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Vik Fearing <vik(at)2ndquadrant(dot)fr>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #14027: n_tup_ins increments regardless of insertion success |
| Date: | 2016-03-19 10:16:50 |
| Message-ID: | CAKh5naaAgzxZa+QK84Fh_VVRB0=cVE-oMmErAV4OPg-5jsbeiw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
2016-03-19 4:08 GMT+03:00 David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>:
> To help explain why - consider that PostgreSQL is basically optimistic in
> its behavior. It writes out data expecting that the various constraints are
> going to succeed and that the transaction as a whole will be committed. If
> at any point the written data is deemed to be invalid it is marked as have
> been (for practical purposes) "deleted"
>
> just as if you had done an SQL DELETE on a valid record. Its just that in
> this instance the data in question was never visible outside of its
> transaction. It is, however, physically present and thus eligible for
> vacuum and contributes to the statistics of the database.
David, thanks for the explanation. Now that's clear to me.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-03-19 13:59:01 | Re: BUG #14031: Failed to Write to History File |
| Previous Message | David Gould | 2016-03-19 08:20:09 | Re: BUG #13750: Autovacuum slows down with large numbers of tables. More workers makes it slower. |