Обсуждение: BUG #13470: Logical replication 'invalid memory alloc'

Поиск
Список
Период
Сортировка

BUG #13470: Logical replication 'invalid memory alloc'

От
kotlarski.krzysztof@gmail.com
Дата:
The following bug has been logged on the website:

Bug reference:      13470
Logged by:          Krzysztof Kotlarski
Email address:      kotlarski.krzysztof@gmail.com
PostgreSQL version: 9.4.4
Operating system:   Tested OS X and Gentoo
Description:


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:
 slot_name | xlog_position
-----------+---------------
 test_slot | 6/BD3C1950
(1 row)

CREATE TABLE
ALTER TABLE
INSERT 0 1
ALTER TABLE
UPDATE 1
ERROR:  invalid memory alloc request size 18446744073709551613
CONTEXT:  slot "test_slot", output plugin "test_decoding", in the change
callback, associated LSN 6/BD3D8C28

Bug affects all 9.4 versions.

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

От
Andres Freund
Дата:
Hi,

On 2015-06-26 10:03:33 +0000, kotlarski.krzysztof@gmail.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

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

От
Andres Freund
Дата:
Hi Krzysztof,

On 2015-06-26 18:34:46 +0200, Andres Freund wrote:
> On 2015-06-26 10:03:33 +0000, kotlarski.krzysztof@gmail.com wrote:
> 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?).

Just pushed the fix for the bug. It'll probably take a bit until the
next minor releases though.

Thanks for the report!

Regards,

Andres