On 2014-08-15 14:53:45 +0200, Antonin Houska wrote:
> http://www.postgresql.org/message-id/BLU436-SMTP12682D628F61AB9736099C3DCE80@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.
That's something separate, yes.
> 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.
> !>
Is this just to reproduce the issue, or are you really storing the
results of logical decoding in a table again?
Why? That'll just result in circularity, no? It's not something I
really thought about allowing when writing this. Possibly we can make it
work, but I don't really see the point. We obviously shouldn't just
crash, but that's not my point.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
