Hi
I have the following issue:
I have a development database that is altered a lot and a set of functions
that make use of dblink_build_sql_*.
The problem is that after I update a table whenever I use a function that
makes use of dblink_build_sql the server crashes.
The ALTER TABLE sequences u
Robert Voinea writes:
> I have a development database that is altered a lot and a set of functions
> that make use of dblink_build_sql_*.
> The problem is that after I update a table whenever I use a function that
> makes use of dblink_build_sql the server crashes.
This is a bug, but you have n
Hi,
I'm running a the check_postgres.pl --action=bloat on a database and finding
that there is wasted space.
I'm using 95% for the crtical %. If I use 110% I get the same things, but 115%
shows everything is OK.
check_postgres_bloat -H host -p port -db thing -t thing1 -c 95%
check_
On Fri, Jun 11, 2010 at 10:50:20AM -0400, dx k9 wrote:
>
> Hi,
>
>
>
> I'm running a the check_postgres.pl --action=bloat on a database and finding
> that there is wasted space.
>
>
>
> I'm using 95% for the crtical %. If I use 110% I get the same things, but
> 115% shows everything is
dx k9 wrote:
check_postgres checks for both index and table bloat. It looks like
my indexes are ok, this is just picking up on table bloat. I'm not
sure what I can do to reclaim the wasted space other than vacuum full
& analyze. Maybe a pgdump will do it.
CLUSTER will rebuild a new cop
Thanks everyone for the responses.
It seems like the problem is actually that the check_postgres_bloat does not
check for index bloat, just table bloat, even though it says it checks for both.
Below is my proof. Notice how this first check finds the indexes with idx in
their name, but t
