On 2023-May-22, Alvaro Herrera wrote:
> Hah, yeah, that's because an empty pipeline never calls the code to
> allocate the flag array. Here's the trivial fix.
Pushed to both branches, thanks for the report.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
On 2023-May-20, Alexander Lakhin wrote:
> Starting from 038f586d5, the following script:
> echo "
> \startpipeline
> \endpipeline
> " >test.sql
> pgbench -n -M prepared -f test.sql
>
> leads to the pgbench's segfault:
Hah, yeah, that's because an empty pipeline never calls the code to
allocate
Hello Alvaro,
21.02.2023 19:32, Alvaro Herrera wrote:
On 2023-Feb-20, Alvaro Herrera wrote:
Found one last problem: if you do "-f foobar.sql -M prepared" in that
order, then the prepare fails because the statement names would not be
assigned when the file is parsed. This coding only
On 2023-Feb-20, Alvaro Herrera wrote:
> Found one last problem: if you do "-f foobar.sql -M prepared" in that
> order, then the prepare fails because the statement names would not be
> assigned when the file is parsed. This coding only supported doing
> "-M prepared -f foobar.sql", which funnily
Found one last problem: if you do "-f foobar.sql -M prepared" in that
order, then the prepare fails because the statement names would not be
assigned when the file is parsed. This coding only supported doing
"-M prepared -f foobar.sql", which funnily enough is the only one that
On 2023-Feb-13, Andres Freund wrote:
> There's something wrong with the patch, it reliably fails with core dumps:
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest%2F42%2F3260
I think this would happen on machines where sizeof(bool) is not 1 (which
mine is evidently not).
Hi,
On 2023-02-08 13:10:40 +0100, Alvaro Herrera wrote:
> On 2023-Feb-08, Alvaro Herrera wrote:
>
> > I propose instead the following: each command is prepared just before
> > it's executed, as previously, and if we see a \startpipeline, then we
> > prepare all commands starting with the one
On 2023-Feb-08, Alvaro Herrera wrote:
> I propose instead the following: each command is prepared just before
> it's executed, as previously, and if we see a \startpipeline, then we
> prepare all commands starting with the one just after, and until the
> \endpipeline.
Here's the patch.
--
On 2022-Sep-30, Yugo NAGATA wrote:
> Well, I still don't understand why we need to prepare only "the
> commands within a pipeline" before starting pipeline. In the current
> behavior, the entire script is prepared in advance just before executing
> the first SQL command in the script, instead
Alvaro Herrera writes:
> I'm writing my own patch for this problem. While playing around with
> it, I noticed this:
> struct Command {
> /* size: 2168, cachelines: 34, members: 11 */
> /* sum members: 2164, holes: 1, sum holes: 4 */
> /* last cacheline: 56 bytes */
> };
I think the
I'm writing my own patch for this problem. While playing around with
it, I noticed this:
struct Command {
PQExpBufferDatalines;/* 024 */
char * first_line; /*24 8 */
inttype;
Hi,
On Mon, 12 Sep 2022 17:03:43 +0200
Alvaro Herrera wrote:
> On 2022-Mar-28, Yugo NAGATA wrote:
>
> > On Fri, 25 Mar 2022 16:19:54 -0400
> > Tom Lane wrote:
>
> > > I am not convinced this is a great idea. The current behavior is that
> > > a statement is not prepared until it's about to
On 2022-Mar-28, Yugo NAGATA wrote:
> On Fri, 25 Mar 2022 16:19:54 -0400
> Tom Lane wrote:
> > I am not convinced this is a great idea. The current behavior is that
> > a statement is not prepared until it's about to be executed, and I think
> > we chose that deliberately to avoid semantic
On Sat, Sep 3, 2022 at 12:09 PM Julien Rouhaud wrote:
> Hi,
>
> On Sat, Sep 03, 2022 at 10:36:37AM +0500, Ibrar Ahmed wrote:
> >
> > Hi Kyotaro Horiguchi, Fabien Coelho, Daniel Gustafsson,
> >
> > Since you haven't had time to write a review the last many days, the
> author
> > replied
> > with
Hi,
On Sat, Sep 03, 2022 at 10:36:37AM +0500, Ibrar Ahmed wrote:
>
> Hi Kyotaro Horiguchi, Fabien Coelho, Daniel Gustafsson,
>
> Since you haven't had time to write a review the last many days, the author
> replied
> with a rebased patch for a long time and never heard. We've taken your name
>
On Mon, Mar 28, 2022 at 8:35 AM Yugo NAGATA wrote:
> On Fri, 25 Mar 2022 16:19:54 -0400
> Tom Lane wrote:
>
> > Fabien COELHO writes:
> > >> [...] One way to avoid these errors is to send Parse messages before
> > >> pipeline mode starts. I attached a patch to fix to prepare commands
> at
> >
On Fri, 25 Mar 2022 16:19:54 -0400
Tom Lane wrote:
> Fabien COELHO writes:
> >> [...] One way to avoid these errors is to send Parse messages before
> >> pipeline mode starts. I attached a patch to fix to prepare commands at
> >> starting of a script instead of at the first execution of the
Fabien COELHO writes:
>> [...] One way to avoid these errors is to send Parse messages before
>> pipeline mode starts. I attached a patch to fix to prepare commands at
>> starting of a script instead of at the first execution of the command.
> ISTM that moving prepare out of command execution
Hi Horiguchi-san,
On Thu, 27 Jan 2022 17:50:25 +0900 (JST)
Kyotaro Horiguchi wrote:
> At Tue, 16 Nov 2021 02:26:43 +0900, Yugo NAGATA wrote
> in
> > Thank you for pointing it out!
> > I attached the updated patch.
>
> I think we want more elabolative comment for the new place of
> preparing
At Tue, 16 Nov 2021 02:26:43 +0900, Yugo NAGATA wrote in
> Thank you for pointing it out!
> I attached the updated patch.
I think we want more elabolative comment for the new place of
preparing as you mentioned in the first mail.
At Fri, 16 Jul 2021 15:30:13 +0900, Yugo NAGATA wrote in
> One
Hello Daniel Gustafsson,
On Mon, 15 Nov 2021 14:13:32 +0100
Daniel Gustafsson wrote:
> > On 21 Jul 2021, at 03:49, Yugo NAGATA wrote:
>
> > I attached the updated patch v2, which includes a comment fix and a TAP
> > test.
>
> This patch fails the TAP test for pgbench:
Thank you for
> On 21 Jul 2021, at 03:49, Yugo NAGATA wrote:
> I attached the updated patch v2, which includes a comment fix and a TAP test.
This patch fails the TAP test for pgbench:
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 25 just
On Mon, 19 Jul 2021 10:51:36 +0900
Yugo NAGATA wrote:
> Hello Fabien,
>
> On Sat, 17 Jul 2021 07:03:01 +0200 (CEST)
> Fabien COELHO wrote:
>
> >
> > Hello Yugo-san,
> >
> > > [...] One way to avoid these errors is to send Parse messages before
> > > pipeline mode starts. I attached a patch
Hello Fabien,
On Sat, 17 Jul 2021 07:03:01 +0200 (CEST)
Fabien COELHO wrote:
>
> Hello Yugo-san,
>
> > [...] One way to avoid these errors is to send Parse messages before
> > pipeline mode starts. I attached a patch to fix to prepare commands at
> > starting of a script instead of at the
Hello Yugo-san,
[...] One way to avoid these errors is to send Parse messages before
pipeline mode starts. I attached a patch to fix to prepare commands at
starting of a script instead of at the first execution of the command.
What do you think?
ISTM that moving prepare out of command
Hello,
I found that using "BEGIN ISOLATINO LEVEL SERIALIZABLE" in a pipline with
prepared statement makes pgbench abort.
$ cat pipeline.sql
\startpipeline
begin isolation level repeatable read;
select 1;
end;
\endpipeline
$ pgbench -f pipeline.sql -M prepared -t 1
pgbench (15devel)
26 matches
Mail list logo
