Re: Potential bug in pg_dump ...
От
Philip Warner
Тема
Re: Potential bug in pg_dump ...
Дата
Msg-id
3.0.5.32.20011218090125.033c6160@mail.rhyme.com.au
Ответ на
Re: Potential bug in pg_dump ... (Philip Warner)
Список
Дерево обсуждения
Potential bug in pg_dump ... "Marc G. Fournier" <scrappy@hub.org>
Re: Potential bug in pg_dump ... Philip Warner <pjw@rhyme.com.au>
Re: Potential bug in pg_dump ... Philip Warner <pjw@rhyme.com.au>
Re: Potential bug in pg_dump ... Tom Lane <tgl@sss.pgh.pa.us>
Re: Potential bug in pg_dump ... Brent Verner <brent@rcfile.org>
Re: Potential bug in pg_dump ... Tom Lane <tgl@sss.pgh.pa.us>
Re: Potential bug in pg_dump ... Brent Verner <brent@rcfile.org>
Re: Potential bug in pg_dump ... Brent Verner <brent@rcfile.org>
Re: Potential bug in pg_dump ... Tom Lane <tgl@sss.pgh.pa.us>
Re: Potential bug in pg_dump ... Brent Verner <brent@rcfile.org>
At 08:25 18/12/01 +1100, Philip Warner wrote: >At 14:10 17/12/01 -0500, Marc G. Fournier wrote: >> >>Got a report the other day of a "problem" with pg_dump where, if in the >>middle of a dump, someone happens to drop a table, it errors out with: >> > >pg_dump runs in a single TX, which should mean that metadata changes in >another process won't affect it. Have I misunderstood the way PG handles >metadata changes? > Maybe I'm expectibg too much from the locking, since pg_dump is only reading pg_class to get a list of tables. Perhaps it should do one of the following: a) Issue a LOCK TABLE for each table (seems like a bad idea) b) Reconfirm the existance of the table before trying to dump it. c) Ignore the problem I favour either (b) or (c). Anyone have comments or other suggestions? ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
В списке pgsql-hackers по дате отправления