yes i can.
reproduce the step:
1. create table testcase(a int,b int,c text,d text);
2. ALTER TABLE ONLY testcase REPLICA IDENTITY FULL;
3. /u01/pgsql/bin/psql -d postgres -p5559 -c "copy testcase from ‘/tmp/testcase.csv' DELIMITER E'\t' csv QUOTE '''' ";
4. select pg_create_logical_replication_slot('logical_slot','test_decoding');
--update one row
5. update testcase set b = 1;
6. select count(*) from pg_logical_slot_peek_binary_changes('logical_slot',NULL,NULL);
7. postgres=# select count(*) from pg_logical_slot_peek_binary_changes('logical_slot',NULL,NULL);
ERROR: compressed data is corrupt
------------------ 原始邮件 ------------------
发件人: "Michael Paquier";<michael.paquier@gmail.com>;
发送时间: 2016年12月27日(星期二) 中午1:29
收件人: "anderson"<anderson2013@qq.com>;
抄送: "pgsql-bugs"<pgsql-bugs@postgresql.org>;
主题: Re: [BUGS] [BUG] pg9.4.10 Logical decoding did not get the correct oldtuplelen
On Tue, Dec 27, 2016 at 12:30 PM, anderson <anderson2013@qq.com> wrote:
> I found a postgresql 9.4.10 Logical decoding problem
> heapam.c:6976 xlog store incorrect oldtuplen when tuplelen is greater than
> the value field of uint16.
>
> a uint32 variable is assigned to uint16
>
> The structure that holds the oldkey length is:
> typedef struct xl_heap_header_len
> {
> uint16 t_len;
> xl_heap_header header;
> } xl_heap_header_len;
>
> The problem will lead to logic decoding failure when oldtuplene > 65535 and
> relreplident = FULL.
> The table that triggers the problem is usually relreplident = FULL.
Do you have a test case able to reproduce the problem?
--
Michael
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs