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
Дейтер Александр Валериевич 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
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
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
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.