Re: [HACKERS] pg_dump and dependencies and --section ... it's a mess

I wrote: > Barring objections or better ideas, I'll push forward with applying > this patch and the dependency-fixup patch. Applied and back-patched. BTW, I had complained at the end of the pgsql-bugs thread about bug #6699 that it seemed like FK constraints would get prevented from being restore

Re: [HACKERS] pg_dump and dependencies and --section ... it's a mess

Andrew Dunstan writes: > On 06/22/2012 04:43 PM, Tom Lane wrote: >> A possible objection to it is that there are now three different ways in >> which the pg_dump code knows which DO_XXX object types go in which dump >> section: the new addBoundaryDependencies() function knows this, the >> SECTION_

Re: [HACKERS] pg_dump and dependencies and --section ... it's a mess

On 06/22/2012 04:43 PM, Tom Lane wrote: Anyway, the attached patch does seem to fix the constraint bug. Looks sane to me. A possible objection to it is that there are now three different ways in which the pg_dump code knows which DO_XXX object types go in which dump section: the new addB

Re: [HACKERS] pg_dump and dependencies and --section ... it's a mess

I wrote: > I believe the right fix for both of these issues is to add knowledge of > the section concept to the topological sort logic, so that an ordering > that puts POST_DATA before DATA or PRE_DATA after DATA is considered to > be a dependency-ordering violation. One way to do that is to add d

Re: [HACKERS] pg_dump and dependencies and --section ... it's a mess

Andrew Dunstan writes: > On 06/21/2012 07:43 PM, Tom Lane wrote: >> I didn't understand that then, and I still don't. > If something else holds a lock on the table (e.g. another CREATE INDEX) > the ALTER TABLE will block until it's done, waiting for an ACCESS > EXCLUSIVE lock. The whole method

Re: [HACKERS] pg_dump and dependencies and --section ... it's a mess

On 06/21/2012 07:43 PM, Tom Lane wrote: Andrew Dunstan writes: On 06/21/2012 06:25 PM, Tom Lane wrote: Hm, I guess I've forgotten that one? See I didn't understand that then, and I still don't. The ALTER TABLE CLUSTER migh

Re: [HACKERS] pg_dump and dependencies and --section ... it's a mess

Andrew Dunstan writes: > On 06/21/2012 06:25 PM, Tom Lane wrote: >> Hm, I guess I've forgotten that one? > See I didn't understand that then, and I still don't. The ALTER TABLE CLUSTER might need exclusive lock, but it's not go

Re: [HACKERS] pg_dump and dependencies and --section ... it's a mess

On 06/21/2012 06:25 PM, Tom Lane wrote: Andrew Dunstan writes: (There's another bug to do with parallel pg_restore and clustering that Andrew Hammond raised back in January, that I want to fix when I get some time.) Hm, I guess I've forgotten that one? See

Re: [HACKERS] pg_dump and dependencies and --section ... it's a mess

Andrew Dunstan writes: > If I'm understanding you correctly, fixing the bogus dependency thing is > more an insurance policy than fixing a case (other than the constraint > dependency) that is known to be broken. Right. That's the only *known* broken case, and it does seem like we'd have heard

Re: [HACKERS] pg_dump and dependencies and --section ... it's a mess

On 06/21/2012 02:13 PM, Tom Lane wrote: Don't know if everybody on this list has been paying attention to the pgsql-bugs thread about bug #6699. The shortest example of the problem is create table t1 (f1 int primary key, f2 text); create view v1 as select f1, f2 from t1 group by f1; The view

[HACKERS] pg_dump and dependencies and --section ... it's a mess

Don't know if everybody on this list has been paying attention to the pgsql-bugs thread about bug #6699. The shortest example of the problem is create table t1 (f1 int primary key, f2 text); create view v1 as select f1, f2 from t1 group by f1; The view's query is legal only because of the primar