From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Decibel! <decibel(at)decibel(dot)org> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_dump restore time and Foreign Keys |
Date: | 2008-06-09 14:57:12 |
Message-ID: | 19362.1213023432@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Decibel! <decibel(at)decibel(dot)org> writes:
> Actually, in the interest of stating the problem and not the
> solution, what we need is a way to add FKs that doesn't lock
> everything up to perform the key checks.
Ah, finally a useful comment. I think it might be possible to do an
"add FK concurrently" type of command that would take exclusive lock
for just long enough to add the triggers, then scan the tables with just
AccessShareLock to see if the existing rows meet the constraint, and
if so finally mark the constraint "valid". Meanwhile the constraint
would be enforced against newly-added rows by the triggers, so nothing
gets missed. You'd still get a small hiccup in system performance
from the transient exclusive lock, but nothing like as bad as it is
now. Would that solve your problem?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-06-09 15:09:14 | Potential deadlock with auto-analyze |
Previous Message | Mark Cave-Ayland | 2008-06-09 14:44:52 | Re: Strange issue with GiST index scan taking far too long |