Re: [HACKERS] walsender & parallelism
От | Petr Jelinek |
---|---|
Тема | Re: [HACKERS] walsender & parallelism |
Дата | |
Msg-id | 13973428-ca0b-b329-7f32-f15150e10334@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] walsender & parallelism (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] walsender & parallelism
Re: [HACKERS] walsender & parallelism |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: