Re: Another logical decoding assertion failure - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Another logical decoding assertion failure
Date
Msg-id 20141113194344.GL13473@awork2.anarazel.de
Whole thread Raw
In response to Another logical decoding assertion failure  (Antonin Houska <antonin.houska@gmail.com>)
List pgsql-hackers
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.
> 
> 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:BEGINtable 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'tablepublic.changeresult: INSERT: data[text]:'BEGIN'table public.changeresult: INSERT:
data[text]:'tablepublic.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]:'tablepublic.changeresult: INSERT: data[text]:''table public.changeresult: INSERT:
data[text]:''''COMMIT'''''''tablepublic.changeresult: INSERT: data[text]:'table public.changeresult: INSERT:
data[text]:''COMMIT'''tablepublic.changeresult: INSERT: data[text]:'COMMIT'COMMIT
 
(14 rows)

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: group locking: incomplete patch, just for discussion
Next
From: Andres Freund
Date:
Subject: Re: logical decoding - reading a user catalog table