Re: Another logical decoding assertion failure

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