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
>
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 |