On 7 February 2014 19:35, Andres Freund <and...@2ndquadrant.com> wrote: > 0004: wal_decoding: Documentation for replication slots and changeset > extraction
The usage of pg_create_decoding_replication_slot does show the "(1 row)" line. The output of "SELECT * FROM pg_replication_slots;" is out-of-date. There appears to be a column named "slot_name" and "slottype". Could one of these have or not have the underscore for consistency? The example also shows output from pg_decoding_slot_get_changes after inserting 2 rows, but when I run the same example, there are no rows returned: # BEGIN; BEGIN *# INSERT INTO data(data) VALUES('1'); INSERT 0 1 *# INSERT INTO data(data) VALUES('1'); INSERT 0 1 *# COMMIT; COMMIT # SELECT * FROM pg_decoding_slot_get_changes('regression_slot', 'now', 'include-xids', '0'); location | xid | data ----------+-----+------ (0 rows) I inserted a single row outside of a transaction, and got the expected output. Then I ran the above again, and got an output, but an unexpected one: SELECT * FROM pg_decoding_slot_get_changes('regression_slot', 'now', 'include-xids', '0'); location | xid | data -----------+-----+----------------------------------------------- 0/16C8B90 | 769 | BEGIN 0/16C8D50 | 769 | table "data": INSERT: id[int4]:3 data[text]:1 0/16C8D50 | 769 | COMMIT (3 rows) And running the transaction with inserts again, there's no output from that same function command. I always get an output from isolated INSERT statements. I should point out that in my .psqlrc file I have "\set ON_ERROR_ROLLBACK". If I use psql -X, this symptom no longer occurs, so I think the automatic savepoints are interfering, and the effect appears to be inconsistent. -- Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers