| From: | Alvaro Herrera <alvaro(dot)herrera(at)2ndquadrant(dot)com> | 
|---|---|
| To: | Boris Kolpackov <boris(at)codesynthesis(dot)com> | 
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org | 
| Subject: | Re: Pipeline mode and PQpipelineSync() | 
| Date: | 2021-06-24 22:32:20 | 
| Message-ID: | 202106242232.vpewlschvxfv@alvherre.pgsql | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
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 #~400
> PQflush()
> PQconsumeInput()      # At this point select() indicates we can read.
> PQgetResult()         # NULL (???)
> PQgetResult()         # INSERT #1
> PQgetResult()         # NULL
> PQgetResult()         # INSERT #2
> PQgetResult()         # NULL
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 code is less surprising.
I wrote a test case that works as you describe, and indeed with the
original code it gets a NULL initially; that disappears with the
attached patch.  Can you give it a try?
Thanks
-- 
Álvaro Herrera       Valdivia, Chile
"Escucha y olvidarás; ve y recordarás; haz y entenderás" (Confucio)
| Attachment | Content-Type | Size | 
|---|---|---|
| 0001-Fix-libpq-state-machine.patch | text/x-diff | 1.9 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2021-06-24 23:38:01 | Re: seawasp failing, maybe in glibc allocator | 
| Previous Message | Michael Paquier | 2021-06-24 22:25:55 | Re: pgbench logging broken by time logic changes |