Re: a raft of parallelism-related bug fixes
| От | Craig Ringer |
|---|---|
| Тема | Re: a raft of parallelism-related bug fixes |
| Дата | |
| Msg-id | CAMsr+YHg1drdktKpNQQnoNDFjofNG02uvKqvTWZ0odiDfx-Jcw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: a raft of parallelism-related bug fixes (Michael Paquier <michael.paquier@gmail.com>) |
| Ответы |
Re: a raft of parallelism-related bug fixes
|
| Список | pgsql-hackers |
On 18 February 2016 at 20:35, Michael Paquier <michael.paquier@gmail.com> wrote:
On Thu, Feb 18, 2016 at 5:35 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> On 2016/02/18 16:38, Craig Ringer wrote:
>> I should resurrect Abhijit's patch to allow the isolationtester to talk to
>> multiple servers. We'll want that when we're doing tests like "assert that
>> this change isn't visible on the replica before it becomes visible on the
>> master". (Well, except we violate that one with our funky
>> synchronous_commit implementation...)
>
> How much does (or does not) that overlap with the recovery test suite work
> undertaken by Michael et al? I saw some talk of testing for patches in
> works on the N synchronous standbys thread.
This sounds like poll_query_until in PostgresNode.pm (already on HEAD)
where the query used is something on pg_stat_replication for a given
LSN to see if a standby has reached a given replay position.
No, it's quite different, though that's something handy to have that I've emulated in the isolationtester using a plpgsql function.
The isolationtester changes in question allow isolationtester specs to run different blocks against different hosts/ports/DBs.
That lets you make assertions about replication behaviour. It was built for BDR and I think we'll need something along those lines in core if/when any kind of logical replication facilities land, for things like testing failover slots, etc.
The patch is at:
and might be something it's worth having in core as we expand testing of replication, failover, etc.
В списке pgsql-hackers по дате отправления: