[BUGS] BUG #3590: Error while in Plpgsql :
The following bug has been logged online: Bug reference: 3590 Logged by: Abdus Samad Ansari Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.2. Operating system: Fedora 2 Linux Description:Error while in Plpgsql : Details: I am using a plpgsql function and in this I am issuing a insert as : Insert into pis.hrt_emp_leave_bin (emp_no,leave_cd,curr_dt,bin_sl_no,cal_yr,tran_typ,open_bal,ytd_availed,avai led) values (EmployeeNumber, LeaveCode, CurrentDate, Bin_Serial_No,to_number(to_char(CurrentDate,''''),''''),''CM'', OpenBal,YtdAvailed+LeaveVal,LeaveVal); This insert statement while run give an error message : ERROR: syntax error at or near "$1" at character 35 The problem is with the column named "availed", while I renamed the column availed as "availd", the same statement works fine. I could not understand this, whether the word availed is a reserve word for plpgsql? or something else? Thanks in advance. Abdus Samad Ansari ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] to_date gives odd results
> On Thursday 30 August 2007 21:15, Tom Lane wrote: > > to_date and friends are fairly awful in terms of not throwing errors > > when the input doesn't really match the format. I think what you > > shoulda got here is a bad-input error. However, somebody's going to > > have to do a major rewrite of formatting.c to make it much better... Any votes for making that formatting.c rewrite a TODO item? -eggyknap ---(end of broadcast)--- TIP 1: 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] to_date gives odd results
Josh Tolley escribió: > > On Thursday 30 August 2007 21:15, Tom Lane wrote: > > > to_date and friends are fairly awful in terms of not throwing errors > > > when the input doesn't really match the format. I think what you > > > shoulda got here is a bad-input error. However, somebody's going to > > > have to do a major rewrite of formatting.c to make it much better... > > Any votes for making that formatting.c rewrite a TODO item? Well, there is already a to_char patch scheduled for 8.4. If you want to improve the to_date code, you are invited to do so -- no need to have a TODO item about it. If what you expect is that having a TODO item will mean that somebody else will start working on it, I think you'll be disappointed :-) (OTOH maybe we should add it and put the % mark in it.) -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 1: 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] to_date gives odd results
On 8/31/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > Josh Tolley escribió: > > > On Thursday 30 August 2007 21:15, Tom Lane wrote: > > > > to_date and friends are fairly awful in terms of not throwing errors > > > > when the input doesn't really match the format. I think what you > > > > shoulda got here is a bad-input error. However, somebody's going to > > > > have to do a major rewrite of formatting.c to make it much better... > > > > Any votes for making that formatting.c rewrite a TODO item? > > Well, there is already a to_char patch scheduled for 8.4. If you want > to improve the to_date code, you are invited to do so -- no need to have > a TODO item about it. I figured as much. > If what you expect is that having a TODO item will mean that somebody > else will start working on it, I think you'll be disappointed :-) I realize this chance is slim. The likelihood that I could get to it and make something useful of it seemed even more slim :) > (OTOH maybe we should add it and put the % mark in it.) - Josh ---(end of broadcast)--- TIP 1: 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 #3590: Error while in Plpgsql :
"Abdus Samad Ansari" <[EMAIL PROTECTED]> writes: > I am using a plpgsql function and in this I am issuing a insert as : > Insert into pis.hrt_emp_leave_bin > (emp_no,leave_cd,curr_dt,bin_sl_no,cal_yr,tran_typ,open_bal,ytd_availed,avai > led) values (EmployeeNumber, LeaveCode, CurrentDate, > Bin_Serial_No,to_number(to_char(CurrentDate,''''),''''),''CM'', > OpenBal,YtdAvailed+LeaveVal,LeaveVal); > This insert statement while run give an error message : > ERROR: syntax error at or near "$1" at character 35 This probably means that one of the field names in the statement (if I counted characters right, probably "emp_no") is the same as the name of one of the plpgsql variables in the function. You need to change the variables to not conflict with any of the table or field names you need to reference in the queries of that function, because plpgsql is not very bright about telling when it should substitute and when it should not. 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
[BUGS] BUG #3591: autovacuum crash
The following bug has been logged online: Bug reference: 3591 Logged by: Ben Kim Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.0 Operating system: Solaris 8 Description:autovacuum crash Details: The server crashed suddenly the second time since two days ago. ulimit is unlimited, but I see no core file under the postgresql root directory. = 6780 2007-08-31 14:01:46 CDT LOG: autovacuum process (PID 6379) was terminated by signal 11 6780 2007-08-31 14:01:46 CDT LOG: terminating any other active server processes user db1 [local] 6375 2007-08-31 14:01:46 CDT idle 0 WARNING: terminating connection because of crash of another server process user db1 [local] 6375 2007-08-31 14:01:46 CDT idle 0 DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. user db1 [local] 6375 2007-08-31 14:01:46 CDT idle 0 HINT: In a moment you should be able to reconnect to the database and repeat your command. (repeated for every database) ... 6780 2007-08-31 14:01:47 CDT LOG: all server processes terminated; reinitializing 6381 2007-08-31 14:01:47 CDT LOG: database system was interrupted at 2007-08-31 14:01:35 CDT 6381 2007-08-31 14:01:47 CDT LOG: checkpoint record is at F/5A51F588 6381 2007-08-31 14:01:47 CDT LOG: redo record is at F/5A51F588; undo record is at 0/0; shutdown FALSE 6381 2007-08-31 14:01:47 CDT LOG: next transaction ID: 140043601; next OID: 25139832 6381 2007-08-31 14:01:47 CDT LOG: next MultiXactId: 411; next MultiXactOffset: 897 6381 2007-08-31 14:01:47 CDT LOG: database system was not properly shut down; automatic recovery in progress 6381 2007-08-31 14:01:47 CDT LOG: redo starts at F/5A51F5D0 6381 2007-08-31 14:01:47 CDT LOG: record with zero length at F/5A525C18 6381 2007-08-31 14:01:47 CDT LOG: redo done at F/5A525BE8 6381 2007-08-31 14:01:47 CDT LOG: database system is ready 6381 2007-08-31 14:01:47 CDT LOG: transaction ID wrap limit is 1206535619, limited by database db3 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #3591: autovacuum crash
Ben Kim wrote: > > The following bug has been logged online: > > Bug reference: 3591 > Logged by: Ben Kim > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.0 > Operating system: Solaris 8 > Description:autovacuum crash > Details: > > The server crashed suddenly the second time since two days ago. ulimit is > unlimited, but I see no core file under the postgresql root directory. > = > >6780 2007-08-31 14:01:46 CDT LOG: autovacuum process (PID 6379) was >terminated by signal 11 This is a crash all right, but I think we fixed a certain number of bugs after 8.1.0 was released. Please install 8.1.9, and if it still crashes, report again. (We'll be wanting to see stack traces at that point, so please make sure you are using a debug-enabled build, and a non-zero coresize ulimit setting). FWIW the core files should be stored in the data directories (PGDATA). -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3591: autovacuum crash
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Ben Kim wrote: >> PostgreSQL version: 8.1.0 >> The server crashed suddenly the second time since two days ago. ulimit is >> unlimited, but I see no core file under the postgresql root directory. > This is a crash all right, but I think we fixed a certain number of bugs > after 8.1.0 was released. Indeed. > FWIW the core files should be stored in the data directories (PGDATA). It seems likely that ulimit -c may be limited for the postmaster even if it is not in your interactive shell --- very many systems run init scripts with ulimit -c 0. I'd suggest putting "ulimit -c unlimited" right in the script that launches the postmaster. regards, tom lane ---(end of broadcast)--- TIP 1: 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
