The following bug has been logged on the website:
Bug reference: 7803
Logged by: Tomonari Katsumata
Email address: katsumata.tomon...@po.ntts.co.jp
PostgreSQL version: 9.2.2
Operating system: RHEL 5.3 x86_64
Description:
hi, I'm playing with Synchronous Replication on
=?utf-8?Q?Christiaan_Willemsen?= writes:
> Thanks for the answer. I will try to fix the problem via the catalog. As for
> how I did this.. I hope I can give you a full walkthough:
This isn't nearly detailed enough to give me any hope of reproducing the
problem. Any chance you can dredge up the
=?utf-8?Q?Christiaan_Willemsen?= writes:
> Back again ;) I just checked pg_depend, and according to it there is no
> relation between in de table and the sequence... There is however a relation
> between the new table and the old sequence (as expected). So this is sill a
> mistery.
Hm, I might
Hi Tom,
Back again ;) I just checked pg_depend, and according to it there is no
relation between in de table and the sequence... There is however a relation
between the new table and the old sequence (as expected). So this is sill a
mistery.
By the way, I can't to a dump restore, it woul
Hi Tom,
Thanks for the answer. I will try to fix the problem via the catalog. As for
how I did this.. I hope I can give you a full walkthough:
- We've had a paritioned table with 1 primary key, and two foreign keys (one of
them has in index). There were about three partions (all made via a
cwillem...@technocon.com writes:
> I have a table that currently looks like this:
> CREATE TABLE old_table
> (
> id bigint DEFAULT 0
> )
> Thats's it..
> So, now when I drop the table is sais:
> ERROR: cannot drop table old_table because other objects depend on it
> DETAIL: default for tab
The following bug has been logged on the website:
Bug reference: 7802
Logged by: Christiaan Willemsen
Email address: cwillem...@technocon.com
PostgreSQL version: 9.1.7
Operating system: CentOS 6.2
Description:
I have a table that currently looks like this:
CREATE TAB
