Re: Creating streaming replication standby

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

In response to

Browse pgsql-hackers by date

  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