[BUGS] insert statement going into infinite loop
Hi everybody.. I have table with 11 attributes, 6 of them refers different tables and having one primary key. when I am trying to insert row with 121 key value, its going into infinite loop.. I didnt find any error in table definition and no foreign key violations.. Can you please help me in this issue.. I am thinking its a bug in postgres.. Can you make clear in this issue.. thank you.. -- with best --Trim.. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] insert statement going into infinite loop
On Fri, Dec 24, 2010 at 6:57 AM, Trimurthulu Bandaru wrote: > Hi everybody.. > I have table with 11 attributes, 6 of them refers different tables and > having one primary key. > when I am trying to insert row with 121 key value, its going into > infinite loop.. define "infinite loop", the truth is that you're giving almost no information so all we can try now is to guess and cross fingers ;) are you describing that the INSERT never finishes? if so, maybe the table is locked... you can know that by looking in pg_stat_activity view and find your statement in the field current_query and see the field waiting, if is true then the statement is locked waiting for something... or you can see the pg_locks view where relation = 'your_table'::regclass another posibility is that you have a trigger in the table after or before insert and then inside the trigger inserting a new value on the same table forcing a new execution of the trigger making it recursive... > I am thinking its a bug in postgres.. it's too early to blame postgres -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] insert statement going into infinite loop
On 12/24/2010 10:57 PM, Trimurthulu Bandaru wrote: Hi everybody.. I have table with 11 attributes, 6 of them refers different tables and having one primary key. when I am trying to insert row with 121 key value, its going into infinite loop.. Do you have any triggers on the table? Can you produce a single .sql file that creates the tables and does the problem insert? -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] memory leaks? using savepoint
On Tue, Dec 21, 2010 at 11:09 PM, Tom Lane wrote: > So if we take the complaint seriously, we'd better patch 8.2 as well. I'm sort of inclined to think we should take the complaint seriously. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5781: unaccent() function should be marked IMMUTABLE
On Wed, Dec 22, 2010 at 8:45 PM, Bruce Momjian wrote: > Tom Lane wrote: >> "Grant Hutchins and Peter Jaros" writes: >> > The unaccent(text) function supplied by contrib/unaccent is marked >> > VOLATILE. >> > This prevents it from being used in indexes. We believe that the function >> > meets the requirements to be marked IMMUTABLE. >> >> No, it most certainly doesn't. It depends on the behavior of a >> dictionary that it has no hard-wired connection to, so the specific >> behavior of the dictionary is uncertain. Even if you're willing to >> assume that the dictionary being used is the one defined by this >> module, that dictionary depends on external configuration files >> which are easily changeable. >> >> Arguably it'd be reasonable to change the function's marking from >> volatile to stable, but that's not going to be enough to allow use in >> indexes. > > So, should we change unaccent() from VOLATILE to STABLE? Sounds like it, but it doesn't sound like it will help much. :-( -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
