| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: error context for vacuum to include block number |
| Date: | 2019-12-29 00:21:31 |
| Message-ID: | CA+TgmoYSvEP3weQaCPGf6+DXLy2__JbJUYtoXyWP=qHcyGbihA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Dec 26, 2019 at 10:57 AM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> I agree that's better.
> I don't see any reason why the progress params need to be updated atomically.
> So rebasified against your patch.
I am not sure whether it's important enough to make a stink about, but
it bothers me a bit that this is being dismissed as unimportant. The
problem is that, if the updates are not atomic, then somebody might
see the data after one has been updated and the other has not yet been
updated. The result is that when the phase is
PROGRESS_VACUUM_PHASE_VACUUM_INDEX, someone reading the information
can't tell whether the number of index scans reported is the number
*previously* performed or the number performed including the one that
just finished. The race to see the latter state is narrow, so it
probably wouldn't come up often, but it does seem like it would be
confusing if it did happen.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2019-12-29 07:02:21 | Re: Consolidate 'unique array values' logic into a reusable function? |
| Previous Message | Robert Haas | 2019-12-28 23:56:41 | Re: Building infrastructure for B-Tree deduplication that recognizes when opclass equality is also equivalence |