Re: BUG #19686: Rolling back SET TABLESPACE - Mailing list pgsql-hackers

From shihao zhong
Subject Re: BUG #19686: Rolling back SET TABLESPACE
Date
Msg-id CAGRkXqTwGvh6Ce8RafmJ1nXvxfMe7DBOMQVcML=tzoT-BcEPCw@mail.gmail.com
Whole thread
In response to Re: BUG #19686: Rolling back SET TABLESPACE  (Manu <manuelreyesbravo@gmail.com>)
Responses Re: BUG #19686: Rolling back SET TABLESPACE
List pgsql-hackers
Hi Manu,

v6 looks good to me. The child CHECK case, VALIDATE CONSTRAINT and
sql_drop all leave 0 stale entries now. One small thing.

ATSetTableSpaceCopyIndexes() also runs for ALTER INDEX, so a plain
ALTER INDEX SET TABLESPACE in a pipeline now commits on its own.
Maybe only call it for tables and matviews.

I recently got interested in replication lag with physical
replication, so I also looked at the replay side on a standby. 

A plain top-level ALTER costs the same as master. In a transaction
block it costs more.

WAL size. The index copy is logged page by page, so the extra WAL
is the size of the indexes. Given they are mostly FPI, I think it is okay for
replicas to quickly catch up.

AccessExclusiveLock. Each index now gets one too, so one more lock
record per index goes to the standby. I think that is okay. The
table already has that lock, and queries lock the table before its
indexes, so nobody new is blocked.

Thanks,
Shihao




pgsql-hackers by date:

Previous
From: shihao zhong
Date:
Subject: Re: [Patch] New pg_stat_tablespace view
Next
From: shihao zhong
Date:
Subject: Re: Checkpointer write combining