Re: [COMMITTERS] pgsql: Establish conventions about global objectnames used in regressi
От | Peter Geoghegan |
---|---|
Тема | Re: [COMMITTERS] pgsql: Establish conventions about global objectnames used in regressi |
Дата | |
Msg-id | CAH2-WzkuCydgOmUh=uVtyUvthkAwOeqqGLpnRvTWwJhvN9pSbg@mail.gmail.com обсуждение исходный текст |
Ответ на | pgsql: Establish conventions about global object names used in regressi (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-committers |
On Sat, Sep 21, 2019 at 10:52 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > would work. The naming convention I was putting in didn't allow for > identical DB and user names, and it didn't seem to me that it was > worth overriding that convention to keep this particular test > result the same. The error output still proves that ecpg *tried* > to connect to the database named the same as the user, which is > the only real point of this test case as compared to its siblings. > And why not test the error path, anyway? Seems reasonable to me. > > I'm asking about this because I find that "make installcheck-world" > > sometimes fails at this point when run against my local installation > > -- the test "test connect/test" reliably fails. > > Um, you're confusing me ... is it "sometimes", or is it "reliably"? It's reliable. Doesn't have to be a Valgrind build, or even a debug build. > It does seem like there might be something to poke at here. We never > did figure out quite what the other reporter was seeing. > > Given the lack of overlap of user and database names, we can be > pretty darn certain that the test case shouldn't accidentally > succeed due to timing issues. I wonder if there could be some kind > of uninitialized-variable bug inside ecpg that lets it sometimes > connect to the wrong DB name (perhaps one it'd previously connected > to) if the DB name is omitted from the command? That seems possible. IIRC Valgrind has certain limitations when it comes to detecting stack corruption. -- Peter Geoghegan
В списке pgsql-committers по дате отправления: