> On 11 Mar 2026, at 03:18, Laurenz Albe <[email protected]> wrote: > > The question is whether the overall benefits of your proposal (which > certainly makes sense > in a setup like you describe) would be worth a performance and resource usage > regression like > the one I described above. Or can you see a way to modify your approach so > that that problem > can be avoided? Version proposed by Andrew Jackson [0] adds a connection option check_all_addrs. Off by default. This resolves potential problems of existing users. Best regards, Andrey Borodin. [0] https://commitfest.postgresql.org/patch/5396/
- [PATCH] libpq: try all addresses for a host before mov... Evgeny Kuzin
- Re: [PATCH] libpq: try all addresses for a host b... Tom Lane
- Re: [PATCH] libpq: try all addresses for a ho... Evgeny Kuzin
- Re: [PATCH] libpq: try all addresses for ... Laurenz Albe
- Re: [PATCH] libpq: try all addresses ... Andrey Borodin
- Re: [PATCH] libpq: try all addre... Laurenz Albe
- Re: [PATCH] libpq: try all addresses ... Evgeny Kuzin
- Re: [PATCH] libpq: try all addre... Greg Sabino Mullane
- Re: [PATCH] libpq: try all addre... Jacob Champion
- Re: [PATCH] libpq: try all a... Evgeny Kuzin
- Re: [PATCH] libpq: try a... Zsolt Parragi
- Re: [PATCH] libpq: try a... Greg Sabino Mullane
- Re: [PATCH] libpq: try all a... Alastair Turner
- Re: [PATCH] libpq: try all addresses for a ho... Andrey Borodin
- Re: [PATCH] libpq: try all addresses for ... Evgeny Kuzin
