| From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: BUG #17212: pg_amcheck fails on checking temporary relations |
| Date: | 2021-10-06 22:03:08 |
| Message-ID: | 8DEF4462-BB8C-4EF3-B0D0-B4A28040BD9B@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
> On Oct 6, 2021, at 2:45 PM, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>
> and db3 is in recovery.
<snip>
> they're scattered across different databases, some in recovery, some not.
What I mean here is that, since pg_amcheck might run for many hours, and database may start in recovery but then exit recovery, or may be restarted and go into recovery while we're not connected to them, the tool may see differences when processing a pattern against one database at one point in time and the same or different patterns against the same or different databases at some other point in time. We don't get the luxury of assuming that nothing changes out from under us.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2021-10-06 22:20:14 | Re: BUG #17212: pg_amcheck fails on checking temporary relations |
| Previous Message | Mark Dilger | 2021-10-06 21:45:49 | Re: BUG #17212: pg_amcheck fails on checking temporary relations |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2021-10-06 22:05:39 | Re: using extended statistics to improve join estimates |
| Previous Message | Mark Dilger | 2021-10-06 21:45:49 | Re: BUG #17212: pg_amcheck fails on checking temporary relations |