Hallo,
I've a problem with postgress 8.1,
Db_data FS is full because file oid are too large, how I can delete old
OID file without to risk to damage oid relation database
Thks
Alessandro
Internet Email Confidentiality Footer
In response to Miracapillo Alessandro [EMAIL PROTECTED]:
Db_data FS is full because file oid are too large, how I can delete old
OID file without to risk to damage oid relation database
Are you vacuuming on a regular basis? If not, you may need to vacuum
full to get things back under
Thanks for response,
the process that do VACCUM FULL was in hang but I see it after my mail
thanks for your interest
best regards
Alessandro Miracapillo
-Messaggio originale-
Da: Bill Moran [mailto:[EMAIL PROTECTED]
Inviato: venerdì 13 giugno 2008 12.55
A: Miracapillo Alessandro
The following bug has been logged online:
Bug reference: 4238
Logged by: Lawrence Cohan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Linux 4.1.1
Description:pg_class.relhasindex not updated by vacuum
Details:
We rely on this column
Lawrence Cohan [EMAIL PROTECTED] writes:
We rely on this column to build a list of tables restricted to only those
that have indexes to be rebuilt with CONCURRENTLY however the column is not
updated as documentation says by the vacuum. After a successful
analyze/vacuum/analyze against the
Lawrence Cohan [EMAIL PROTECTED] writes:
Is it possible that because of the PKEY's we have on the tables that
flag is still showing true?
Uh, well certainly -- a PK is an index.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
Is it possible that because of the PKEY's we have on the tables that
flag is still showing true? In that case this is somewhat misleading
as the other flag relhaspkey from pg_class refers to the PK and its own
implicit index is not visible in PGADMIN UI for instance. The pg version
we are on in
Isn't a PK a CONSTRAINT and not an INDEX???
Some say one or more fields and others one or more attributes that
uniquely identifies a record in a table and PG like many other databases
would create a default internal index on that CONSTRAINT that can't be
seen or dropped unless you will drop the
This is what's happening if we add the PK on the table and we were
expecting that ONLY if a user index like fooi was created the
relhasindex should be true.
create table foo(f1 int, id serial, CONSTRAINT foo_pkey PRIMARY KEY
(id));
select relhasindex from pg_class where relname = 'foo';
Lawrence Cohan wrote:
Isn't a PK a CONSTRAINT and not an INDEX???
Sure, from a logical point of view. The implementation of that
constraint is an index.
In that case the two separate pg_class relhasindex and relhaspkey would
make sense indeed - just a thought nothing else and we'll take it
Alvaro Herrera [EMAIL PROTECTED] writes:
Lawrence Cohan wrote:
In that case the two separate pg_class relhasindex and relhaspkey would
make sense indeed - just a thought nothing else and we'll take it as is.
What would be the point? If you want to figure out whether a table has
a primary
Many thanks again. I figured out how to get only the tables that have
indexes created less these PK indexes so I can used the pg_get_indexdef
to rebuild them all through a scheduled Pgagent job in a loop using
CONCURRENTLY as our production assumes DB access 24/7.
Lawrence Cohan.
-Original
It is not criticism but only my own thought and PG is a really great
database!!! It was all perhaps due to my poor understanding of
relhasindex from pg_class internal catalog and I understand and respect
your view.
Best regards,
Lawrence Cohan.
-Original Message-
From: Tom Lane
13 matches
Mail list logo
