RE: Per-table resync for logical replication subscriptions - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: Per-table resync for logical replication subscriptions
Date
Msg-id OS9PR01MB1214999564BA9BDCE6015BBB4F5A32@OS9PR01MB12149.jpnprd01.prod.outlook.com
Whole thread
In response to Re: Per-table resync for logical replication subscriptions  (Cagri Biroglu <cagri.biroglu@adyen.com>)
Responses Re: Make COPY format extendable: Extract COPY TO format implementations
Re: Per-table resync for logical replication subscriptions
List pgsql-hackers
Dear Cagri,

Hi, thanks for updating the patch. Sorry I could not reply to your latest post,
because it was blocked by the company's rule.

Few comments:
01.
According to ExecuteTruncate(), we did some additional check like
truncate_check_rel() and truncate_check_perms(). Is it needed here? If not we can
add code comment here. At least, InvokeObjectTruncateHoo() seems needed.

02. Question:
This command drops replication origins and remote slots, which cannot be rolled back.
So what should users do the command fails?

03.
Also, such operations should be done after the transctional ones (ExecuteTruncateGuts).

04.
I found that ATTACH PARTITION/DETACH PARTITION CONCURRENTLY command acquires the
ShareUpdateExclusive Lock for the root table. This can cause that tables are
missed to be truncated, or detached tables can be truncated.
One primitive idea for fixing is to check whether the schema structure is modified
after acquiring the AccesExclusive lock, but there may be better approaches.

Best regards,
Hayato Kuroda
FUJITSU LIMITED


Attachment

pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Row pattern recognition
Next
From: David Rowley
Date:
Subject: Re: Reduce memory overheads for storing a Memoize tuple