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
