On 2021-Sep-01, Matthew Tice wrote:
> Hi Alvaro, thanks for the quick reply.
Hi. Glad to hear that your problem is now behind.
> I'm scheduled to do my patching maintenance at the end of this month -
> but at this point I don't think I'm going to make it.
>
> Other than patching, is there a wor
Interestingly enough, I hopped on the database system this morning and
found the `datfrozenxid` dropped back down below
`autovacuum_freeze_max_age` around 0200 local time (roughly 18 hours
after the fact).
Looking through the Postgresql logs I don't see anything standing out
at that time.
I still
Hi Alvaro, thanks for the quick reply.
I'm scheduled to do my patching maintenance at the end of this month -
but at this point I don't think I'm going to make it.
Other than patching, is there a work around? For example, in #2 above:
>The fix for 2) is simpler,
>simply always remove both th
On 2021-Sep-01, Matthew Tice wrote:
[ problem table is pg_database ]
> My primary, read/write database is Postgresql 10.4 (CentOS 7) while my
> standby databases have been patched to 10.17.
Hmm, I think there was a bug in the early 10.x versions where advancing
the xid age of shared tables would
Hi,
Starting this morning at 0830 local time I noticed that my
datfrozenxid starts moving past the `autovacuum_freeze_max_age` value
of 2. When we encountered this in the past the solution has
been to do one of the following:
1. This is related an error similar to
```
found xmin 2675436
