On 2021-Jul-08, Boris Kolpackov wrote:
> 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 thi
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
Looking at this again, I noticed that I could probably do away with the
switch on pipelineStatus, and just call pqPipelineProcessQueue in all
cases when appending commands to the queue; I *think* that will do the
right thing in all cases. *Except* that I don't know what will happen
if the program
On 2021-Jul-08, Boris Kolpackov wrote:
> Alvaro Herrera writes:
> > That seems a fair complaint, but I think PQisBusy is doing the right
> > thing per its charter. It is documented as "would PQgetResult block?"
> > and it is returning correctly that PQgetResult would not block in that
> > situa
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 PQisBusy()
> > indicate there is a result available
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 PQisBusy()
> indicate there is a result available without me sending a query for it?
> That
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.
On 2021-Jul-07, Boris Kolpackov wrote:
> // Try to minimize the chance of blocking the server by first processing
> // the result and then sending more queries.
> //
> if (FD_ISSET (sock, &rds))
> {
> if (PQconsumeInput (conn) == 0)
> assert (false);
>
> wh
On 2021-Jul-07, Boris Kolpackov wrote:
> 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
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 for my repro. Is it possible for
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 for my repro. Is it possible for you to
share a full program I can compi
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?
On 2021-Jul-06, Boris Kolpackov wrote:
> 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?
Yeah ... the problem as
On 2021-Jul-06, Boris Kolpackov wrote:
> 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?
Can you please try with
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?
On 2021-Jun-29, Ranier Vilela wrote:
> On 2021-Jun-29, Alvaro Herrera wrote:
>
> >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 ...
>
> I think that has an oversight with a719232
>
On 2021-Jun-29, Alvaro Herrera wrote:
>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 ...
I think that has an oversight with a719232
return false shouldn't be return 0?
regards,
Ranier
On 2021-Jun-29, Alvaro Herrera wrote:
> (I do see that you're doing PQisBusy that I'm not. Going to try adding
> it next.)
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 ...
--
Álvaro H
On 2021-Jun-29, Boris Kolpackov wrote:
> 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/od
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
On 2021-Jun-24, Boris Kolpackov wrote:
> I've hit another similar case except now an unexpected NULL result is
> returned in the middle of PGRES_PIPELINE_ABORTED result sequence. The
> call sequence is as follows:
>
> PQsendQueryPrepared() # INSERT #1
> PQflush()
> PQsendQueryPrepared() # INSERT
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
On Sat, Jun 26, 2021 at 05:40:15PM -0400, Alvaro Herrera wrote:
> It hadn't occurred to me that I should ask the release management team
> about adding a new function to libpq this late in the cycle.
I have not followed the thread in details, but if you think that this
improves the feature in the
It hadn't occurred to me that I should ask the release management team
about adding a new function to libpq this late in the cycle.
Please do note that the message type used in the new routine is currenly
unused and uncovered -- see line 4660 here:
https://coverage.postgresql.org/src/backend/tcop
On 2021-Jun-25, Alvaro Herrera wrote:
> From 071757645ee0f9f15f57e43447d7c234deb062c0 Mon Sep 17 00:00:00 2001
> From: Alvaro Herrera
> Date: Fri, 25 Jun 2021 16:02:00 -0400
> Subject: [PATCH v2 2/4] Add PQrequestFlush()
I forgot to mention:
> +/*
> + * Send request for server to flush its buff
On 2021-Jun-24, Boris Kolpackov wrote:
> 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 resul
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
On 2021-Jun-23, Boris Kolpackov wrote:
> If, however, I execute it by checking for results before sending the
> next INSERT, I get the following call sequence:
>
> PQsendQueryPrepared() # INSERT #1
> PQflush()
> PQsendQueryPrepared() # INSERT #2
> PQflush()
> ...
> PQsendQueryPrepared() # INSERT
On 2021-Jun-23, Boris Kolpackov wrote:
> If, however, I execute it by checking for results before sending the
> next INSERT, I get the following call sequence:
>
> PQsendQueryPrepared() # INSERT #1
> PQflush()
> PQsendQueryPrepared() # INSERT #2
> PQflush()
> ...
> PQsendQueryPrepared() # INSERT
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:
> 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
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 in the middle of PGRES_PIPELINE_ABORTE
On 2021-Jun-23, Boris Kolpackov wrote:
> I think one change that is definitely needed is to make it clear that
> the PQpipelineSync() call is not optional.
>
> I would also add a note saying that while the server starts processing
> the pipeline immediately, it may buffer the results and the only
On 2021-Jun-23, Boris Kolpackov wrote:
> I think one change that is definitely needed is to make it clear that
> the PQpipelineSync() call is not optional.
>
> I would also add a note saying that while the server starts processing
> the pipeline immediately, it may buffer the results and the only
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
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
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 that the client
would send data on PQflus
On 2021-Jun-21, Boris Kolpackov wrote:
> 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 woul
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
On 2021-Jun-16, Boris Kolpackov wrote:
> Specifically, the documentation[1]
> makes it sound like the use of PQpipelineSync() is optional (34.5.1.1
> "Issuing Queries"):
Hmm. My intention here was to indicate that you should have
PQpipelineSync *somewhere*, but that the server was free to start
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
41 matches
Mail list logo
