Re: Bug in pgbench prepared statements

On Fri, Dec 01, 2023 at 07:06:40PM -0800, Lev Kokotov wrote: > Attached. PR against master also here > , just to make sure it's > mergeable . Thanks for the updated patch. It looks sensible seen fr

Re: Bug in pgbench prepared statements

> The patch you have sent does not apply cleanly on the master branch, > could you rebase please? Attached. PR against master also here , just to make sure it's mergeable . > Wouldn't it > better t

Re: Bug in pgbench prepared statements

On Thu, Nov 30, 2023 at 07:15:54PM -0800, Lev Kokotov wrote: >> I see prepareCommand() is called one more time in >> prepareCommandsInPipeline(). Should you also check the return value >> there? > > Yes, good catch. New patch attached. Agreed that this is not really helpful as it stands >> It ma

Re: Bug in pgbench prepared statements

> I see prepareCommand() is called one more time in > prepareCommandsInPipeline(). Should you also check the return value > there? Yes, good catch. New patch attached. > It may also be useful to throw this patch on the January commitfest if > no one else comes along to review/commit it. First ti

Re: Bug in pgbench prepared statements

On Wed Nov 29, 2023 at 7:38 PM CST, Lev Kokotov wrote: Patch attached, if there is any interest in fixing this small bug. I see prepareCommand() is called one more time in prepareCommandsInPipeline(). Should you also check the return value there? It may also be useful to throw this patch on

Bug in pgbench prepared statements

Hi, I noticed something that looks like a bug in pgbench when using the prepared protocol. pgbench assumes that all prepared statements are prepared correctly, even if they contain errors (e.g. syntax, column/table doesn't exist, etc.). My test script is just: SELECT one; The output looks somet