Re: Changeset Extraction v7.5
От | Thom Brown |
---|---|
Тема | Re: Changeset Extraction v7.5 |
Дата | |
Msg-id | CAA-aLv6Wg5PdJeyiU-ngTvr3V1_QCb8z5JeKyfuVuW1P1WCnqQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Changeset Extraction v7.5 (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Changeset Extraction v7.5
|
Список | pgsql-hackers |
On 7 February 2014 23:43, Andres Freund <andres@2ndquadrant.com> wrote: > On 2014-02-07 20:58:14 +0000, Thom Brown wrote: >> On 7 February 2014 19:35, Andres Freund <andres@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. > > Thanks, refreshed. > >> There appears to be a column named "slot_name" and "slottype". Could >> one of these have or not have the underscore for consistency? > > That's luckily already fixed... > >> 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: > >> 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. > > Thanks, that's a bug indeed. I have experimentally fixed the bug, not > sure whether I like the fix yet, or not. > > I've already fixed two issues caused by the rebase onto > 858ec11858a914d4c380971985709b6d6b7dd6fc. > > Is pushing to git sufficient for you, or shall I rebase and resend the > series? Sure, push it to git, I'll add your remote repo and checkout that branch. -- Thom
В списке pgsql-hackers по дате отправления: