Re: [BUGS] BUG #14769: Logical replication error "cache lookup failedfor type 0"

On 03/08/17 01:59, scott@deltaex.com wrote:
> The following bug has been logged on the website:
> 
> Bug reference:      14769
> Logged by:          Scott Milliken
> Email address:      scott@deltaex.com
> PostgreSQL version: 10beta2
> Operating system:   Linux 4.10.0-27-generic #30~16.04.2-Ubuntu
> Description:        
> 
> I'm testing postgresql 10beta2, and found a bug with logical replication.
> The bug halts logical replication, and produces the error "cache lookup
> failed for type 0" in the secondary's log.
> 
> The error can be reproduced by dropping a column in a replicated table. When
> a column is dropped, it zeroes out attypeid in pg_attribute:
> 
> ```
> test=# select * from pg_attribute where attrelid =
> 'public.testtbl'::regclass and atttypid = 0 order by attnum;
> -[ RECORD 1 ]-+-----------------------------
> attrelid      | 16386
> attname       | ........pg.dropped.2........
> atttypid      | 0
> attstattarget | 0
> attlen        | -1
> attnum        | 2
> attndims      | 0
> attcacheoff   | -1
> atttypmod     | -1
> attbyval      | f
> attstorage    | x
> attalign      | i
> attnotnull    | f
> atthasdef     | f
> attidentity   | 
> attisdropped  | t
> attislocal    | t
> attinhcount   | 0
> attcollation  | 100
> attacl        | ¤
> attoptions    | ¤
> attfdwoptions | ¤
> ```
> 
> Perhaps there's a missing check against pg_attribute.attisdropped
> somewhere?
> 

Good catch! Looks like we didn't initialize the attribute map for
locally dropped columns. Once I did that I found there is also typo in
slot_modify_cstrings() which uses wrong value from the remote side, that
is also made visible by your example.

Both are fixed in attached patch.

-- 
  Petr Jelinek                  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs