Re: Another logical decoding assertion failure

On 08/15/2014 03:16 PM, Andres Freund wrote:
> On 2014-08-15 14:53:45 +0200, Antonin Houska wrote:
>> 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.

It was basically an experiment. I tried to capture changes into a table.
I don't know whether it's legal (i.e. whether the current call of
pg_logical_slot_get_changes() should include changes that the current
transaction did). Unloged / temporary table may be necessary for case
like this.

The reason I report it is that (I think), if such an use case is not
legal, it should be detected somehow and handled using ereport / elog.

// Tony