Re: Old row version in hot chain become visible after a freeze

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

In response to

Browse pgsql-bugs by date

  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