Re: pg_restore and FK constraints with large dbs

Поиск
Список
Период
Сортировка
От Stephan Szabo
Тема Re: pg_restore and FK constraints with large dbs
Дата
Msg-id 20031117154448.B9405@megazone.bigpanda.com
обсуждение исходный текст
Ответ на Re: pg_restore and FK constraints with large dbs  (ow <oneway_111@yahoo.com>)
Ответы Re: pg_restore and FK constraints with large dbs  (ow <oneway_111@yahoo.com>)
Список pgsql-admin
On Mon, 17 Nov 2003, ow wrote:

> --- Stephan Szabo <sszabo@megazone.bigpanda.com> wrote:
> > Well, I've been trying to deal with the particular case at hand, ie, get
> > your load in a more reasonable amount of time assuming that you had more
> > constraints and this was going to be a particular problem for you in the
> > immediate term.  I've mentioned that there's likely to be future
> > development on the issue in this thread already and that there was a
> > recent discussion on the topic that occurred a bit late to do anything for
> > 7.4.  I can't change the past to suit your desires, sorry, the best I can
> > do is point you towards getting a solution for the future.
> >
>
> Thanks, you've been very helpful and I appreciate the effort.
>
> In case if there's no immediate solution, the solution could be something like
> "yes, we understand the importance of the raised issue and we intent to
> implement a fix for it in 7.5/8.0/or whatever".

Like I said, it's been discussed and I would expect some form of this for
7.5 although I can't say for certain.  Enough people were interested in
the discussion that it's likely to happen with a little championing.

> Personally, I see the fix as the ability for the superuser to issue "SET
> suspend_fk_checks(or whatever)=true/false" on the respective connection and
> perhaps the respective pg_restore option.

That was one of the options mentioned in the thread I talked about before.
There's still some question about whether it'd affect all checks or just
ones from things like alter table.

> Anything I can do to make this happen? (am not a C-developer but perhaps could
> help with testing).

Well, generally looking through the archives and making a reasonable
proposal on -general or -hackers is a good start.  The code for this is
unlikely to be difficult, but there's alot of behavior to decide. Things
to think about are things like what checks do we want to disable, who can
do so and what're the mechanisms for doing so, for example, alter time
checks disabled by superusers via a set option.  And then thinking about
the limitations.

В списке pgsql-admin по дате отправления:

Предыдущее
От: ow
Дата:
Сообщение: Re: pg_restore and FK constraints with large dbs
Следующее
От: ow
Дата:
Сообщение: Re: pg_restore and FK constraints with large dbs