Re: multithreading in Batch/pipelining mode for libpq

From: Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com>
To: Ilya Roublev <iroublev(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: multithreading in Batch/pipelining mode for libpq
Date: 2017-04-22 01:14:50
Message-ID: CAMsr+YFcoWm6WuhXvs6FGMsOWez3VdkfuJ4xzBd5ok3VBmhW3Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 22 Apr. 2017 6:04 am, "Ilya Roublev" <iroublev(at)gmail(dot)com> wrote:

1) is it possible technically (possibly by changing some part of libpq
code) to ignore results (especially for this sort of queries like insert),
processing somehow separately the situation when some error occurs?

There is a patch out there to allow libpq result processing by callback I
think. Might be roughly what you want.

2) if the answer to the previous question is negative, is it possible to
send asynchronous queries in one thread while reading results in another
thread?

Not right now. libpq's state tracking wouldn't cope.

I imagine it could be modified to work with some significant refactoring.
You'd need to track state with a shared fifo of some kind where dispatch
outs queries on the fifo as it sends them and receive pops them from it.

I started on that for the batch mode stuff but it's not in any way thread
safe there.

locking, info in PGconn very quickly becomes inconsistent, the number of
queries sent does not correspond to the number of results to be read, etc.
So I'd like to know at first is it possible at all (possibly by some
changes to be made in libpq)? Sorry if my idea sounds rather naive. And
thanks for your answer and advice.

Yeah, it's possible. The protocol can handle it, it's just libpq that can't.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-04-22 01:21:47 Re: multithreading in Batch/pipelining mode for libpq
Previous Message Tom Lane 2017-04-21 22:28:47 Re: Unportable implementation of background worker start