[BUGS] BUG #1742: long tables can NOT be updated via "rcv:menu" or sql command line
The following bug has been logged online: Bug reference: 1742 Logged by: Wade Zhang Email address: [EMAIL PROTECTED] PostgreSQL version: on MAS n440aa1 Operating system: SUN solaris Description:long tables can NOT be updated via "rcv:menu" or sql command line Details: Now we encountered a problem that database can not be updated from rcv:menu,spa form or PostgreSQL command line if the table length exceeds a threshold, we are not sure the real value of this threshold. In summary, a short record can be updated correctly, and a long record update always failed with error message "No Tuples Found". I am afraid that there is a lenght limit on PostgreSQL interface. However, the database can be updated correctly via an executable .sql file, with header of "psql -h pglocalhost -U scncraft <100->3 (1) a short table, Discount_Plan_tbl (the number is 30), can be updated correctly. (2) a long table, Counter_Definition_tbl (the number is 16), can NOT be updated, and failed with "No Tuples Found". And you can also try any other tables with length of more than 48 records(three pages display) and less than 32 pages(two pages display). All the short tables can be updated and long tables can NOT. Furthermroe, all these tables can be updated via an executable .sql file. We guest the database interface via "rcv:menu,spa" is not implemented properly. Hope DB team can fix it as soon as possbile since such a problem blocked the whole testing work of the whole project. ---(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 #1743: problem in pg_restore
The following bug has been logged online: Bug reference: 1743 Logged by: karthika Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.2 Operating system: Windows Description:problem in pg_restore Details: When i executed the pg_restore -d sample -U postgres sample.bak pg_restore: connecting to database for restore Password: pg_restore: [archiver (db)] connection to database "sample" failed: FATAL: password authentication failed for user "postgres" pg_restore: *** aborted because of error Kindly mail me the solution to this problem. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] BUG #1735: row number -1 is out of range 0..-1 error
On Thu, Jun 30, 2005 at 06:03:09PM +0300, Bobi Ivanov wrote: > > SELECT > billingplans.id AS plan_id, > billingplans.description as plan_name > FROM (billingplans inner join billingplans_lots > on billingplans.id = billingplans_lots.plan_id) inner join resellerlots > on billingplans_lots.lot_id = resellerlots.lotid > WHERE resellerlots.lot_desc = 45678 and resellerlots.resellerid = 1000 > > and this is what I get: > > row number -1 is out of range 0..-1 > Total query runtime: 40 ms. > Data retrieval runtime: 30 ms. > 0 rows retrieved. > > I checked this through psql and: > > plan_id | plan_name > -+--- > (0 rows) I get the same result (zero rows) in psql; that appears to be correct, given the join conditions and the WHERE clause. Maybe Andreas or somebody else can test the query with pgAdmin. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(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] BUG #1735: row number -1 is out of range 0..-1 error
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Michael Fuhr > Sent: 01 July 2005 14:35 > To: Bobi Ivanov > Cc: Andreas Pflug; pgsql-bugs@postgresql.org > Subject: Re: [BUGS] BUG #1735: row number -1 is out of range > 0..-1 error > > On Thu, Jun 30, 2005 at 06:03:09PM +0300, Bobi Ivanov wrote: > > > > SELECT > > billingplans.id AS plan_id, > > billingplans.description as plan_name > > FROM (billingplans inner join billingplans_lots > > on billingplans.id = billingplans_lots.plan_id) inner join > resellerlots > > on billingplans_lots.lot_id = resellerlots.lotid > > WHERE resellerlots.lot_desc = 45678 and > resellerlots.resellerid = 1000 > > > > and this is what I get: > > > > row number -1 is out of range 0..-1 > > Total query runtime: 40 ms. > > Data retrieval runtime: 30 ms. > > 0 rows retrieved. > > > > I checked this through psql and: > > > > plan_id | plan_name > > -+--- > > (0 rows) > > I get the same result (zero rows) in psql; that appears to be > correct, given the join conditions and the WHERE clause. Maybe > Andreas or somebody else can test the query with pgAdmin. I get 0 rows and no errors with pgAdmin SVN trunk (not that we have changed any of that code recently anyway). Regards, Dave ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] BUG #1744: Directory Missing
The following bug has been logged online: Bug reference: 1744 Logged by: K.G.Sivaraman Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: Solaris Description:Directory Missing Details: Postmaster is successfully running after the install. But after sometimes, I am facing the following problem. Can some one suggests what is the problem ?. ERROR : FATAL: database "CTBLISTDB" does not exist. DETAIL : The database subdirectory "/usr/local/pgsql/data/pg_tblspc/17231/17232" is missing. Note : CTBLISTDB is the table space created in the PostGRESQL, where we create table and store the data. I am starting the Postmaster when the Solaris system is coming up. This problem is not happening always. But once the problem is happened I have to manually clean the database and setup again or the backup to be restore, which is not a correct solution. I am not sure whether this is a bug or not. But I am getting this problem frequently. What is the cause and what is the solution. ---(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 #1741: %i missing in snprintf implementation
Tom Lane wrote: > "Tim Mauch" <[EMAIL PROTECTED]> writes: > > The implementation of snprintf/vsnprintf in src/port/snprintf.c does not > > allow the use of %i ( %d equivalent ). This likely isn't a problem for > > postgres itself, but when a program compiles with -lpq and the standard c > > libraries are not previously included the use of %i in the format string of > > snprintf causes segmentation faults. > > This is easily fixed by adding "case 'i':" to the same block of code handled > > by "case 'd':" and case 'D':" in the implementation. > > We are certainly not going to buy into the assumption that our snprintf > has to support every odd feature that anyone anywhere thinks snprintf > should have :-(. The correct response to this is to figure out how your > program's calls got linked to our snprintf, and stop that from > happening. > > AFAICS, our library should be defining the global symbol pg_snprintf not > snprintf. Can you look into why that's not happening for you? Uh, the pg_snprintf macro fix is not in 8.0.X, only 8.1. The good news, however, is that very few platforms used our snprintf in 8.0 (the ones that don't have 64-bit integer support in snprintf). -- 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 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
[BUGS] BUG #1745: Unable to delete data from the database
The following bug has been logged online: Bug reference: 1745 Logged by: K.G.Sivaraman Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: Solaris Description:Unable to delete data from the database Details: When try to delete the existing name in the database (having ID and Name as the table parameters and both are indexed), it returns success. But when queried again, then the deleted name appeared. When we analysed the problem, the basic delete command itself not working. Normally DELETE command will return the number of records deleted (ex) DELETE 1 for 1 record. But now, it returns DELETE 0, even though the record is there and it is not got deleted. The error in the log file is as follows : ERROR : xlog flush request 0/D17B00 is not satisfied --- flushed only to 0/C31ED0 CONTEXT : writing block 0 of relation 17231/17232/17249 WARNING : could not write block 0 of 17231/17232/17249 DETAIL : Multiple failures --- write error may be permanent. But when I add a new record, it is getting added and I am able to delete the newly added record. Why this error coming ?. Can some one can help ?. ---(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
