Hm, perhaps you should check the logs if the identd is working correctly.
Greetings,
Matthias
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Rodrigo Tavares
> Sent: Friday, December 15, 2006 1:08 PM
> To: pgsql-admin@postgresql.org
> Subject: [ADM
Hi,
i tried various ways to backup that db.
if i use a separate 'copy table to 'file' with binary' i can export the
problematic table and restore without problems. resulting outputfile is
much smaller than default output and runtime is much shorter.
is there any way to say pg_dump to use a copy
Hi Tom and Shoaib,
Thanks for all your help, the penny dropped and I now understand what you
meant by SYSID. I have traced the usename and all is now well.
Regards,
Sandy
Computer Officer, RA Certification Manager
Department of Computer Science - UWA
Llandinam Building
Penglais Campus
Aberyst
Glad to hear that Sandy :)
---
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)
On 12/18/06, Sandy Spence <[EMAIL PROTECTED]> wrote:
Hi Tom and Shoaib,
Thanks for all your help, the penny dropped and I now understand what you
meant by SYSID. I have traced the usename and all is now
unsubscribe
Hi,
just encountered this error trying to dump my db:
any ideas?
Thank you
pg_dump: ERROR: could not access status of transaction 1629514106
DETAIL: could not open file "pg_clog/0612": No such file or directory
pg_dump: SQL command to dump the contents of table "annuncio400" failed:
PQendc
sorry, forgot to mention: PG 8.1.5
On 12/18/06, Edoardo Ceccarelli <[EMAIL PROTECTED]> wrote:
Hi,
just encountered this error trying to dump my db:
any ideas?
Thank you
pg_dump: ERROR: could not access status of transaction 1629514106
DETAIL: could not open file "pg_clog/0612": No such f
You can try creating the missing clog file as 256K of zeros, once that is
done you can now try going through the pg_dump process again.
This suggestion might help you as well -->
http://archives.postgresql.org/pgsql-admin/2003-02/msg00263.php
-
Shoaib Mir
EnterpriseDB (www.en
Thanks for the help, I will probably try this but I would like to know how
all of this was originated:
I am posting here the evolution of my db, hoping that somebody can help:
- I upgraded from 7.x to 8.1.5 about 20 days ago
- the db is about 2 / 3 giga and the application that works on it has n
Can anyone point me to where in the source the database system
identifier is initially generated at? I've looked through initdb.c and I
cannot find it. I've also scoured various other parts of the source to
no avail. I may have more luck if I were an accomplished C programmer,
but alas, I am not.
"Edoardo Ceccarelli" <[EMAIL PROTECTED]> writes:
> pg_dump: ERROR: could not access status of transaction 1629514106
> DETAIL: could not open file "pg_clog/0612": No such file or directory
This looks like a data corruption problem to me. It may or may not be
significant that 1629514106 = 0x6120
Thanks, I tought about that as well but with PG7.X we had the same machine
with the same database running smoothly for more than a year
now strange things like this are happening:
2006-12-18 14:49:35 CET [14691] : LOG: server process (PID 13421)
wasterminated by signal 11
2006-12-18 14:49:35 CE
Joshua Colson <[EMAIL PROTECTED]> writes:
> Can anyone point me to where in the source the database system
> identifier is initially generated at?
In xlog.c I believe (probably in BootstrapXLog). But it's not very
interesting, it's just a random number ...
regards, tom la
"Edoardo Ceccarelli" <[EMAIL PROTECTED]> writes:
> I bet a crashing process could cause that data corruption, right?
No, Postgres is remarkably resistant to causing corruption during a
crash; it's deliberately engineered that way. I don't say this
*couldn't* be the explanation but it shouldn't be
14 matches
Mail list logo
