Re: pgbench and timestamps (bounced)

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>, Jaime Soler <jaime(dot)soler(at)gmail(dot)com>
Subject: Re: pgbench and timestamps (bounced)
Date: 2021-01-13 15:53:09
Message-ID: alpine.DEB.2.22.394.2101131649420.699567@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello Tom,

>>> Hi, this entry is "Waiting on Author" and the thread was inactive for a
>>> while. I see this discussion still has some open questions. Are you
>>> going to continue working on it, or should I mark it as "returned with
>>> feedback" until a better time?
>> IMHO the proposed fix is reasonable and addresses the issue.
>> I have responded to Tom's remarks about it, and it is waiting for his
>> answer to my counter arguments. So ISTM that the patch is currently still
>> waiting for some feedback.
> It looks like my unhappiness with injecting a pthread dependency into
> pgbench is going to be overtaken by events in the "option delaying
> queries" thread [1]. However, by the same token there are some conflicts
> between the two patchsets, and also I prefer the other thread's approach
> to portability (i.e. do it honestly, not with a private portability layer
> in pgbench.c). So I'm inclined to put the parts of this patch that
> require pthreads on hold till that lands.

Ok. This is fair enough. Portability is a pain thanks to Windows vs MacOS
vs Linux approaches of implementing or not a standard.

> What remains that we could do now, and perhaps back-patch, is point (2)
> i.e. disallow digits as the first character of a pgbench variable name.

I'm fine with that.

> That would be enough to "solve" the original bug report, and it does seem
> like it could be back-patched, while we're certainly not going to risk
> back-patching anything as portability-fraught as introducing mutexes.


I'm unable to do much pg work at the moment, but this should be eased
quite soon.

> [1]

Fabien Coelho - CRI, MINES ParisTech

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-01-13 16:13:15 Re: pg_preadv() and pg_pwritev()
Previous Message Tom Lane 2021-01-13 15:28:26 Re: Alter timestamp without timezone to with timezone rewrites rows