Re: BUG #13470: Logical replication 'invalid memory alloc'

Hi,

On 2015-06-26 10:03:33 +0000, kotlarski(dot)krzysztof(at)gmail(dot)com wrote:
> Minimal reproductible example:
>
> SELECT * FROM pg_create_logical_replication_slot('test_slot',
> 'test_decoding');
> CREATE TABLE "t" ("a" character varying);
> ALTER TABLE "t" REPLICA IDENTITY FULL;
> INSERT INTO "t" ("a") VALUES ('a1');
> ALTER TABLE "t" ADD "b" character varying;
> UPDATE "t" SET "a" = 'a2';
> SELECT * FROM pg_logical_slot_get_changes('test_slot', NULL, NULL);
>
> Produces:

> ERROR: invalid memory alloc request size 18446744073709551613
> CONTEXT: slot "test_slot", output plugin "test_decoding", in the change
> callback, associated LSN 6/BD3D8C28

Ick.

The problem is that I used fastgetattr() in test_decoding's
tuple_to_stringinfo(). Which is normally ok, even though fragile,
because the new tuple's natts will always be tupledesc->natts. !FULL
replica identities can't contain nulls for pretty much the same reason.
But with FULL the *old*, preexisting, tuple will be logged - which can
have a lower natts value.

So this should just be a heap_getattr(), not a fastgetattr().

The next set of backbranch releases will contain the fix, until then you
could just fix it in test_decoding.c (or the plugin I guess you copied
the code to?).

Greetings,

Andres Freund