RE: Parallel Apply - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: Parallel Apply
Date
Msg-id TY7PR01MB145541DD6F5BE4CD403BA39FDF586A@TY7PR01MB14554.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: Parallel Apply  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
List pgsql-hackers
Happy new year hackers,

I found that CFbot sometimes failed tests. Per my analysis, there were two
issues in the 0005 patch. The following describes two changes.

1)
Took care of the case where an empty prepared transaction was replicated.
The leader worker would gather even such transactions in get_flush_position()
and try to clean up a replica identity hash. If the empty transaction is firstly
replicated after the worker is launched, however, the replica identity hash is
not yet initialized, which causes the segmentation fault. To address the issue,
a guard was added to the cleanup function.

As far as I know, an empty prepared transaction can happen if
  a) the prepared transaction has already been rolled back while decoding, or
  b) all changes are skipped.
Added test sometimes meets a) due to the timing issue.

2)
Fixed a timing issue in 050_parallel_apply.pl. The test sets the two_phase
option to true, but sometimes it fails if the apply workers are not yet finished
after the subscription is disabled. Now the test ensures there are no apply workers.

Best regards,
Hayato Kuroda
FUJITSU LIMITED


Attachment

pgsql-hackers by date:

Previous
From: Nikhil Kumar Veldanda
Date:
Subject: Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)
Next
From: Peter Eisentraut
Date:
Subject: Re: Use Python "Limited API" in PL/Python