On April 7, 2016 2:26:41 AM GMT+02:00, Michael Paquier 
<michael.paqu...@gmail.com> wrote:
>On Thu, Apr 7, 2016 at 12:55 AM, Andres Freund <and...@anarazel.de>
>> On 2016-04-06 16:49:17 +0100, Simon Riggs wrote:
>>> Perhaps easy to solve, but how do we test it is solved?
>> Maybe something like
>> -- drain
>> pg_logical_slot_get_changes(...);
>> -- generate message in different database, to ensure it's not
>> -- in this database
>> \c template1
>> SELECT pg_logical_emit_message(...);
>> \c postgres
>> -- check
>> pg_logical_slot_get_changes(..);
>> It's a bit ugly to hardcode database names :/
>When running installcheck, there is no way to be sure that databases
>template1 and/or postgres exist on a server, so this test would fail
>because of that.

No need to hardcode postgres, see Petr's reply. I'm not concerned about 
template 1 not being there -if you tinkered with things in that level it's 
unlikely that tests will succeed.  Also, remember, this is in a test cluster 
created by the regression script, and there's no installcheck support anyway 
(because of the required settings for logical decoding) anyway
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to