Re: [PATCH] pgbench: add multiconnect option

Bonjour Michaël,

>> Good. I was thinking of adding such capability, possibly for handling
>> connection errors and reconnecting…
>
> round-robin and random make sense. I am wondering how round-robin
> would work with -C, though? Would you just reuse the same connection
> string as the one chosen at the starting point.

Well, not necessarily, but this is debatable.

>> I was thinking of providing a allowing a list of conninfo strings with
>> repeated options, eg --conninfo "foo" --conninfo "bla"…
>
> That was my first thought when reading the subject of this thread:
> create a list of connection strings and pass one of them to
> doConnect() to grab the properties looked for. That's a bit confusing
> though as pgbench does not support directly connection strings,

They are supported because libpq silently assumes that "dbname" can be a
full connection string.

> and we should be careful to keep fallback_application_name intact.

Hmmm. See attached patch, ISTM that it does the right thing.

>> Your approach using PGSERVICEFILE also make sense!
>
> I am not sure that's actually needed here, as it is possible to pass
> down a service name within a connection string. I think that you'd
> better leave libpq do all the work related to a service file, if
> specified. pgbench does not need to know any of that.

Yes, this is an inconvenient with this approach, part of libpq machinery
is more or less replicated in pgbench, which is quite annoying, and less
powerful.

Attached my work-in-progress version, with a few open issues (eg probably
not thread safe), but comments about the provided feature are welcome.

I borrowed the "strategy" option, renamed policy, from the initial patch.
Pgbench just accepts several connection strings as parameters, eg:

pgbench ... "service=db1" "service=db2" "service=db3"

The next stage is to map scripts to connections types and connections
to connection types, so that pgbench could run W transactions against a
primary and R transactions agains a hot standby, for instance. I have a
some design for that, but nothing is implemented.

There is also the combination with the error handling patch to consider:
if a connection fails, a connection to a replica could be issued instead.

--
Fabien.