At Mon, 4 Jul 2022 10:49:33 +0200, Alvaro Herrera
wrote in
> > Mmm. My patch moves the point of failure of the scenario a bit but
> > still a little short. However, as my understanding, it seems like the
> > task of the PQpipelineSync()-PQgetResult() pair to consume the
> > CloseComplete. If Ii
I have pushed this to all three branches. Thanks!
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"It takes less than 2 seconds to get to 78% complete; that's a good sign.
A few seconds later it's at 90%, but it seems to have stuck there. Did
somebody make perce
On 2022-Jul-04, Alvaro Herrera wrote:
> BTW I patch for the problem with uniqviol also (not fixed by v7). I'll
> send an updated patch in a little while.
Here it is. I ran "libpq_pipeline uniqviol" in a tight loop a few
thousand times and didn't get any error. Before these fixes, it would
fail
On 2022-Jul-04, Kyotaro Horiguchi wrote:
> At Wed, 29 Jun 2022 14:09:17 +0200, Alvaro Herrera
> wrote in
> > However, another problem case, not fixed by PIPELINE_IDLE, occurs if you
> > exit pipeline mode after PQsendQuery() and then immediately use
> > PQexec(). The CloseComplete will be rec
Thanks for the further testing scenario.
At Wed, 29 Jun 2022 14:09:17 +0200, Alvaro Herrera
wrote in
> So I wrote some more test scenarios for this, and as I wrote in some
> other thread, I realized that there are more problems than just some
> NOTICE trouble. For instance, if you send a query
So I wrote some more test scenarios for this, and as I wrote in some
other thread, I realized that there are more problems than just some
NOTICE trouble. For instance, if you send a query, then read the result
but not the terminating NULL then send another query, everything gets
confused; the next
At Tue, 21 Jun 2022 14:56:40 +0900 (JST), Kyotaro Horiguchi
wrote in
> By the way, I noticed that "libpq_pipeline uniqviol" intermittently
> fails for uncertain reasons.
>
> > result 574/575: pipeline aborted
> > ...
> > done writing
> >
At Tue, 21 Jun 2022 14:59:07 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Tue, 21 Jun 2022 14:56:40 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > By the way, I noticed that "libpq_pipeline uniqviol" intermittently
> > fails for uncertain reasons.
> >
> > > result 574/575: pipeline aborted
>
At Tue, 21 Jun 2022 14:56:40 +0900 (JST), Kyotaro Horiguchi
wrote in
> By the way, I noticed that "libpq_pipeline uniqviol" intermittently
> fails for uncertain reasons.
>
> > result 574/575: pipeline aborted
> > ...
> > done writing
> >
At Tue, 21 Jun 2022 11:42:59 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 17 Jun 2022 20:31:50 +0200, Alvaro Herrera
> wrote in
> > Others to think about:
> >
> > PQisBusy (I think no changes are needed),
>
> Agreed.
>
> > PQfn (I think it should accept a call in PGASYNC_PIPELINE_IDLE
At Fri, 17 Jun 2022 20:31:50 +0200, Alvaro Herrera
wrote in
> On 2022-Jun-16, Kyotaro Horiguchi wrote:
>
> > The attached is a crude patch to separate the state for PIPELINE-IDLE
> > from PGASYNC_IDLE. I haven't found a better way..
>
> Ah, yeah, this might be a way to fix this.
>
> Somethin
On 2022-Jun-16, Kyotaro Horiguchi wrote:
> The attached is a crude patch to separate the state for PIPELINE-IDLE
> from PGASYNC_IDLE. I haven't found a better way..
Ah, yeah, this might be a way to fix this.
Something very similar to a PIPELINE_IDLE mode was present in Craig's
initial patch for
At Thu, 16 Jun 2022 10:34:22 +0900 (JST), Kyotaro Horiguchi
wrote in
> PQgetResult() resets the state to IDLE while in pipeline mode.
>
> fe-exec.c:2171
>
> > if (conn->pipelineStatus != PQ_PIPELINE_OFF)
> > {
> > /*
> >
At Thu, 16 Jun 2022 10:34:22 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Wed, 15 Jun 2022 14:56:42 -0400, Tom Lane wrote in
> > Alvaro Herrera writes:
> > > So, git archaeology led me to this thread
> > > https://postgr.es/m/202106072107.d4i55hdscxqj@alvherre.pgsql
> > > which is why we adde
At Wed, 15 Jun 2022 14:56:42 -0400, Tom Lane wrote in
> Alvaro Herrera writes:
> > So, git archaeology led me to this thread
> > https://postgr.es/m/202106072107.d4i55hdscxqj@alvherre.pgsql
> > which is why we added that message in the first place.
>
> Um. Good thing you looked. I doubt we wa
Alvaro Herrera writes:
> So, git archaeology led me to this thread
> https://postgr.es/m/202106072107.d4i55hdscxqj@alvherre.pgsql
> which is why we added that message in the first place.
Um. Good thing you looked. I doubt we want to revert that change now.
> Alternatives:
> - Have the client n
On 2022-Jun-10, Kyotaro Horiguchi wrote:
> (Moved to -hackers)
>
> At Wed, 8 Jun 2022 17:08:47 +0200, Alvaro Herrera
> wrote in
> > What that Close message is doing is closing the unnamed portal, which
> > is otherwise closed implicitly when the next one is opened. That's how
> > single-query
=?UTF-8?Q?=C3=81lvaro_Herrera?= writes:
> Sadly, it looks like I won't be able to get this patched pushed for 14.4.
I think that's a good thing actually; this isn't urgent enough to
risk a last-minute commit. Please wait till the release freeze
lifts.
regards, tom lane
On Fri, Jun 10, 2022, at 8:25 AM, Kyotaro Horiguchi wrote:
>
> The current implement of PQsendQueryInternal looks like the result of
> a misunderstanding of the doc. In the regression tests, that path is
> excercised only for an error case, where no CloseComplete comes.
>
> The attached adds a t
At Fri, 10 Jun 2022 15:25:44 +0900 (JST), Kyotaro Horiguchi
wrote in
> The current implement of PQsendQueryInternal looks like the result of
> a misunderstanding of the doc. In the regression tests, that path is
> excercised only for an error case, where no CloseComplete comes.
>
> The attache
(Moved to -hackers)
At Wed, 8 Jun 2022 17:08:47 +0200, Alvaro Herrera
wrote in
> What that Close message is doing is closing the unnamed portal, which
> is otherwise closed implicitly when the next one is opened. That's how
> single-query mode works: if you run a single portal, it'll be kept o
21 matches
Mail list logo
