Re: pgsql: Add 'basebackup_to_shell' contrib module.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql: Add 'basebackup_to_shell' contrib module.
Дата
Msg-id 230838.1648659506@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgsql: Add 'basebackup_to_shell' contrib module.  (Andres Freund <andres@anarazel.de>)
Ответы Re: pgsql: Add 'basebackup_to_shell' contrib module.  (Andres Freund <andres@anarazel.de>)
Re: pgsql: Add 'basebackup_to_shell' contrib module.  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2022-03-30 12:34:34 -0400, Tom Lane wrote:
>> One refinement that comes to mind as I look at the patch is to distinguish
>> between "check" and "installcheck".  Not sure that's worthwhile, but not
>> sure it isn't, either.

> As it's just about "free" to do so, I see no reason not to go for showing that
> difference.  How about:

> echo "+++ (tap|regress|isolation) [install-]check in $(subdir) +++" && \

WFM.

> I see no reason to distinguish the PGXS / non-PGXs tap installcheck cases?

Agreed.

> Random aside: Am I the only one bothered by a bunch of places in
> Makefile.global.in quoting like
>   $(MAKE) -C '$(top_builddir)' DESTDIR='$(abs_top_builddir)'/tmp_install install
>'$(abs_top_builddir)'/tmp_install/log/install.log2>&1 
> and
>   rm -rf '$(CURDIR)'/tmp_check &&
> etc

Don't we need that to handle, say, build paths with spaces in them?
Admittedly we're probably not completely clean for such paths,
but that's not an excuse to break the places that do it right.

(I occasionally think about setting up a BF animal configured
like that, but haven't tried yet.)

            regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: basebackup/lz4 crash
Следующее
От: Dagfinn Ilmari Mannsåker
Дата:
Сообщение: Re: multithreaded zstd backup compression for client and server