Обсуждение: DBLink problems
I was having problems with dbLink package earlier, but with your help I was able to solve them with PostgreSQL v7.3b.
Now, I am trying to port my solution to v7.2.1, which I am currently using. Every other time I run my procedures I get the following error:
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
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?
2. Can I use dbLink, which comes with v7.3b with v7.2.1?
3. How stable is v7.3b and should I just move to it without trying to port my procedures to v7.2.1?
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
Thank you.
"Oleg Lebedev" <oleg.lebedev@waterford.org> writes:
> 3. How stable is v7.3b and should I just move to it without trying to
> port my procedures to v7.2.1?
So far we've not seen reports that suggest any stability problems with
7.3 beta. What you are mainly risking if you move to a beta is having
to dump/initdb/reload (again) to go to 7.3 final. I do not think there
will be any forced initdb's between 7.3beta3 and final, but it can't be
ruled out.
7.3beta3, due out pretty soon, will contain fixes for two nasty problems
that have plagued all 7.2.* releases ("can't wait without a PROC" and at
least some forms of the missing-pg_clog-file problem). So a pretty good
case could be made that it will likely be *more* stable than any 7.2
release. Any remaining bugs are likely to be in new features that
weren't in 7.2.
> 4. Can I configure v7.3b to be able to use the same database as v7.2.1?
Nope. You must dump and reload.
regards, tom lane
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