From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
---|---|
To: | michael(at)paquier(dot)xyz |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Creating streaming replication standby |
Date: | 2018-04-02 23:09:18 |
Message-ID: | 20180403.080918.146441215216111922.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> A complain that I have about such concepts is that it creates a
> dependency between utilities which are usually classified by
> distributions as client-side (pg_basebackup goes to postgresql-client
> for Debian), and the server itself. There is perhaps room for an
> extension though. If many vendors are providing such an option at SQL
> level, it would mean that there is demand for it.
I think new function/SQL would not be necessarily bound to
pg_basebackup. Rather, new GUC would be invented so that which tool is
executed by the function/SQL for backup. For example,
create_streaming_standby_command = '/path/to/create_standby.sh %h %p %d'
where %h is the host, %p is the port on which postmaster is listening
on and %d is the database cluster directory for the standby server to
be created.
Then the new function (suppose it is called
"create_streaming_standby") would be called something like:
create_streaming_standby('standby_host', 5432, '/usr/local/pgsql/data')
and it execute create_standby.sh with the arguments.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-04-02 23:23:24 | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
Previous Message | Anthony Iliopoulos | 2018-04-02 23:05:44 | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |