dblink doesn't honor interrupts while waiting a result
Hi
dblink in 8.3 blocks without any possibility of interrupting it while
waiting for an answer from the remote server. Here is a strace
[pid 27607] rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
[pid 27607] sendto(56, "Q\0\0\0008lock table travelhit.booking_code in
exclusive mode\0", 57, 0, NULL, 0) = 57
[pid 27607] rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
[pid 27607] poll([{fd=56, events=POLLIN|POLLERR}], 1, -1) = ?
ERESTART_RESTARTBLOCK (To be restarted)
[pid 27607] --- SIGTERM (Terminated) @ 0 (0) ---
[pid 27607] rt_sigreturn(0xf) = -1 EINTR (Interrupted system call)
[pid 27607] poll(
As you can see I'm trying to lock the table travelhit.booking_code,
which blocks because someone else is already holding that lock. When
I send a SIGTERM to the backend, the poll() syscalll is interruped -
but immediatly restarted.
I'm not sure how a proper fix for this could look like, since the
blocking actually happens inside libpq - but this certainly makes
working with dblink painfull...
regards, Florian Pflug
On 2/25/08, Florian G. Pflug <fgp@phlo.org> wrote:
I'm not sure how a proper fix for this could look like, since the
blocking actually happens inside libpq - but this certainly makes
working with dblink painfull...
Proper fix would be to use async libpq API, then loop on poll(2)
with small timeout. You can look at pl/proxy for example code.
--
marko
Marko Kreen wrote:
On 2/25/08, Florian G. Pflug <fgp@phlo.org> wrote:
I'm not sure how a proper fix for this could look like, since the
blocking actually happens inside libpq - but this certainly makes
working with dblink painfull...Proper fix would be to use async libpq API, then loop on poll(2)
with small timeout. You can look at pl/proxy for example code.
Ah, cool, I'll check out pl/proxy.
regards, Florian Pflug
On Mon, Feb 25, 2008 at 04:45:43AM +0100, Florian G. Pflug wrote:
dblink in 8.3 blocks without any possibility of interrupting it while
waiting for an answer from the remote server. Here is a strace
[pid 27607] rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
[pid 27607] sendto(56, "Q\0\0\0008lock table travelhit.booking_code in
exclusive mode\0", 57, 0, NULL, 0) = 57
[pid 27607] rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
[pid 27607] poll([{fd=56, events=POLLIN|POLLERR}], 1, -1) = ?
ERESTART_RESTARTBLOCK (To be restarted)
[pid 27607] --- SIGTERM (Terminated) @ 0 (0) ---
[pid 27607] rt_sigreturn(0xf) = -1 EINTR (Interrupted system call)
[pid 27607] poll(As you can see I'm trying to lock the table travelhit.booking_code,
which blocks because someone else is already holding that lock. When
I send a SIGTERM to the backend, the poll() syscalll is interruped -
but immediatly restarted.I'm not sure how a proper fix for this could look like, since the
blocking actually happens inside libpq - but this certainly makes
working with dblink painfull...
FWIW, I've had problems with dblink getting wedged somewhere in it's
communication with another server. I'm not sure at what stage this
happens (getting results, sending a query, etc). The only way I've found
to clear it is to restart the database the connection was coming from.
Dunno if this is related or not...
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828