On 11/03/2014 05:24 PM, Josh Berkus wrote: > BTW, the reason I started poking into this was a report from a user that > they have a pg_multixact directory which is 21GB in size, and is 2X the > size of the database. > > Here's XID data: > > Latest checkpoint's NextXID: 0/1126461940 > Latest checkpoint's NextOID: 371135838 > Latest checkpoint's NextMultiXactId: 162092874 > Latest checkpoint's NextMultiOffset: 778360290 > Latest checkpoint's oldestXID: 945761490 > Latest checkpoint's oldestXID's DB: 370038709 > Latest checkpoint's oldestActiveXID: 1126461940 > Latest checkpoint's oldestMultiXid: 123452201 > Latest checkpoint's oldestMulti's DB: 370038709 > > Oldest mxid file is 29B2, newest is 3A13 > > No tables had a relminmxid of 1 (some of the system tables were 0, > though), and the data from pg_class and pg_database is consistent.
More tidbits: I just did a quick check on customer systems (5 of them). This only seems to be happening on customer systems where I specifically know there is a high number of FK lock waits (the system above gets around 1000 per minute that we know of). Other systems with higher transaction rates don't exhibit this issue; I checked a 9.3.5 database which normally needs to do XID wraparound once every 10 days, and it's pg_multixact is only 48K (it has one file, 0000). Note that pg_clog on the bad machine is only 64K in size. How many IDs are there per mxid file? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
