Re: Most efficient way for libPQ .. PGresult serialization

From: Joshua Bay <joshuabay93(at)gmail(dot)com>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Most efficient way for libPQ .. PGresult serialization
Date: 2016-08-20 14:20:28
Message-ID: CABb-U3bXrh6uNjD6bnVc3vYGw=5+Djiah3JVOXSxj5v0qF5syg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

No, it can be anything else.

Please correctly me if I'm wrong, but to me, PgPool-II looks like a proxy
server that forwards all the data without interpretation. Can I intercept
in the middle and control the flow between client and server? For e.g, I
need control when the result of transaction is sent back to the result?

On Sat, Aug 20, 2016 at 2:39 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> On 19 August 2016 at 22:16, Joshua Bay <joshuabay93(at)gmail(dot)com> wrote:
>
>> Oh I see.
>> I just read more on use cases PgBouncer, but seems like it can't be used
>> for my project.
>> The reason is that I need to have my middleware to have full control over
>> each transaction.
>> That is it must be able to decide if it's going to commit or abort a
>> single query (reason why libpq is used in the middleware), and it must be
>> able to decide when to send back the result. Also it does things like load
>> balancing with it's algorithm.
>>
>> So, what middleware does is (simplied, ignoring other details)
>> 1. listens to query and does load balancing
>> 2. execute query on behalf of client to server with libpq (does not have
>> to be libpq).
>> 3. serialize the result and send it back
>>
>> And the #3 is why I asked for ways to serialize PGresult (of libpq)
>>
>> Client app will deserialize the result and thus be able to interpret
>> PGresult as if it used libpq itself.
>>
>>
> Surely the app should just use libpq, and your middleware should be a
> proxy?
>
> Like, say, PgPool-II?
>
> Otherwise you'll have to extract all the results handling parts of libpq
> into some smaller cut-down library and graft on
> serialization/deserialization code. There's nothing built-in for that
> ,since the natural and logical serialization for query results is the
> PostgreSQL wire protocol.
>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-08-20 15:17:01 Re: New SQL counter statistics view (pg_stat_sql)
Previous Message Michael Paquier 2016-08-20 14:16:11 Re: LSN as a recovery target