Re: incoorect restore_command

2021-02-24 Thread Fujii Masao




On 2021/02/24 16:52, Michael Paquier wrote:

On Wed, Feb 24, 2021 at 07:24:17AM +0100, Philipp Gramzow wrote:

I agree, using a proper extension would be more straightforward. I'm sure
that's the reason why someone changed our archive_command.


Okay, let's do so in the docs then.  Others may have comments to
offer, so I'll first wait a bit before applying my suggestion from
upthread.


I agree with this change.

But I have one question; why do those commands use different
archive directories? Isn't it better to use the same one?

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION




Re: Inaccuracy in wal_receiver_status_interval parameter description

2021-02-24 Thread Dmitriy Kuzmin
Thanks.

Will this change be made in the documentation for all Postgresql versions?

Best regards,
Dmitriy Kuzmin

ср, 24 февр. 2021 г. в 12:19, Michael Paquier :

> On Sun, Feb 21, 2021 at 09:21:41PM -0300, Euler Taveira wrote:
> > LGTM.
>
> Thanks, applied.
> --
> Michael
>


Re: Inaccuracy in wal_receiver_status_interval parameter description

2021-02-24 Thread Michael Paquier
On Wed, Feb 24, 2021 at 11:16:57PM +1000, Dmitriy Kuzmin wrote:
> Will this change be made in the documentation for all Postgresql versions?

This wording has been introduced back in 2011 as of b186523, and
nobody complained about that until now, so I did not see a strong need
to back-patch it.  Would people prefer a back-patch for that?
--
Michael


signature.asc
Description: PGP signature


Re: incoorect restore_command

2021-02-24 Thread Michael Paquier
On Wed, Feb 24, 2021 at 08:15:59PM +0900, Fujii Masao wrote:
> But I have one question; why do those commands use different
> archive directories? Isn't it better to use the same one?

storage.sgml uses /var/lib/pgsql/data for the location of the data,
and the archive path is a mix between /mnt/server/archivedir/ and
/var/lib/pgsql/archive/.  However, the former is used for
pg_archivecleanup and in postgresql.conf.sample, so why not just using
/mnt/server/archivedir/ in backup.sgml?  Please see the attached.
--
Michael
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 3c8aaed0b6..d8a60f7529 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1484,7 +1484,7 @@ restore_command = 'cp /mnt/server/archivedir/%f %p'
   on, and set up an archive_command that performs
   archiving only when a switch file exists.  For example:
 
-archive_command = 'test ! -f /var/lib/pgsql/backup_in_progress || (test ! -f /var/lib/pgsql/archive/%f && cp %p /var/lib/pgsql/archive/%f)'
+archive_command = 'test ! -f /var/lib/pgsql/backup_in_progress || (test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f)'
 
   This command will perform archiving when
   /var/lib/pgsql/backup_in_progress exists, and otherwise
@@ -1501,7 +1501,7 @@ psql -c "select pg_start_backup('hot_backup');"
 tar -cf /var/lib/pgsql/backup.tar /var/lib/pgsql/data/
 psql -c "select pg_stop_backup();"
 rm /var/lib/pgsql/backup_in_progress
-tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/
+tar -rf /var/lib/pgsql/backup.tar /mnt/server/archivedir/
 
   The switch file /var/lib/pgsql/backup_in_progress is
   created first, enabling archiving of completed WAL files to occur.
@@ -1520,11 +1520,11 @@ tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/
   If archive storage size is a concern, you can use
   gzip to compress the archive files:
 
-archive_command = 'gzip < %p > /var/lib/pgsql/archive/%f'
+archive_command = 'gzip < %p > /mnt/server/archivedir/%f.gz'
 
   You will then need to use gunzip during recovery:
 
-restore_command = 'gunzip < /mnt/server/archivedir/%f > %p'
+restore_command = 'gunzip < /mnt/server/archivedir/%f.gz > %p'
 
  
 


signature.asc
Description: PGP signature


Re: pgbench: supports PGDATABASE / warning about -d

2021-02-24 Thread Michael Paquier
On Wed, Feb 24, 2021 at 02:29:31PM +0900, Michael Paquier wrote:
> Yeah, let's fix that.  Adding only PGDATABASE to the list of
> environment variables supported does not look enough to me, so I
> propose the simple patch attached to clarify what happens to dbname in
> more details.

Applied this one as of 9e9b5c0.  5aaa584 is the original change that
updated the doc of pgbench to mention all the supported environment
variable, so this has been backpatched down to 12.
--
Michael


signature.asc
Description: PGP signature