Re: [HACKERS] [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.

2012-09-26 Thread Виктор Егоров
You're right, REINDEX was not done. I've stopped the VACUUM, did a proper server restart (pg_ctl -m fast -w restart) and will work on rebuilding relations. Seems like I have another issue with a bunch of bloated tables on my way also. Thanks for the support. 2012/9/26 Andres Freund : >> Last ent

Re: [HACKERS] [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.

2012-09-26 Thread Andres Freund
Hi, On Wednesday, September 26, 2012 07:57:06 AM Виктор Егоров wrote: > I'm afraid I'm exactly in this situation now. :( > Last entry from the 9.1.6 recommended VACUUM (FREEZE, VERBOSE, ANALYZE) It recommended doing a REINDEX first though? I guess you didn't do that? > was: INFO: "meta_version

Re: [HACKERS] [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.

2012-09-25 Thread Виктор Егоров
Forget to mention, that: - VACUUM is running on the master; - current state is unchanged for 20 hours. 2012/9/26 Виктор Егоров : > I'm afraid I'm exactly in this situation now. > > Last entry from the 9.1.6 recommended VACUUM (FREEZE, VERBOSE, ANALYZE) was: > INFO: "meta_version_chunks": found 55

Re: [HACKERS] [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.

2012-09-25 Thread Виктор Егоров
I'm afraid I'm exactly in this situation now. Last entry from the 9.1.6 recommended VACUUM (FREEZE, VERBOSE, ANALYZE) was: INFO: "meta_version_chunks": found 55363 removable, 32566245 nonremovable row versions in 450292 out of 450292 pages DETAIL: 0 dead row versions cannot be removed yet. There

Re: [HACKERS] [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.

2012-09-25 Thread Robert Haas
On Fri, Sep 21, 2012 at 10:41 AM, Andres Freund wrote: > Hrm. I retract my earlier statement about the low likelihood of corruption due > to this. Yeah. :-( We've recently had at least one report of autovacuum failing to terminate due to a series of index pages forming a circular loop, and at l

Re: [HACKERS] [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.

2012-09-21 Thread Andres Freund
On Friday, September 21, 2012 03:30:31 PM Marko Tiikkaja wrote: > On 9/20/12 11:55 PM, Andres Freund wrote: > > On Monday, September 17, 2012 03:58:37 PM Tom Lane wrote: > >> OK, that explains why we've not seen a blizzard of trouble reports. > >> Still seems like a good idea to fix it ASAP, though

Re: [HACKERS] [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.

2012-09-21 Thread Marko Tiikkaja
On 9/20/12 11:55 PM, Andres Freund wrote: On Monday, September 17, 2012 03:58:37 PM Tom Lane wrote: OK, that explains why we've not seen a blizzard of trouble reports. Still seems like a good idea to fix it ASAP, though. Btw, I think RhodiumToad/Andrew Gierth and I some time ago helped a user i

Re: [HACKERS] [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.

2012-09-20 Thread Andres Freund
On Monday, September 17, 2012 03:58:37 PM Tom Lane wrote: > Andres Freund writes: > > Btw, I played with this some more on Saturday and I think, while > > definitely a bad bug, the actual consequences aren't as bad as at least > > I initially feared. > > > > Fake relcache entries are currently se

Re: [HACKERS] [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.

2012-09-15 Thread Andres Freund
On Saturday, September 15, 2012 06:29:25 PM Tom Lane wrote: > Robert Haas writes: > > Definitions aside, I think it's a pretty scary issue. It basically means > > that if you have a recovery (crash or archive) during which you read a > > buffer into memory, the buffer won't be checkpointed. So if