Re: [NOVICE] URGENT! pg_dump doesn't work! (fwd)
От | Nigel J. Andrews |
---|---|
Тема | Re: [NOVICE] URGENT! pg_dump doesn't work! (fwd) |
Дата | |
Msg-id | Pine.LNX.4.21.0207231440000.2345-100000@ponder.fairway2k.co.uk обсуждение исходный текст |
Список | pgsql-general |
---------- Forwarded message ---------- Date: Tue, 23 Jul 2002 14:39:50 +0100 (BST) From: Nigel J. Andrews <nandrews@investsystems.co.uk> To: Wim <wdh@belbone.be> Subject: Re: [NOVICE] [GENERAL] URGENT! pg_dump doesn't work! On Tue, 23 Jul 2002, Wim wrote: > > I looked for core files in my data directory, but could find any... I > installed gdb, since I run postgres on Solaris 9. > I have no experience with gdb, so could you tell me how I get a trace > when postgres fails? What you need to do is: 1) start psql - to connect to your backend which I assume is running or you already know how to do 2) identify the backend (postgres) server your psql session from 1) is attached to - use ps ax | grep postgres to list all backend processes (possibly ps -fe instead ps ax). If your database is quiet and only your psql session is using it then the relevent process is obvious. If your database is busy you may find it easier to connect to it as a user that is not normally used, for example the database superuser (usually postgres), as this information should appear in the process listing. 3) start gdb using: gdb <path to postgres backend binary> <process id from step 2> - this attaches gdb to process serving your psql session. 4) at the gdb prompt press 'c' - this makes the backend process continue normal operations (gdb stopped it when it attached to it) 5) in your psql session issue the statement that causes the fault 6) when the backend generates it's fault you should have a prompt in your gdb session. Typing 'bt' at the gdb prompt will give you a stack trace. Now, the complications. 1) To get a useful stack trace you may need to have postgres built with debugging enabled, which would require a reconfigure and build from source if not already done. 2) I'm starting to think I've taken you wrong route with this. I'm no expert on the internals but I'm not convinced the backend is generating a fault such that you would get a core file or be able to do the final stage in above steps. My apologies for wasting your time if that's the case. However, as you've already gone to the trouble to install gdb it may be easiest to give the above instructions a go and see if you do indeed get a gdb prompt in the final step. Whether this works or not you should also attempt to obtain the stack trace from the pg_dump attempt. There should be a way to start pg_dump such that you have time to determine the backend process for it, however, reading the manpage I can only see -W as a possibility. One other question that would be interesting perhaps is whether the problem you are experiencing persists across a backend restart. Hopefully someone like Tom or Bruce can provide some guidance. Tom already suggested data corruption. -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants
В списке pgsql-general по дате отправления: