Re: AW: Proposal: More flexible backup/restore via pg_dump

From: Giles Lean <giles(at)nemeton(dot)com(dot)au>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: Proposal: More flexible backup/restore via pg_dump
Date: 2000-06-27 22:48:52
Message-ID: 5054.962146132@nemeton.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> I don't suppose anyone knows of a way of telling if a file handle supports
> seek?

The traditional method is to call lseek() and see what happens.

> Part of the motivation for this utility was to allow DBAs to fix the
> ordering at restore time, but otherwise I totally agree. Unfortunately I
> don't think the RI checks can be delayed at this stage - can they?

The current pg_dump handles the data and then adds the constraints.

Otherwise there are "chicken and egg" problems where two tables have
mutual RI constraints. Even at the tuple level two tuples can be
mutually dependent.

Regards,

Giles

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2000-06-27 23:16:27 Re: Big 7.1 open items
Previous Message Tom Lane 2000-06-27 21:49:04 Re: Please help cache lookup failed