Thank you for your help Alvaro - we really appreciate it.
The error in fact stopped this morning - we took downtime and ran a vacuum
across all of our tables, and saw increased auto vacuum activity as well.
It looks like it bumped up the oldest multitxid to something other than 1 now:
postgres@s
avi Singh wrote:
> Your right we looked back in our old logs and we do see the messages there
> as well. Still what I'm not getting is since we restarted the database
> after SAN FC re-cable effort auto-vacuum is running on all the threads
> continuous. I have never seen auto-vacuum using all the t
Your right we looked back in our old logs and we do see the messages there
as well. Still what I'm not getting is since we restarted the database
after SAN FC re-cable effort auto-vacuum is running on all the threads
continuous. I have never seen auto-vacuum using all the threads 24*7 on
this datab
AnandKumar, Karthik wrote:
> Thanks. We started seeing this error right after a SAN FC re-cable effort -
> so yes, that would make sense.
> We’ll do a little more digging to see if the could have gotten removed.
> If that’s an older file that we have in our filesystem backups, is it safe to
Thanks. We started seeing this error right after a SAN FC re-cable effort - so
yes, that would make sense.
We’ll do a little more digging to see if the could have gotten removed.
If that’s an older file that we have in our filesystem backups, is it safe to
restore from there?
On 10/13/1
AnandKumar, Karthik wrote:
> root@site-db01a:/var/lib/pgsql/cmates/data # ls pg_multixact/members
> 0001 0002 0003 0004 0005 0006 0007 0008 0009 000A 000B 000C
> 000D 000E 000F 0010 0011 0012 0013 0014 0015 0016 0017 0018 0019
> 001A 001B
> root@site-db01a:/var/lib
We are also seeing this in our log file
Oct 12 19:08:14 site-db01a postgres[6117]: [7589-1] app=,user=,db=,ip=LOG:
MultiXact member wraparound protections are disabled because oldest
checkpointed MultiXact 1 does not exist on disk
On Wed, Oct 12, 2016 at 7:13 PM, avi Singh
wrote:
> Got the out
Got the output of pg_control
postgres@site-db01a:~/cmates/data/global $
/usr/pgsql-9.4/bin/pg_controldata /var/lib/pgsql/cmates/data
pg_control version number:942
Catalog version number: 201409291
Database system identifier: 6228991221455883206
Database cluster
Sharing output
postgres@site-db01a:~/cmates/data/pg_multixact/members $ ls
0002 0004 0006 0008 000A 000C 000E 0010 0012 0014 0016
0018 001A
0001 0003 0005 0007 0009 000B 000D 000F 0011 0013 0015 0017
0019 001B
postgres@site-db01a:~/cmates/data/pg_multixact/offsets $ l
root@site-db01a:/var/lib/pgsql/cmates/data # ls pg_multixact/members
0001 0002 0003 0004 0005 0006 0007 0008 0009 000A 000B 000C
000D 000E 000F 0010 0011 0012 0013 0014 0015 0016 0017 0018 0019
001A 001B
root@site-db01a:/var/lib/pgsql/cmates/data # ls pg_multixact/
AnandKumar, Karthik wrote:
> Hi,
>
> We run postgres 9.4.5.
>
> Starting this morning, we started seeing messages like the below:
> Oct 12 14:07:15 site-db01a postgres[11253]: [106430-1] app=,user=,db=,ip=LOG:
> MultiXact member wraparound protections are disabled because oldest
> checkpointed
11 matches
Mail list logo