I am trying to add bulk operation support to ODB (a C++ ORM) using
the new pipeline mode added to libpq in PostgreSQL 14. However, things
don't seem to be working according to the documentation (or perhaps I
am misunderstanding something). Specifically, the documentation[1]
makes it sound like the
I am making use of the new pipeline mode added to libpq in
PostgreSQL 14. At the same time I would still like to support
older libpq versions by not providing the extended functionality
that depends on this mode.
The natural way to achieve this in C/C++ is to conditionally
enable code that depends
Tom Lane writes:
> I think putting a version number as such in there is a truly
> horrid idea. However, I could get behind adding a boolean flag
> that says specifically whether the pipeline feature exists.
> Then you'd do something like
>
> #ifdef LIBPQ_HAS_PIPELINING
>
> rather than embeddin
Alvaro Herrera writes:
> I think I should rephrase this to say that PQpipelineSync() is needed
> where the user needs the server to start executing commands; and
> separately indicate that it is possible (but not promised) that the
> server would start executing commands ahead of time because $re
Alvaro Herrera writes:
> > I think always requiring PQpipelineSync() is fine since it also serves
> > as an error recovery boundary. But the fact that the server waits until
> > the sync message to start executing the pipeline is surprising. To me
> > this seems to go contrary to the idea of a "p
Alvaro Herrera writes:
> On 2021-Jun-22, Alvaro Herrera wrote:
>
> > > So I think it would be useful to clarify the server behavior and
> > > specify it in the documentation.
> >
> > I'll see about improving the docs on these points.
>
> So I started to modify the second paragraph to indicate
Boris Kolpackov writes:
> What's strange here is that the first PQgetResult() call (marked with ???)
> returns NULL instead of result for INSERT #1 as in the first call sequence.
I've hit another similar case except now an unexpected NULL result is
returned
Alvaro Herrera writes:
> Curious -- I just noticed that the server understands a message 'H' that
> requests a flush of the server buffer. However, libpq has no way to
> generate that message as far as I can see. I think you could use that
> to request results from the pipeline, without the syn
Alvaro Herrera writes:
> Subject: [PATCH] Clarify that pipeline sync is mandatory
>
> ---
> doc/src/sgml/libpq.sgml | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
> index 441cc0da3a..0217f8d8c7 100644
> --- a/doc
Alvaro Herrera writes:
> IIUC the problem is that PQgetResult is indeed not prepared to deal with
> a result the first time until after the queue has been "prepared", and
> this happens on calling PQpipelineSync. But I think the formulation in
> the attached patch works too, and the resulting co
Alvaro Herrera writes:
> I forgot to mention:
>
> > + /* XXX useless without a flush ...? */
> > + pqFlush(conn);
> > +
> > + return 1;
> > +}
>
> I'm not sure if it's a good idea for PQrequestFlush to itself flush
> libpq's buffer. We can just document that PQflush is required ...
> opi
Alvaro Herrera writes:
> No luck reproducing any problems with this sequence as yet.
Can you try to recreate the call flow as implemented here (it's
pretty much plain old C if you ignore error handling):
https://git.codesynthesis.com/cgit/odb/libodb-pgsql/tree/odb/pgsql/statement.cxx?h=bulk#n78
Alvaro Herrera writes:
> Ah, yes it does. I can reproduce this now. I thought PQconsumeInput
> was sufficient, but it's not: you have to have the PQgetResult in there
> too. Looking ...
Any progress on fixing this?
Alvaro Herrera writes:
> Can you please try with this patch?
I don't get any difference in behavior with this patch. That is, I
still get the unexpected NULL result. Does it make a difference for
your reproducer?
Alvaro Herrera writes:
> On 2021-Jul-07, Boris Kolpackov wrote:
>
> > I don't get any difference in behavior with this patch. That is, I
> > still get the unexpected NULL result. Does it make a difference for
> > your reproducer?
>
> Yes, the behavior changes
Alvaro Herrera writes:
> Hmm ... aren't you trying to read more results than you sent queries?
Hm, but should I be able to? Or, to put another way, should PQisBusy()
indicate there is a result available without me sending a query for it?
That sounds very counter-intuitive to me.
Alvaro Herrera writes:
> On 2021-Jul-08, Boris Kolpackov wrote:
>
> > Alvaro Herrera writes:
> >
> > > Hmm ... aren't you trying to read more results than you sent queries?
> >
> > Hm, but should I be able to? Or, to put another way, should PQisBus
Alvaro Herrera writes:
> To be honest, I am hesitant to changing the charter in that way; I fear
> it may have consequences I don't foresee. I think the workaround is not
> *that* bad.
Ok, fair enough. I've updated my code to account for this and it seems
to be working fine now.
> I'm having
18 matches
Mail list logo
