OK, I have an 8.0.almost 5 installation which did not have any such
problems yet. The 8.0.~3 instance will soon be migrated to 8.1.latest,
so I will skip the 8.0.5 step, even if it only means install/restart/no
dump - after all I had a single crash in a few months of operation.
I take it granted t
Csaba Nagy wrote:
It's version 8.0.almost3, meaning that I used the 8.0 stable CVS branch
just before 8.0.3 was released. I will upgrade this data base to 8.1.x
(the latest released version at the time of upgrade) soon, so if the 8.1
version has the temporary table thing fixed that would be very
Csaba Nagy <[EMAIL PROTECTED]> writes:
> I have a postgres 8.0 installation, and I'm running autovacuum against
> it. I have noticed that it processes temporary tables too, which is in
> itself a bit curious, but the problem is that autovacuum might even
> crash if a temporary table is suddenly gon
It's version 8.0.almost3, meaning that I used the 8.0 stable CVS branch
just before 8.0.3 was released. I will upgrade this data base to 8.1.x
(the latest released version at the time of upgrade) soon, so if the 8.1
version has the temporary table thing fixed that would be very nice :-)
I also hav
Exactly which version of 8.0.x? There was a bug fixed around 8.0.5 or
so "Prevent core dump in contrib version of autovacuum when a table has
been dropped. Per report from daveg (not his patch, though)."
The version of autovacuum in 8.1 is a fairly different beast than the
contrib version, a
Hi all,
I have a postgres 8.0 installation, and I'm running autovacuum against
it. I have noticed that it processes temporary tables too, which is in
itself a bit curious, but the problem is that autovacuum might even
crash if a temporary table is suddenly gone while it tries to vacuum
it... that'
