BUG #13470: Logical replication 'invalid memory alloc'
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.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs