Re: BUG #14769: Logical replication error "cache lookup failed for type 0"

On 03/08/17 01:59, scott(at)deltaex(dot)com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 14769
> Logged by: Scott Milliken
> Email address: scott(at)deltaex(dot)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