On 2014-08-15 14:53:45 +0200, Antonin Houska wrote: > http://www.postgresql.org/message-id/blu436-smtp12682d628f61ab9736099c3dc...@phx.gbl > recalls me that I also saw an assertion failure recently. Although I > wanted to isolate and report my issue when my vacation is over, this > report made me curious whether I saw the same. Eventually it seems to be > a different symptom. > > Following are the steps that trigger the failure in my environment > (9.5devel), although it's not always that straightforward - sometimes I > need to create and populate one more table. (I use the 'test_decoding' > contrib module.) > > > postgres=# SELECT pg_create_logical_replication_slot('my_slot', > 'test_decoding'); > pg_create_logical_replication_slot > ------------------------------------ > (my_slot,0/16F3B30) > (1 row) > > postgres=# CREATE TABLE a AS SELECT * FROM > pg_logical_slot_get_changes('my_slot', NULL, NULL) WITH NO DATA; > SELECT 0 > postgres=# INSERT INTO a SELECT * FROM > pg_logical_slot_get_changes('my_slot', NULL, NULL); > INSERT 0 2 > postgres=# INSERT INTO a SELECT * FROM > pg_logical_slot_get_changes('my_slot', NULL, NULL); > The connection to the server was lost. Attempting reset: Failed. > !>
This was actually triggered by a bug in logical decoding. I've pushed a fix. Thanks for the report! I still think it's a bad idea to do something like the above, but even after a fair amount of thinking I can't come up with a case that's an actual problem. So I think we can just allow it. Obviously it's not a good idea to use a output plugin without filtering, and a logged table for this - each subsequent get_changes() will otherwise contain the rows inserted into the table the previous round. The attached regression tests contains pretty output demonstrating that: BEGIN table public.changeresult: INSERT: data[text]:'BEGIN' table public.changeresult: INSERT: data[text]:'table public.changeresult: INSERT: data[text]:''BEGIN''' table public.changeresult: INSERT: data[text]:'table public.changeresult: INSERT: data[text]:''table public.somechange: INSERT: id[integer]:1''' table public.changeresult: INSERT: data[text]:'table public.changeresult: INSERT: data[text]:''COMMIT''' table public.changeresult: INSERT: data[text]:'COMMIT' table public.changeresult: INSERT: data[text]:'BEGIN' table public.changeresult: INSERT: data[text]:'table public.changeresult: INSERT: data[text]:''BEGIN''' table public.changeresult: INSERT: data[text]:'table public.changeresult: INSERT: data[text]:''table public.changeresult: INSERT: data[text]:''''BEGIN''''''' table public.changeresult: INSERT: data[text]:'table public.changeresult: INSERT: data[text]:''table public.changeresult: INSERT: data[text]:''''table public.somechange: INSERT: id[integer]:1''''''' table public.changeresult: INSERT: data[text]:'table public.changeresult: INSERT: data[text]:''table public.changeresult: INSERT: data[text]:''''COMMIT''''''' table public.changeresult: INSERT: data[text]:'table public.changeresult: INSERT: data[text]:''COMMIT''' table public.changeresult: INSERT: data[text]:'COMMIT' COMMIT (14 rows) Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
