[GENERAL] Multixact members limit exceeded

2017-08-09 Thread Peter Hunčár
Hello We have a fairly large postgresql-9.4 database (currently 70TB and growing to approx 80TB ) running on Centos 7. The HW is 48 core Xeon with 180GB of RAM with data on a enterprise grade SAN storage. We started feeding it several weeks ago and everything went smoothly until we hit this issu

Re: [GENERAL] Multixact members limit exceeded

2017-08-09 Thread Peter Hunčár
d changed after vacuum full, or am I not understanding something? Thanks a lot On Wed, Aug 9, 2017 at 7:57 PM Andres Freund wrote: > Hi, > > On 2017-08-09 10:06:48 +, Peter Hunčár wrote: > > We started feeding it several weeks ago and everything went smoothly > until > >

Re: [GENERAL] Multixact members limit exceeded

2017-08-09 Thread Peter Hunčár
Hello, there are currently no transactions whatsoever, the app is paused. I can even restart the database if needed. I ran vacuum full, because as I mentioned above it seemed to me that manual vacuum did not change the relminmxid of a table. Unfortunately, an upgrade is not an option :(

Re: [GENERAL] Multixact members limit exceeded

2017-08-24 Thread Peter Hunčár
Hello it took 10 days to autovacuum the 32TB toast table and after restarting with previous (but slightly tuned autovacuum) parameters, the database works just fine. The data import is almost done, there are just several hundred thousands of rows to add :) The next headache will the the backup of

[GENERAL] table corruption

2017-10-23 Thread Peter Hunčár
Hi, we have a table with around 1.6 billion rows having quite lot of big binary data toasted. Today we started getting: WIB > ERROR: invalid page in block 1288868309 of relation base/96031/96201 Which is a toast reltype. I know that zero_damaged_pages and vacuum (or restore the table from back