On 24/04/17 04:31, Petr Jelinek wrote:
> On 24/04/17 02:04, Andres Freund wrote:
>> Hi,
>>
>> Oh, and one more point: There desperately need to be tests exercising
>> "SQL via walsender". Including the issue of parallelism here, the missed
>> cancel handler, timeouts, and such. One way to do so is to use
>> pg_regress with an adjusted connection string (specifying
>> replication=database), doing the same for isolationtester, or using
>> dblink.
>>
>
> Well, there are some tests (the logical replication uses that
> functionality) and it's not quite clear to me what all to run there.
> I assume you don't want to rerun whole regression suite against
> walsender given the time it would take in normal tests (although I could
> see doing that optionally somehow) but then what to pick from there.
>
So actually maybe running regression tests through it might be
reasonable approach if we add new make target for it.
Attached patch shows how it could be done.
Patch adds new make target check-walsender-sql which runs serial
schedule of regression tests using replication connection (there is new
command line argument --replication-connection for pg_regress as well).
Reason for running serial schedule is that the max_walsenders setting
becomes problem when running parallel one.
Note that the first patch is huge. That's because I needed to add
alternative output for largeobject test because it uses fastpath
function calls which are not allowed over replication protocol.
As part of this I realized that the parser fallback that I wrote
originally for handling SQL in walsender is not robust enough as the
lexer would fail on some valid SQL statements. So there is also second
patch that does this using different approach which allows any SQL
statement.
Thoughts?
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
