On 2021-Mar-03, 'Alvaro Herrera' wrote:
> I wonder if it would make sense to get rid of conn->last_query
> completely and just rely always on conn->cmd_queue_head, where the
> normal (non-pipeline) would use the first entry of the command queue.
> That might end up being simpler than pipeline mode
On Wed, Mar 3, 2021 at 5:45 PM Justin Pryzby wrote:
> I'm proposing some minor changes.
>
>
Some additional tweaks/comments for the documentation with the edit
proposed edits:
(edit) + PQresultStatus, will report a
Remove the comma
(orig) + the failed operation are skipped entirely. Th
On 2021-Mar-03, 'Alvaro Herrera' wrote:
> On 2021-Mar-03, 'Alvaro Herrera' wrote:
>
> > This should obviously not occur. I'm trying to figure out how to repair
> > it and not break everything again ...
>
> I think trying to set up the connection state so that the next query
> appears in conn->l
I'm proposing some minor changes.
--
Justin
>From 35ed4dc1fc770834972396f7eeed142f6dabee88 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Wed, 3 Mar 2021 16:36:40 -0600
Subject: [PATCH 2/2] doc review
---
doc/src/sgml/libpq.sgml| 67 +-
src/interface
On 2021-Mar-03, 'Alvaro Herrera' wrote:
> This should obviously not occur. I'm trying to figure out how to repair
> it and not break everything again ...
I think trying to set up the connection state so that the next query
appears in conn->last_query prior to PQgetResult being called again
leads
On 2021-Mar-03, 'Alvaro Herrera' wrote:
> I'm much more comfortable with this version, so I'm marking the patch as
> Ready for Committer in case anybody else wants to look at this before I
> push it.
Actually, I just noticed a pretty serious problem, which is that when we
report an error, we don'
On 2021-Mar-03, k.jami...@fujitsu.com wrote:
> I tried applying this patch to test it on top of Iwata-san's libpq trace log
> [1].
> In my environment, the compiler complains.
> It seems that in libpqwalreceiver.c: libpqrcv_exec()
> the switch for PQresultStatus needs to handle the
> cases for PG
On Wed, Feb 17, 2021 8:14 AM (JST), Alvaro Herrera wrote:
Hi Alvaro,
> Here's a new version, where I've renamed everything to "pipeline". I think
> the
> docs could use some additional tweaks now in order to make a coherent
> story on pipeline mode, how it can be used in a batched fashion, etc.
On 2021-Feb-20, Craig Ringer wrote:
> On Wed, 17 Feb 2021, 07:13 Alvaro Herrera, wrote:
> > I
> > think the docs could use some additional tweaks now in order to make a
> > coherent story on pipeline mode, how it can be used in a batched
> > fashion, etc.
>
> I'll do that soon and send an updat
On Wed, 17 Feb 2021, 07:13 Alvaro Herrera, wrote:
> Here's a new version, where I've renamed everything to "pipeline".
Wow. Thanks.
I
> think the docs could use some additional tweaks now in order to make a
> coherent story on pipeline mode, how it can be used in a batched
> fashion, etc.
>
I
Hi,
Thanks for the response.
On Fri, Feb 19, 2021 at 12:46 PM Alvaro Herrera
wrote:
> Hi,
>
> On 2021-Feb-19, Zhihong Yu wrote:
>
> > Hi,
> > +static int pqBatchProcessQueue(PGconn *conn);
> >
> > I was suggesting changing:
> >
> > +int
> > +PQexitBatchMode(PGconn *conn)
> >
> > to:
> >
> > +sta
Hi,
On 2021-Feb-19, Zhihong Yu wrote:
> Hi,
> +static int pqBatchProcessQueue(PGconn *conn);
>
> I was suggesting changing:
>
> +int
> +PQexitBatchMode(PGconn *conn)
>
> to:
>
> +static int
> +PQexitBatchMode(PGconn *conn)
I understand that, but what I'm saying is that it doesn't work.
pqBat
Hi,
+static int pqBatchProcessQueue(PGconn *conn);
I was suggesting changing:
+int
+PQexitBatchMode(PGconn *conn)
to:
+static int
+PQexitBatchMode(PGconn *conn)
Cheers
On Fri, Feb 19, 2021 at 10:43 AM Alvaro Herrera
wrote:
> On 2021-Jan-21, Zhihong Yu wrote:
>
> > It seems '\\gset or \\aset
On 2021-Jan-21, Zhihong Yu wrote:
> It seems '\\gset or \\aset is not ' would correspond to the check more
> closely.
>
> + if (my_command->argc != 1)
> + syntax_error(source, lineno, my_command->first_line,
> my_command->argv[0],
>
> It is possible that my_command->argc == 0 (wh
Hello, thanks for looking at this patch.
On 2021-Feb-16, Zhihong Yu wrote:
> + if (querymode == QUERY_SIMPLE)
> + {
> + commandFailed(st, "startpipeline", "cannot use pipeline mode
> with the simple query protocol");
> + st->state = CSTATE_ABORTED;
> + re
Hi,
+ if (querymode == QUERY_SIMPLE)
+ {
+ commandFailed(st, "startpipeline", "cannot use pipeline mode
with the simple query protocol");
+ st->state = CSTATE_ABORTED;
+ return CSTATE_ABORTED;
I wonder why the st->state is only assigned for this if block.
Here's a new version, where I've renamed everything to "pipeline". I
think the docs could use some additional tweaks now in order to make a
coherent story on pipeline mode, how it can be used in a batched
fashion, etc.
Here's the renames I applied. It's mostly mechanical, except
PQbatchSendQueue
On 2021-Feb-16, Craig Ringer wrote:
> FWIW I'm also thinking of revising the docs to mostly use the term
> "pipeline" instead of "batch". Use "pipelining and batching" in the chapter
> topic, and mention "batch" in the index, and add a para that explains how
> to run batches on top of pipelining,
On Tue, 16 Feb 2021 at 09:19, Craig Ringer
wrote:
>
> So long as there is a way to "send A", "send B", "send C", "read results
> from A", "send D", and there's a way for the application to associate some
> kind of state (an application specific id or index, a pointer to an
> application query-queu
On Thu, 11 Feb 2021 at 07:51, Alvaro Herrera
wrote:
> On 2021-Jan-21, Alvaro Herrera wrote:
>
> > As you can see in an XXX comment in the libpq test program, the current
> > implementation has the behavior that PQgetResult() returns NULL after a
> > batch is finished and has reported PGRES_BATCH_
On 2021-Jan-21, Alvaro Herrera wrote:
> As you can see in an XXX comment in the libpq test program, the current
> implementation has the behavior that PQgetResult() returns NULL after a
> batch is finished and has reported PGRES_BATCH_END. I don't know if
> there's a hard reason to do that, but I
Hi,
+ commandFailed(st, "SQL", "\\gset and \\aset are not
allowed in a batch section");
It seems '\\gset or \\aset is not ' would correspond to the check more
closely.
+ if (my_command->argc != 1)
+ syntax_error(source, lineno, my_command->first_line,
my_com
As you can see in an XXX comment in the libpq test program, the current
implementation has the behavior that PQgetResult() returns NULL after a
batch is finished and has reported PGRES_BATCH_END. I don't know if
there's a hard reason to do that, but I'd like to supress it because it
seems weird an
Thanks David Johnston and Daniel Vérité, I have incorporated your
changes into this patch, which is now v26. Also, it's been rebased on
current sources.
I've been using the new PQtrace() stuff to verify the behavior of the
new feature. It's not perfect, but at least it doesn't crash
immediately
On 2020-Nov-23, Daniel Verite wrote:
> Hi,
>
> Here's a new version with the pgbench support included.
Thanks, incorporated into my local copy.
Hi,
Here's a new version with the pgbench support included.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: https://www.manitou-mail.org
Twitter: @DanielVerite
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 9ce32fb39b..2a94f8f6b9 100644
--- a/doc/src/sgml/libpq.s
Hi
On Wed, Nov 18, 2020, at 09:51, Alvaro Herrera wrote:
> On 2020-Nov-14, Daniel Verite wrote:
>
> > The patch I posted in [1] was pretty simple, but at the time, query
> > results were always discarded. Now that pgbench can instantiate
> > variables from query results, a script can do:
> > se
On 2020-Nov-14, Daniel Verite wrote:
> The patch I posted in [1] was pretty simple, but at the time, query
> results were always discarded. Now that pgbench can instantiate
> variables from query results, a script can do:
> select 1 as var \gset
> select :var;
> This kind of sequence wouldn't
On Fri, Nov 13, 2020 at 5:38 PM Alvaro Herrera
wrote:
> Here's a v25.
>
> I made a few more changes to the docs per David's suggestions; I also
> reordered the sections quite a bit. It's now like this:
> * Batch Mode
>* Using Batch Mode
> * Issuing Queries
> * Processing Results
>
Alvaro Herrera wrote:
> I adapted the test code to our code style. I also removed the "timings"
> stuff; I think that's something better left to pgbench.
>
> (I haven't looked at Daniel's pgbench stuff yet, but I will do that
> next.)
The patch I posted in [1] was pretty simple, but at
Here's a v25.
I made a few more changes to the docs per David's suggestions; I also
reordered the sections quite a bit. It's now like this:
* Batch Mode
* Using Batch Mode
* Issuing Queries
* Processing Results
* Error Handling
* Interleaving Result Processing and Query Di
(Adding previous reviewers to CC)
On 2020-Nov-03, David G. Johnston wrote:
> Given the caveats around blocking mode connections why not just require
> non-blocking mode, in a similar fashion to how synchronous functions are
> disallowed?
This is a very good question. Why indeed? Does anybody h
Hi David,
Thanks for the feedback. I did rework a bit the doc based on your
remarks. Here is the v24 patch.
Matthieu Garrigues
On Tue, Nov 3, 2020 at 6:21 PM David G. Johnston
wrote:
>
> On Mon, Nov 2, 2020 at 8:58 AM Alvaro Herrera wrote:
>>
>> On 2020-Nov-02, Alvaro Herrera wrote:
>>
>> > In
Hi,
On 2020-11-03 10:42:34 -0300, Alvaro Herrera wrote:
> It would definitely help if you (and others) could think about the API
> being added: Does it fulfill the promises being made? Does it offer the
> guarantees that real-world apps want to have? I'm not much of an
> application writer mysel
On Mon, Nov 2, 2020 at 8:58 AM Alvaro Herrera
wrote:
> On 2020-Nov-02, Alvaro Herrera wrote:
>
> > In v23 I've gone over docs; discovered that PQgetResults docs were
> > missing the new values. Added those. No significant other changes yet.
>
>
Just reading the documentation of this patch, have
I implemented a C++ async HTTP server using this new batch mode and it
provides everything I needed to transparently batch sql requests.
It gives a performance boost between x2 and x3 on this benchmark:
https://www.techempower.com/benchmarks/#section=test&runid=3097dbae-5228-454c-ba2e-2055d3982790
On Tue, 3 Nov 2020 at 08:42, Alvaro Herrera wrote:
> Hi Dave,
>
> On 2020-Nov-03, Dave Cramer wrote:
>
> > On Mon, 2 Nov 2020 at 10:57, Alvaro Herrera
> wrote:
> >
> > > On 2020-Nov-02, Alvaro Herrera wrote:
> > >
> > > > In v23 I've gone over docs; discovered that PQgetResults docs were
> > > >
Hi Dave,
On 2020-Nov-03, Dave Cramer wrote:
> On Mon, 2 Nov 2020 at 10:57, Alvaro Herrera wrote:
>
> > On 2020-Nov-02, Alvaro Herrera wrote:
> >
> > > In v23 I've gone over docs; discovered that PQgetResults docs were
> > > missing the new values. Added those. No significant other changes yet
Alvaro,
On Mon, 2 Nov 2020 at 10:57, Alvaro Herrera wrote:
> On 2020-Nov-02, Alvaro Herrera wrote:
>
> > In v23 I've gone over docs; discovered that PQgetResults docs were
> > missing the new values. Added those. No significant other changes yet.
>
>
>
Thanks for looking at this.
What else d
On 2020-Nov-02, Alvaro Herrera wrote:
> In v23 I've gone over docs; discovered that PQgetResults docs were
> missing the new values. Added those. No significant other changes yet.
>From 3f305d05000981445fe4dbbb96c2e88ace89f439 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Mon, 26 Oct 20
In v23 I've gone over docs; discovered that PQgetResults docs were
missing the new values. Added those. No significant other changes yet.
I started reading this patch. As a starting point I decided to post an
updated copy (v22), wherein I reverted the overwriting of
src/include/port/linux.h with the win32.h contents (?) and the inclusion
of in libpq-fe.h. If those are needed, some different
solution will have to be found.
Trivial
This patch fixes compilation on windows and compilation of the documentation.
Matthieu Garrigues
On Thu, Oct 1, 2020 at 8:41 AM Matthieu Garrigues
wrote:
>
> On Thu, Oct 1, 2020 at 6:35 AM Michael Paquier wrote:
>
> > The documentation is failing to build, and the patch does not build
> > corre
On Thu, Oct 1, 2020 at 6:35 AM Michael Paquier wrote:
> The documentation is failing to build, and the patch does not build
> correctly on Windows. Could you address that?
> --
> Michael
Yes I'm on it.
--
Matthieu
On Mon, Sep 21, 2020 at 07:55:03PM +0200, Matthieu Garrigues wrote:
> I merged PQbatchProcessQueue into PQgetResult.
> One first init call to PQbatchProcessQueue was also required in
> PQsendQueue to have
> PQgetResult ready to read the first batch query.
>
> Tests and documentation are updated ac
Hi Dave,
I merged PQbatchProcessQueue into PQgetResult.
One first init call to PQbatchProcessQueue was also required in
PQsendQueue to have
PQgetResult ready to read the first batch query.
Tests and documentation are updated accordingly.
Matthieu Garrigues
On Mon, Sep 21, 2020 at 3:39 PM Dave Cr
On Mon, Sep 21, 2020 at 3:39 PM Dave Cramer wrote:
>
>
>
> On Mon, 21 Sep 2020 at 09:21, Matthieu Garrigues
> wrote:
>>
>> Matthieu Garrigues
>>
>> On Mon, Sep 21, 2020 at 3:09 PM Dave Cramer
>> wrote:
>> >>
>> > There was a comment upthread a while back that people should look at the
>> > co
On Mon, 21 Sep 2020 at 09:21, Matthieu Garrigues <
matthieu.garrig...@gmail.com> wrote:
> Matthieu Garrigues
>
> On Mon, Sep 21, 2020 at 3:09 PM Dave Cramer
> wrote:
> >>
> > There was a comment upthread a while back that people should look at the
> comments made in
> https://www.postgresql.org/m
Matthieu Garrigues
On Mon, Sep 21, 2020 at 3:09 PM Dave Cramer wrote:
>>
> There was a comment upthread a while back that people should look at the
> comments made in
> https://www.postgresql.org/message-id/20180322.211148.187821341.horiguchi.kyotaro%40lab.ntt.co.jp
> by Horiguchi-San.
>
> Fro
On 2020-Sep-21, Dave Cramer wrote:
Hello Dave,
> I am looking for this in the commitfest and can't find it. However there is
> an old commitfest entry
>
> https://commitfest.postgresql.org/13/1024/
>
> Do you have the link for the new one ?
Here you go:
https://commitfest.postgresql.org/29/27
Dave Cramer
www.postgres.rocks
On Mon, 31 Aug 2020 at 11:46, Matthieu Garrigues <
matthieu.garrig...@gmail.com> wrote:
> Hi,
>
> It seems like this patch is nearly finished. I fixed all the remaining
> issues. I'm also asking
> a confirmation of the test scenarios you want to see in the next
> v
Alvaro,
On Fri, 4 Sep 2020 at 17:26, Alvaro Herrera
wrote:
> On 2020-Aug-31, Matthieu Garrigues wrote:
>
> > It seems like this patch is nearly finished. I fixed all the remaining
> > issues. I'm also asking a confirmation of the test scenarios you want
> > to see in the next version of the pat
On 2020-Aug-31, Matthieu Garrigues wrote:
> It seems like this patch is nearly finished. I fixed all the remaining
> issues. I'm also asking a confirmation of the test scenarios you want
> to see in the next version of the patch.
Hmm, apparently nobody noticed that this patch is not registered in
Hi,
It seems like this patch is nearly finished. I fixed all the remaining
issues. I'm also asking
a confirmation of the test scenarios you want to see in the next
version of the patch.
> Hi,
>
> On 2020-07-10 19:01:49 -0400, Alvaro Herrera wrote:
> > Totally unasked for, here's a rebase of this
54 matches
Mail list logo
