Re: pgsql: Add 'basebackup_to_shell' contrib module.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net>
Subject: Re: pgsql: Add 'basebackup_to_shell' contrib module.
Date: 2022-03-29 21:19:44
Message-ID: CA+TgmoYUTKqBDH7FZ99baN8yECe-CGeqgigjM=FyQYe2BXiZEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Tue, Mar 29, 2022 at 4:36 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> It failed:
>
> https://cirrus-ci.com/task/5567070686412800
> https://api.cirrus-ci.com/v1/artifact/task/5567070686412800/log/contrib/basebackup_to_shell/tmp_check/log/001_basic_primary.log
> https://api.cirrus-ci.com/v1/artifact/task/5567070686412800/log/contrib/basebackup_to_shell/tmp_check/log/regress_log_001_basic

Hmm. The log here is not very informative. It just says that the first
time we tried to use the 'shell' target, it timed out. I suppose the
most obvious explanation for that is that the shell command we
executed timed out:

qq{type con > "$escaped_backup_path\\\\%f"}

But why should that be so? Does 'type con' not respond to EOF? I don't
see how that can be the case. Is our implementation of pclose broken?
If so, then I think COPY TO/FROM PROGRAM would be broken on Windows.

Any ideas?

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Andres Freund 2022-03-29 22:25:04 Re: pgsql: Add 'basebackup_to_shell' contrib module.
Previous Message Robert Haas 2022-03-29 21:01:52 pgsql: Make PostgreSQL::Test::Cluster::run_log() return a useful value.

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2022-03-29 21:56:02 Re: Extend compatibility of PostgreSQL::Test::Cluster
Previous Message David G. Johnston 2022-03-29 21:14:05 Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset