Re: [BUGS] BUG #2769: invalid memory alloc request size n on startup
Chris Jones [EMAIL PROTECTED] writes: #0 0x081cd8ba in errfinish () #1 0x081ce756 in elog_finish () #2 0x081dd6e5 in MemoryContextAlloc () #3 0x081ca14c in load_relcache_init_file () #4 0x081c9164 in RelationCacheInitialize () Hmph. Apparently there is something wrong with the pg_internal.init file in this database. I've dropped this database and restored it from backups to get it running again. That was premature --- you could have just removed the broken init file (which is merely a cache). I'm not sure how easy it'll be to identify the problem with the cache file without an easy way to compare to valid data, but if you want to send me the saved-off init file I'll take a look. Which PG version is this again? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] PostgreSQL 8.1.5: regression tests fail on sparc
Дейтер Александр Валериевич wrote: Hi, PostgreSQL 8.1.5 have a problem with division by zero on sparc. Solaris 9 sparc, gcc 4.0.2, 4.1.1: $ ./configure --enable-thread-safety --disable-nls --without-perl --without-python --without-krb5 --without-openssl --without-readline ... I found that you logged this as gcc bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968 However, SunStudio is much better for SPARC platform and now is free. GCC does not have good code optimalizer for SPARC. Zdenek ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[BUGS] 8.2rc1: vacuum full fills up disk space
this somehow sounds buggy: there's this table forum.posts which had 224mb table size, 145mb toast table size and 176mb indexes size (aproximately 60'000 rows). as i was doing some updates of all the records, i've issued a VACUUM FULL tablename... this was merely 60min ago, and it hasn't yet finished... instead in pg_xlog there are now 380+ files, totalling in over 6gb. available disk space is almost used up... the table was freshly loaded yestertday when reloading for rc1. as the process of vacuuming is still ongoing, is there something i can do to... a) .. prevent total diskspace fillup. what happens if i send a cancel signal to the process? b) .. gather some evidence if needed? c) .. check if the vacuum process is still alive? d) .. give the process in question a higher priority so it would finish sooner? thanks, thomas
Re: [BUGS] 8.2rc1: vacuum full fills up disk space
Thomas H. [EMAIL PROTECTED] writes: this somehow sounds buggy: vacuum full absolutely *will* bloat your index, if run on a heavily-modified table. I do not think it will bloat pg_xlog by itself however; are you sure you don't have some other open transactions? a) .. prevent total diskspace fillup. what happens if i send a cancel = signal to the process? Killing it should not corrupt anything; if it does that IS a serious bug and will be met with a full alarm response... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] 8.2rc1: vacuum full fills up disk space
this somehow sounds buggy: vacuum full absolutely *will* bloat your index, if run on a heavily-modified table. I do not think it will bloat pg_xlog by itself however; are you sure you don't have some other open transactions? well yes, as the system is live, users are browsing the website. but all queries that try to access the table in question are stalled at the moment. when querying server status i'm seeing lots of queries that are waiting for access to the table. would vacuum freeze be faster? a) .. prevent total diskspace fillup. what happens if i send a cancel = signal to the process? Killing it should not corrupt anything; if it does that IS a serious bug and will be met with a full alarm response... after a while it eventually finished just in time before the hd was filled up :-) 2006-11-27 07:18:04 [2096] LOG: duration: 6093332.000 ms statement: VACUUM FULL VERBOSE ANALYZE forum.posts thanks, - thomas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
