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. b
"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 diskspa
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 ...
this was merely 60min ago, and it hasn't yet finished...
Дейтер Александр Валериевич 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 y
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
