Re: Backporting BackgroundPsql

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Backporting BackgroundPsql
Дата
Msg-id 3486c490-f827-4898-8ba1-00c85646df75@dunslane.net
обсуждение исходный текст
Ответ на Re: Backporting BackgroundPsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers


On 2024-06-25 Tu 10:26 AM, Tom Lane wrote:
Andres Freund <andres@anarazel.de> writes:
On 2024-06-25 13:26:23 +0300, Heikki Linnakangas wrote:
1. Write the new test differently on backbranches. Before 664d757531, the
test needs to work a lot harder to use the background psql session, calling
pump() etc. That's doable, but as noted in the discussion that led to
664d757531, it's laborious and error-prone.

2. Backport commit 664d757531. This might break out-of-tree perl tests that
use the background_psql() function. I don't know if any such tests exist,
and they would need to be changed for v17 anyway, so that seems acceptable.
Anyone aware of any extensions using the perl test modules?

3. Backport commit 664d757531, but keep the existing background_psql()
function unchanged. Add a different constructor to get the v17-style
BackgroundPsql session, something like "$node->background_psql_new()".
Yes, I've wished for this a couple times. I think 2 or 3 would be reasonable.
I think 1) often just leads to either tests not being written or being
fragile...
I'd vote for (2).  (3) is just leaving a foot-gun for people to
hurt themselves with.
			


+1


I'd like to get rid of it in its current form at least. Just about all the uses I'm aware of could be transformed to use the Session object I've been working on, based either on FFI or a small XS wrapper for some of libpq.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michail Nikolaev
Дата:
Сообщение: Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY
Следующее
От: Jacob Champion
Дата:
Сообщение: Re: Direct SSL connection and ALPN loose ends