Re: [BUGS] BUG #1733: Function visibility in transactions error
Tom Lane wrote: System catalog lookups generally follow SnapshotNow rules, not MVCC. So the new function definition is visible as soon as it's committed, whether you are in a serializable transaction or not. IMHO this is a bug, or at least not optimal behavior. But per the discussion on -hackers on this topic a few months ago, it seems pretty difficult to fix. -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS] row number -1 is out of range 0..-1
I get this message 'row number -1 is out of range 0..-1' sometimes. I say sometimes, because this happens unexpected when I submit absolutely correct query. Query succeeds, but it returns no resul although there should be.
Re: [BUGS] row number -1 is out of range 0..-1
On Tue, Jun 28, 2005 at 03:11:03PM +0300, Bobi Ivanov wrote: > > I get this message 'row number -1 is out of range 0..-1' sometimes. > I say sometimes, because this happens unexpected when I submit absolutely > correct query. Query succeeds, but it returns no resul although there should > be. The above error happens if a program calls PQgetvalue(), PQgetlength(), or PQgetisnull() with a row number of -1 and if there were no rows in the result. Are you calling those libpq functions directly, or are you using an interface that sits on top of libpq? If the latter, what interface and version are you using? What version of PostgreSQL? What does your code look like? -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] Select on pkey returned more than one row
Dear Gurus, As always, please point me to the right resource if this issue is already addressed. Version: 7.4.6, Debian "Woody" linux. Source: max func args increased to 64, but I doubt it matters. In a pl/pgsql function, called from an AFTER trigger, I receive this message: ERROR: query "SELECT mennyiseg FROM muvelet_cikk WHERE muvelet= $1 AND cikk= $2 AND minoseg= $3 AND mozgasnem= $4 " returned more than one row Whereas the fields in the WHERE clause are exactly the pkey fields for that table: "muvelet_cikk_pkey" primary key, btree (muvelet, cikk, minoseg, mozgasnem) I'm not sure but this may be because of a race condition (one backend frequently inserting rows while another backend firing a trigger that causes a mass UPDATE on the same tuples. Indeed, we tend to receive deadlocks.) Are pkey constraints immediate or deferred? May it be the cause of the problem? If so, what are the risks of changing the constraint to immediate, if it can be done at all? The table definition in question is as follows. Double-checked, and indeed, no rows violate the pkey (and I assume no rows violate it in the transaction that throws the error, either -- but indeed, rows are updated or inserted into this table from both abovementioned backends) I'm able to send more information if needed. TIA, -- G. [local]:tir=# \d muvelet_cikk Table "public.muvelet_cikk" Column | Type | Modifiers ---+---+ muvelet | integer | not null cikk | integer | not null mozgasnem | integer | not null mennyiseg | numeric(14,4) | me| integer | kcikk | integer | minoseg | integer | not null default 1 Indexes: "muvelet_cikk_pkey" primary key, btree (muvelet, cikk, minoseg, mozgasnem) "muvelet_cikk_cikk_muvelet" btree (cikk, muvelet) "muvelet_cikk_mozgasnem_cikk" btree (mozgasnem, cikk) "muvelet_cikk_mozgasnem_muvelet" btree (mozgasnem, muvelet) Check constraints: "mennyiseg_me" CHECK ((mennyiseg IS NULL) = (me IS NULL)) Foreign-key constraints: "$2" FOREIGN KEY (cikk) REFERENCES cikk(az) ON UPDATE CASCADE "$6" FOREIGN KEY (kcikk) REFERENCES kulso_cikk(az) "$5" FOREIGN KEY (minoseg) REFERENCES minoseg(az) "$1" FOREIGN KEY (muvelet) REFERENCES muvelet(az) ON UPDATE CASCADE ON DELETE CASCADE "$4" FOREIGN KEY (me) REFERENCES mennyisegi_egyseg(az) "$3" FOREIGN KEY (mozgasnem) REFERENCES mozgasnem(az) Triggers: muvelet_cikk_ad AFTER DELETE ON muvelet_cikk FOR EACH ROW EXECUTE PROCEDURE muvelet_cikk_ad() muvelet_cikk_aiud AFTER INSERT OR DELETE OR UPDATE ON muvelet_cikk FOR EACH ROW EXECUTE PROCEDURE muvelet_cikk_aiud() muvelet_cikk_biu BEFORE INSERT OR UPDATE ON muvelet_cikk FOR EACH ROW EXECUTE PROCEDURE muvelet_cikk_biu() muvelet_cikk_noty AFTER INSERT OR DELETE OR UPDATE ON muvelet_cikk FOR EACH ROW EXECUTE PROCEDURE muvelet_cikk_noty() ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] row number -1 is out of range 0..-1
Thank you for your quick responce! I don't call them directly. I use pgsql 8.0.3 under Fedora Core and I'm writing queries through pgAdminIII. This is the query that produces it: select billingplans_freetalktime.id, billingplans_freetalktime.seconds, billingplans_freetalktime.accumulate, billingplans_freetalktime.period from (billingplans_freetalktime inner join tariffs on billingplans_freetalktime.tariff_id = tariffs.id_tariff) where billingplans_freetalktime.plan_id = 5 and '3597' like tariffs.prefix||'%' order by length(tariffs.prefix) desc; and I get this: row number -1 is out of range 0..-1 Total query runtime: 40 ms. Data retrieval runtime: 60 ms. 0 rows retrieved. I'll be glad if you can tell me how can I fix it. Do you know patch or something? -Bobi Ivanov - Original Message - From: "Michael Fuhr" <[EMAIL PROTECTED]> To: "Bobi Ivanov" <[EMAIL PROTECTED]> Cc: Sent: Tuesday, June 28, 2005 3:58 PM Subject: Re: [BUGS] row number -1 is out of range 0..-1 On Tue, Jun 28, 2005 at 03:11:03PM +0300, Bobi Ivanov wrote: I get this message 'row number -1 is out of range 0..-1' sometimes. I say sometimes, because this happens unexpected when I submit absolutely correct query. Query succeeds, but it returns no resul although there should be. The above error happens if a program calls PQgetvalue(), PQgetlength(), or PQgetisnull() with a row number of -1 and if there were no rows in the result. Are you calling those libpq functions directly, or are you using an interface that sits on top of libpq? If the latter, what interface and version are you using? What version of PostgreSQL? What does your code look like? -- Michael Fuhr http://www.fuhr.org/~mfuhr/ __ NOD32 1.1155 (20050626) Information __ This message was checked by NOD32 antivirus system. http://www.nod32.com ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] row number -1 is out of range 0..-1
On Tue, Jun 28, 2005 at 04:07:33PM +0300, Bobi Ivanov wrote: > > Thank you for your quick responce! I don't call them directly. I use pgsql > 8.0.3 under Fedora Core and I'm writing queries through pgAdminIII. How consistently do you get the error? What happens if you run the query in psql? -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #1735: row number -1 is out of range 0..-1 error
The following bug has been logged online: Bug reference: 1735 Logged by: Borislav Ivanov Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: Fedora Core Description:row number -1 is out of range 0..-1 error Details: I get this message 'row number -1 is out of range 0..-1' sometimes. I say sometimes, because this happens unexpected when I submit absolutely correct query. This is the last time it happened: I have two tables: CREATE TABLE billingplans_freetalktime ( plan_id int4 NOT NULL, tariff_id int4 NOT NULL, seconds int4 NOT NULL, accumulate int2 NOT NULL, period interval NOT NULL, description varchar(255), id serial NOT NULL ) WITHOUT OIDS; ALTER TABLE billingplans_freetalktime OWNER TO ser; CREATE TABLE tariffs ( id_tariffs_key serial NOT NULL, id_tariff int4 NOT NULL, prefix char(20) NOT NULL, description char(30) NOT NULL, voice_rate numeric(8,4) NOT NULL, from_day int2 NOT NULL, to_day int2 NOT NULL, from_hour int2, to_hour int2 NOT NULL, CONSTRAINT pk_tariffs PRIMARY KEY (id_tariffs_key), CONSTRAINT fk_tariffs_id_tariff FOREIGN KEY (id_tariff) REFERENCES tariffsnames (id_tariff) MATCH SIMPLE ON UPDATE CASCADE ON DELETE CASCADE ) WITHOUT OIDS; ALTER TABLE tariffs OWNER TO ser; and when i submit this query: select billingplans_freetalktime.id, billingplans_freetalktime.seconds, billingplans_freetalktime.accumulate, billingplans_freetalktime.period from (billingplans_freetalktime inner join tariffs on billingplans_freetalktime.tariff_id = tariffs.id_tariff) where billingplans_freetalktime.plan_id = 5 and '3597' like tariffs.prefix||'%' order by length(tariffs.prefix) desc; it returns: row number -1 is out of range 0..-1 Total query runtime: 151 ms. Data retrieval runtime: 80 ms. 0 rows retrieved. although there are these rows in each table: insert into billingplans_freetalktime values (5,41,12,0,'7 days','za proba',3) insert into tariffs values (1, 41, '359', 'descr', 12.3, 0, 6, 0, 23) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #1734: Can't install in D:\
The following bug has been logged online: Bug reference: 1734 Logged by: Paolo Petranzan Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: Windows 2000 Workstation SP4 Description:Can't install in D:\ Details: I'm trying to install PostgreSQL 8.0 in D:/Programmi/PostgreSQL, but I get this error from initdb: creating directory D:/Programmi/PostgreSQL/8.0/data/global ... initdb: could not create directory "D:/Programmi/PostgreSQL": File exists of course "file exists": installer just created it! ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] BUG #1733: Function visibility in transactions error
Tom Lane wrote: "Robert Grabowski" <[EMAIL PROTECTED]> writes: I have problem with function visibility in transaction when I do create and drop function. System catalog lookups generally follow SnapshotNow rules, not MVCC. So the new function definition is visible as soon as it's committed, whether you are in a serializable transaction or not. regards, tom lane Hi! OK. I can understand that. But why at first call after update function have I results of the old function, and at second call in the same transaction I have results of the new function. It is strange for me. pozdrawiam Robert Grabowski ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #1734: Can't install in D:\
Please see the FAQ and the archives of the mailing lists. This has come up before. It's permissions issues on your D: drive or subdirectories. //Magnus > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Paolo Petranzan > Sent: Tuesday, June 28, 2005 1:35 PM > To: pgsql-bugs@postgresql.org > Subject: [BUGS] BUG #1734: Can't install in D:\ > > > The following bug has been logged online: > > Bug reference: 1734 > Logged by: Paolo Petranzan > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0.3 > Operating system: Windows 2000 Workstation SP4 > Description:Can't install in D:\ > Details: > > I'm trying to install PostgreSQL 8.0 in > D:/Programmi/PostgreSQL, but I get this error from initdb: > > creating directory D:/Programmi/PostgreSQL/8.0/data/global > ... initdb: could not create directory > "D:/Programmi/PostgreSQL": File exists > > of course "file exists": installer just created it! > > ---(end of > broadcast)--- > TIP 7: don't forget to increase your free space map settings > ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] row number -1 is out of range 0..-1
"Bobi Ivanov" <[EMAIL PROTECTED]> writes: > Thank you for your quick responce! I don't call them directly. I use pgsql > 8.0.3 under > Fedora Core and I'm writing queries through pgAdminIII. I would say then that this is a pgAdmin bug, and should be reported on the pgAdmin mailing lists --- I'm not sure that any of the pgAdmin hackers read this list. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #1735: row number -1 is out of range 0..-1 error
"3";"12";"0";"7 days is the result I'm getting in pgadmin. Regards, Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] row number -1 is out of range 0..-1
Tom Lane wrote: "Bobi Ivanov" <[EMAIL PROTECTED]> writes: Thank you for your quick responce! I don't call them directly. I use pgsql 8.0.3 under Fedora Core and I'm writing queries through pgAdminIII. I would say then that this is a pgAdmin bug, and should be reported on the pgAdmin mailing lists --- I'm not sure that any of the pgAdmin hackers read this list. I do read the list, though I missed it initially. I doubt it's a pgadmin bug, but let's see the query first. Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] BUG #1736: endless loop in PQconnectdb
The following bug has been logged online:
Bug reference: 1736
Logged by: Karsten Desler
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.7
Operating system: debian sarge
Description:endless loop in PQconnectdb
Details:
I've got a pretty flaky tcpip connection to a Postgres 7.4.7 database server
and often times (once or twice a day) my program gets stuck in an endless
busy-loop in PGconnectdb.
An excerpt from a strace:
poll([{fd=389, events=POLLIN|POLLERR, revents=POLLIN|POLLERR|POLLHUP}], 1,
-1) = 1
recv(389, "", 1, 0) = 0
poll([{fd=389, events=POLLIN|POLLERR, revents=POLLIN|POLLERR|POLLHUP}], 1,
-1) = 1
recv(389, "", 1, 0) = 0
...
SSL is not involved. Sadly I can't say how far along in the connection
process the bug is triggered, but I could install a libpq3 with debugging
symbols and add a few strategically placed gdb watch/break points, if
needed.
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [BUGS] BUG #1736: endless loop in PQconnectdb
"Karsten Desler" <[EMAIL PROTECTED]> writes: > I've got a pretty flaky tcpip connection to a Postgres 7.4.7 database server > and often times (once or twice a day) my program gets stuck in an endless > busy-loop in PGconnectdb. Hmm. Maybe you have a test case for the proposed patch for bug #1467? Please see the patch posted in pgsql-patches a couple days ago, and let us know if it helps. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #1736: endless loop in PQconnectdb
Yes, please --- the patch is at: http://archives.postgresql.org/pgsql-patches/2005-06/msg00486.php --- Tom Lane wrote: > "Karsten Desler" <[EMAIL PROTECTED]> writes: > > I've got a pretty flaky tcpip connection to a Postgres 7.4.7 database server > > and often times (once or twice a day) my program gets stuck in an endless > > busy-loop in PGconnectdb. > > Hmm. Maybe you have a test case for the proposed patch for bug #1467? > Please see the patch posted in pgsql-patches a couple days ago, and let > us know if it helps. > > regards, tom lane > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to [EMAIL PROTECTED] so that your >message can get through to the mailing list cleanly > -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
