Oleg Lebedev wrote:
> So, I have several questions in regards to this:
> 1. How can I debug this problem and find out what exactly is the cause
> of the error?
Use gdb in another session to attach to the backend. Then either run the query
that fails and do a backtrace, or set a breakpoint and step through the
code. I usually do something like this:
Terminal 1:
- psql mydatabase
- execute some dblink function which you know will succeed; alternatively use
the LOAD command to load the dblink shared library
Terminal 2:
- run `ps -ef|grep postgres`
- find the pid of the *backend* (not the psql pid) -- this should be the one
with "mydatabase" shown
- run `gdb /path/to/postgres`
- in gdb, do `attach pidnum` where pidnum is the one you determined above
- either do `break function_name` then `continue`; or just do `continue`
Terminal 1:
- execute the statement which fails;
- either step through if a breakpoint was hit, or type `bt` to get a backtrace
if there was a segfault
That should get you going. This all assumes that you configured with
--enable-debug and --enable-cassert.
> 2. Can I use dbLink, which comes with v7.3b with v7.2.1?
No. Too many non-backward-compatible changes.
> 3. How stable is v7.3b and should I just move to it without trying to
> port my procedures to v7.2.1?
You saw Tom's answer on this. I'd have to agree with him.
> 4. Can I configure v7.3b to be able to use the same database as v7.2.1?
> I tried and got an error saying that data dir was initialized by v7.2.1
> and is not compatible with v7.3b
Nope -- gotta dump and reload.
Joe
