From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Jeff Frost <jeff(at)pgexperts(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, "Wood, Dan" <hexpert(at)amazon(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Old row version in hot chain become visible after a freeze |
Date: | 2017-09-28 15:00:29 |
Message-ID: | 20170928150029.4tqfrdfw5sh452af@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Jeff Frost wrote:
> Any idea on how to identify affected rows on a running system?
> Is it as simple as:
>
> SELECT id, count(*) FROM foo GROUP BY id HAVING count(*) > 1;
>
> Maybe also need to:
>
> set enable_indexscan = 0;
> set enable_indexonlyscan = 0;
>
> before running the SELECT?
Did you find out? Your proposed query/settings seems like a good way to
determine if any supposed unique column is still unique, but I wonder if
there's a better way. I suppose a procedure would involve seeing which
tables have HOT updates, and scan those.
Of course, this could theoretically happen to tables without any UNIQUE,
and then the recipe doesn't work.
> Is it possible to affect a DELETE or does it need to be a HOT updated row?
AFAICS it needs to be a HOT update.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2017-09-28 15:24:33 | Re: Old row version in hot chain become visible after a freeze |
Previous Message | Alvaro Herrera | 2017-09-28 14:56:57 | Re: Old row version in hot chain become visible after a freeze |