the log table was effected (the log table is the only table that
has a large number of data changing, most of the other tables are
relatively static). Changing the owner of the parent directory to
postgres fixed the problem.
Thanks!
-Zeki
Tom Lane wrote:
[EMAIL PROTECTED] writes
og table if possible.
-Zeki
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Have you tried an analyze after 1,000 or so inserts? Also, you should
be able to disable sequence scans for the duration of the connection
using SET enable_seqscan=false.
-Zeki
Brian O'Reilly wrote:
The following bug has been logged online:
Bug reference: 1552
Logged by:
x27;(53101,30)';
UPDATE 0
#
-Zeki
On Fri, 13 Aug 2004, Tom Lane wrote:
> Zeki Mokhtarzada <[EMAIL PROTECTED]> writes:
> > The system is running on a Dell PowerEdge 2650 running RedHat 8. We had a
> > kernel halt about two weeks ago that was caused by one of our disk mirrors
stgresql.org/pgsql-bugs/2003-12/msg00174.php
But you never stated how to delete the duplicate rows. Any suggestions?
Also, where can I find documentation on the purpose and values of the
ctid, oid, xmin, xmax, cmin, cmax columns?
Thanks!
-Zeki
id I get no rows returned.
I suspect a corrupt index is at fault here. If that's the case, a reindex
will take quite some time and will lock the table causing a long period of
downtime. Is that my only option? Any other ideas?
-Zeki
---(end of broadcast)
