Re: [HACKERS] Early locking option to parallel backup - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [HACKERS] Early locking option to parallel backup
Date
Msg-id 20171106143016.GG4628@tamriel.snowman.net
Whole thread Raw
In response to [HACKERS] Early locking option to parallel backup  (Lucas <lucas75@gmail.com>)
Responses Re: [HACKERS] Early locking option to parallel backup  (Lucas B <lucas75@gmail.com>)
List pgsql-hackers
Lucas,

* Lucas (lucas75@gmail.com) wrote:
> pg_dump was taking more than 24 hours to complete in one of my databases. I
> begin to research alternatives. Parallel backup reduced the backup time to
> little less than a hour, but it failed almost every time because of
> concurrent queries that generated exclusive locks. It is difficult to
> guarantee that my applications will not issue queries such as drop table,
> alter table, truncate table, create index or drop index for a hour. And I
> prefer not to create controls mechanisms to that end if I can work around
> it.

I certainly understand the value of pg_dump-based backups, but have you
considered doing file-based backups?  That would avoid the need to do
any in-database locking at all, and would give you the ability to do
PITR too.  Further, you could actually restore that backup to another
system and then do a pg_dump there to get a logical representation (and
this would test your physical database backup/restore process too...).

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Raúl Marín Rodríguez
Date:
Subject: Re: [HACKERS] pow support for pgbench
Next
From: Юрий Соколов
Date:
Subject: Re: [HACKERS] Small improvement to compactify_tuples