Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc?
От | Daniel Gustafsson |
---|---|
Тема | Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc? |
Дата | |
Msg-id | B0CDD2D6-DBCF-4E8B-8322-4B1D7ED50DCA@yesql.se обсуждение исходный текст |
Ответ на | Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc?
|
Список | pgsql-hackers |
> On 23 Aug 2023, at 23:02, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Daniel Gustafsson <daniel@yesql.se> writes: >> On 23 Aug 2023, at 21:22, Andres Freund <andres@anarazel.de> wrote: >>> I think there's more effective ways to make this cheaper. The basic thing >>> would be to use libpq instead of forking of psql to make a connection >>> check. > >> I had it in my head that not using libpq in pg_regress was a deliberate choice, >> but I fail to find a reference to it in the archives. > > I have a vague feeling that you are right about that. Perhaps the > concern was that under "make installcheck", pg_regress might be > using a build-tree copy of libpq rather than the one from the > system under test. As long as we're just trying to ping the server, > that shouldn't matter too much I think ... unless we hit problems > with, say, a different default port number or socket path compiled into > one copy vs. the other? That seems like it's probably a "so don't > do that" case, though. Ah yes, that does ring a familiar bell. I agree that using it for pinging the server should be safe either way, but we should document the use-with-caution in pg_regress.c if/when we go down that path. I'll take a stab at changing the psql retry loop for pinging tomorrow to see what it would look like. -- Daniel Gustafsson
В списке pgsql-hackers по дате отправления: