Sorry, had exported it - bad cut/pasting...
I even tried it in single-user mode passing -P directly but got the same
result
Also confused/concerned by the 7 dead rows in pg_class. as i've
restarted the server all transaction should have finished so i'd like to
reclaim these - especially as vacu
John Lister writes:
> still getting the same problem.
>>> PGOPTIONS="-P"
>>> psql backend
I think you need export PGOPTIONS="-P" to make that work. Whether
it's related to your problem isn't clear though.
regards, tom lane
--
Sent via pgsql-admin mailing list (pgsql-a
Did you remove the # sign from the beginning of the line below?
>
> #listen_addresses = '*' # what IP address(es) to listen
> on;
Are you sure there is no line before the following lines which does match?
The first line matches wins.
>
> -- pg_hba.conf -- (remainder of file i
John Chase wrote:
> #listen_addresses = '*' # what IP address(es) to listen
> on;
umm. is the '#' still there?
Then the changes have no effect, because the line is commented out ...
Peter
--
Sent via pgsql-admin mailing list ([email protected])
To make changes to
I have two XP laptops connected to each other via cross-over cable. They
ping each other, they connect to each other's drives, no firewalls or
port filter is installed or enabled.
8.3.5 installed on 192.168.10.10
pgAdmin 1.8.4 installed on 192.168.10.12.
Here are the important bits from postgresq
>Yeah, if you have reason not to trust the system indexes then -P is
>a good idea until they are fixed. Standalone mode per se isn't that
>important --- you could do this from a regular session with -P specified
>via PGOPTIONS.
still getting the same problem.
> PGOPTIONS="-P"
> psql backend
>>
John Lister writes:
> Although saying that..
> reindex now works, but doing a vacuum verbose complains that the index
> is out of step with the table and i should reindex..
> would i be better shutting the db down, restarting in standalone mode
> (and also using the -P option) before reindexing
Cheers tom, that did it - i've removed the duplicates and seeing what else
is broken.
.
"John Lister" writes:
ERROR: could not create unique index "pg_class_oid_index"
a quick inspection of the pg_class table doesn't show any duplicates, is
there anyway i can find out which row(s) are d
Hi All,
I have a couple of questions about autovacuum/vacuum behavior.
On my production system, I set autovacuum ON since it's pretty hard to
me find a good timeframe for vacuum (the system is pretty busy over the day)
Last week the system was really slow and running vacuum manually the
performan
"John Lister" writes:
> ERROR: could not create unique index "pg_class_oid_index"
> a quick inspection of the pg_class table doesn't show any duplicates, is
> there anyway i can find out which row(s) are duplicated and remove them
> without a full db restore?
> also doing something like this
Hi, my wal archiving broke and postgresql filled up the local disk with
transaction logs, which i foolishly deleted in a moment of madness, after
resetting the transaction log a few of my tables are damaged but repairable.
However the system tables also seemed to have suffered. My main problem i
11 matches
Mail list logo
