| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Benjamin Krajmalnik <kraj(at)illumen(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: Howto: Using PITR recovery for standby replication |
| Date: | 2006-04-21 04:02:24 |
| Message-ID: | 20060421040224.GM5426@surnet.cl |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Benjamin Krajmalnik wrote:
> The particular table which was problematic (and for which I posted
> another message due to the unique constraint violation which I am
> seeing intermittently) is the one with the high insertion rate. The
> sequence is currently being used to facilitate purginf of old records.
How are you creating the dumps of the sequence and the table? If you do
both separately (as in two pg_dump invocations with a -t switch each),
that could explain your problem. This shouldn't really happen however,
because the sequence dump should be emitted in a dump of the table, if
the field is really of SERIAL or BIGSERIAL type. However I don't see
any other way which would make the sequence go out of sync.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Benjamin Krajmalnik | 2006-04-21 04:10:12 | Re: slow cursor |
| Previous Message | Benjamin Krajmalnik | 2006-04-21 03:52:30 | Re: Howto: Using PITR recovery for standby replication |