Обсуждение: archive_command does not execute

George Wilk wrote:
>
> Hi,
>
>
>
> I am attempting to use the WAL archiving on a Solaris machine, running
> PostgreSQL 8.1.4.  The archive_command specified in the
> postgresql.conf file does not get executed, nor do I see any log
> entries showing errors etc.  What am I doing wrong here?
>
>
>
> Here is the relevant fragment of my conf file:
>
>
>
> fsync = on                              # turns forced synchronization
> on or off
>
> wal_sync_method = fsync         # the default is the first option
>
>                                         # supported by the operating
> system:
>
>                                         #   open_datasync
>
>                                         #   fdatasync
>
>                                         #   fsync
>
>                                         #   fsync_writethrough
>
>                                         #   open_sync
>
> #full_page_writes = on                  # recover from partial page writes
>
> #wal_buffers = 8                        # min 4, 8KB each
>
> #commit_delay = 0                       # range 0-100000, in microseconds
>
> #commit_siblings = 5                    # range 1-1000
>
>
>
> # - Checkpoints -
>
>
>
> checkpoint_segments = 1         # in logfile segments, min 1, 16MB each
>
> checkpoint_timeout = 30         #  range 30-3600, in second
>
> checkpoint_warning = 5          # in seconds, 0 is off
>
>
>
> # - Archiving -
>
>  archive_command = 'touch /var/lib/pgsql/bkp/myfile'
>
>
>
>
>
> Here is my log entry for the duration of the test:
>
>
>
> FATAL:  terminating connection due to administrator command
>
> LOG:  shutting down
>
> LOG:  database system is shut down
>
> LOG:  database system was shut down at 2007-06-19 07:48:03 EDT
>
> LOG:  checkpoint record is at 0/899E68
>
> LOG:  redo record is at 0/899E68; undo record is at 0/0; shutdown TRUE
>
> LOG:  next transaction ID: 2445; next OID: 16399
>
> LOG:  next MultiXactId: 1; next MultiXactOffset: 0
>
> LOG:  database system is ready
>
> LOG:  transaction ID wrap limit is 2147484146, limited by database
> "postgres"
>
>
>
> Thanks in advance,
>
>
>
> ~george
>
George

Looks like you are expecting the archive command to run when you shut
down the data base. It won't.  It only runs when the xlog gets full and
the system needs to recycle to a new logfile.

FWIW, here's what my solaris 9, posgresql 8.1.8 system has as an archive
command:

archive_command                          = 'test ! -f
/data/archivelog/%f && cp %p /data/archivelog/%f'

adjust as needed for your directory structure.

you need to run enough commited transactions through to fill up a 16 meg
xlog.  Then you will see the xlog getting archived (or your "myfile" get
updated).

>>> On Tue, Jun 19, 2007 at 11:16 AM, in message <46780175.3040207@jobflash.com>,
Tom Arthurs <tarthurs@jobflash.com> wrote:
>
> Looks like you are expecting the archive command to run when you shut
> down the data base. It won't.  It only runs when the xlog gets full and
> the system needs to recycle to a new logfile.

If you need to force a WAL file to test your backup process, try running
something like:

select pg_switch_xlog();

http://www.postgresql.org/docs/8.2/interactive/functions-admin.html#FUNCTIONS-ADMIN-BACKUP-TABLE

-Kevin

On Tue, 2007-06-19 at 08:17 -0400, George Wilk wrote:

>  archive_command = 'touch /var/lib/pgsql/bkp/myfile'

Presumably you understand that an archive_command like the above is not
ever going to do any archiving?

set

    log_min_messages = DEBUG1

if you want to see the archive messages.

But it seems like you should be able to do

    ls -l /var/lib/pgsql/bkp/myfile

to check your archive_command has succeeded, using your example

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com