Re: Restore replication settings when modifying a field type - Mailing list pgsql-hackers

From Quan Zongliang
Subject Re: Restore replication settings when modifying a field type
Date
Msg-id 0b190c18-1ab0-22ab-f249-af58ee967807@foxmail.com
Whole thread Raw
In response to Re: Restore replication settings when modifying a field type  (Quan Zongliang <quanzongliang@foxmail.com>)
Responses Re: Restore replication settings when modifying a field type
List pgsql-hackers
On 2020/1/15 08:30, Quan Zongliang wrote:
> On 2020/1/3 17:14, Peter Eisentraut wrote:
>> On 2019-11-01 04:39, Euler Taveira wrote:
>>> ATExecAlterColumnType records everything that depends on the column
>>> and for indexes it saves the definition (via pg_get_indexdef_string).
>>> Definition is not sufficient for reconstructing the replica identity
>>> information because there is not such keyword for replica identity in
>>> CREATE INDEX. The new index should call relation_mark_replica_identity
>>> to fix pg_index.indisreplident.
>>
>> Yeah, I don't think we need to do the full dance of reverse compiling 
>> the SQL command and reexecuting it, as the patch currently does.  
>> That's only necessary for rebuilding the index itself.  For re-setting 
>> the replica identity, we can just use the internal API as you say.
>>
>> Also, a few test cases would be nice for this patch.
>>
> 
> I'm a little busy. I'll write a new patch in a few days.

new patch attached.


test case 1:
create table t1 (col1 int,col2 int not null,
   col3 int not null,unique(col2,col3));
alter table t1 replica identity using index t1_col2_col3_key;
alter table t1 alter col3 type text;
alter table t1 alter col3 type smallint using col3::int;

test case 2:
create table t2 (col1 varchar(10), col2 text not null,
   col3 timestamp not null,unique(col2,col3),
   col4 int not null unique);
alter table t2 replica identity using index t2_col2_col3_key;
alter table t2 alter col3 type text;
alter table t2 replica identity using index t2_col4_key;
alter table t2 alter col4 type timestamp using '2020-02-11'::timestamp;


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: subplan resets wrong hashtable
Next
From: Jeff Davis
Date:
Subject: Re: Memory-Bounded Hash Aggregation