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> >wrote: >> 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 >processed >> -- 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: http://www.postgresql.org/mailpref/pgsql-hackers
