| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jeremy Finzel <finzelj(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie> |
| Subject: | Re: found xmin from before relfrozenxid on pg_catalog.pg_authid |
| Date: | 2018-06-19 16:58:37 |
| Message-ID: | 20180619165837.wxtitjqkpusjbidv@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
Hi,
On 2018-06-19 08:25:33 -0500, Jeremy Finzel wrote:
> I have a question related to this - and specifically, preventing the error
> until we have a patch :).
The patch has been committed to postgres, although no release has been
made including it yet.
> We are encountering this error every few weeks on one very high
> transaction db, and have to restart to fix it.
> If I read you correctly, the cache may never be invalidated for these
> catalogs even if I manually VACUUM them? I was thinking if I routinely run
> VACUUM FREEZE on these tables in every database I might avoid the
> issue.
Correct, that won't help. In fact, it'll quite possibly make it worse.
> But given the cause of the issue, would that just make no difference and I
> will still hit the error eventually?
Yes. You might be able to get away with just removing the
pg_internal.init files before and after an explicit VACUUM on shared
system tables.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Juan Manuel Cuello | 2018-06-19 17:00:01 | Re: High WriteLatency RDS Postgres 9.3.20 |
| Previous Message | Hellmuth Vargas | 2018-06-19 16:49:32 | Re: Is postorder tree traversal possible with recursive CTE's? |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jesper Pedersen | 2018-06-19 17:00:36 | Re: Index Skip Scan |
| Previous Message | Andres Freund | 2018-06-19 16:52:20 | Re: Fast default stuff versus pg_upgrade |