Re: pg_dump-restore concurrency

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_dump-restore concurrency
Date: 2010-07-21 16:41:29
Message-ID: 87fwzc4wjq.fsf@cbbrowne.afilias-int.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

yasinmalli(at)gmail(dot)com (paladine) writes:
> Hi all
> I prefer doing pg_dump - psql restore to vacuum full and
> is there anyone know whether postgresql can insert data concurrently while
> restoring a table for not losing any data.
>
> thanks in advance...

The problem scenario that I'd expect is with the handling of sequences.

A pg_dump puts setval() calls to set the values of sequences near
the end of processing, which means that anything using sequences to
assign IDs is likely to lead to some anomalous behaviour:

- At the start, the sequence will have [some value]

- Your concurrent inserts will store data that starts at that point

- A setval() call from the pg_dump will set the sequence to [another
value]

It is entirely possible that a failure will take place anywhere in here
due to clashes between sequence values, if the sequence is used to
ensure uniqueness of values used for unique indices.

You could presumably avoid some of the problems with this by using UUIDs
in such cases, but that adds a different set of challenges.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','gmail.com').
"On a normal ascii line, the only safe condition to detect is a
'BREAK' - everything else having been assigned functions by Gnu
EMACS." -- Tarl Neustaedter

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Paul Ramsey 2010-07-21 17:45:18 Re: locating cities within a radius of another
Previous Message Ben Chobot 2010-07-21 16:07:56 Re: text vs. varchar