Boszormenyi Zoltan writes:
> I looked at ruleutils.c and now I am a little confused.
> I mean different functions use different subsystems to
> get their info. E.g.:
Yup.
> Am I missing something?
Yes. That code is hopelessly intertwined with other operations inside
the backend that need to ru
Tom Lane írta:
> Bob Lunney writes:
>
>> I have a job that summarizes some data from a table, truncates the table,
>> drops the indexes, writes the summarized data back into the table, then
>> recreates the indexes. The operations above are not in a single
>> transaction, but separate state
Euler Taveira de Oliveira wrote:
> Tom Lane escreveu:
> > The window for this sort of thing isn't very large, because the first
> > thing pg_dump does is acquire AccessShareLock on every table it intends
> > to dump, and past that point it won't be possible for anyone to modify
> > the table's DDL.
Bob Lunney writes:
> Could pg_dump also take an AccessShared lock on the system tables to prevent
> DDL changes during the dump, thereby preventing this error? Just a thought...
I think that cure would probably be worse than the disease ...
regards, tom lane
--
Sent v
ache lookup failure for index during pg_dump
> To: "Bob Lunney"
> Cc: pgsql-bugs@postgresql.org
> Date: Friday, February 19, 2010, 7:39 PM
> Bob Lunney
> writes:
> > I have a job that summarizes some data from a table,
> truncates the table, drops the indexes, wri
Tom Lane escreveu:
> The window for this sort of thing isn't very large, because the first
> thing pg_dump does is acquire AccessShareLock on every table it intends
> to dump, and past that point it won't be possible for anyone to modify
> the table's DDL. But it can happen.
>
I did not see it do
Bob Lunney writes:
> I have a job that summarizes some data from a table, truncates the table,
> drops the indexes, writes the summarized data back into the table, then
> recreates the indexes. The operations above are not in a single transaction,
> but separate statements executed by a script
