Pike-devel June 2011

pike-devel@lists.lysator.liu.se

2 participants
6 discussions

Sql.pgsql behavior in case of errors
by aldem-pikedev＠aldem.net 21 Aug '14

21 Aug '14

Hi everyone, I am preparing to use Postgres in my app, found the following strange behavior: ---snip--- Sql.Sql db = Sql.Sql("pgsql://localhost", "test", "test", "test"); db->query("BEGIN"); db->query("INSERT INTO requests (SvTrId) VALUES ('lala')"); catch(db->query("INSERT INTO requests (SvTrId) VALUES ('lala')")); db->query("INSERT INTO requests (SvTrId) VALUES ('juju')"); db->query("ROLLBACK"); ---snip--- Database is opened, row with 'lala' is inserted, second query (obviously) fails as SvTrId is the primary key, but row with 'juju' is inserted *and* appears in the database - i.e. the transaction is *committed*! Studying source code show, that once error is encounter, session is reset, i.e. running transaction is rolled back, everything is closed, temporary tables are deleted and session variables are reset as well, and after that, the next statement(s) will be committed immediately, as there is no active transaction. In my opinion, this is not exactly correct behavior when statement fails, as session still may be needed (especially temporary tables, open cursors etc). Im some cases, this is perfectly normal when SQL statement fails, especially in SERIALIZED transaction isolation level, and it would be more practical to leave the decision as of what to do to the application. Yes, this is true that it is impossible to continue executing statements in failed transaction, but temporary tables etc. may still be needed. Also, silent reconnection is not a good idea too - when there are many transactional statements are executed - it would be nice to have an option to modify this behavior. Best regards, /Alexander

5 6

pike.ida.liu.se offline?
by Ryan 18 Nov '11

18 Nov '11

I am unable to get to the pike homepage to download the latest bits and read the documents. Anyone have any information?

5 11

Re: Calendar.Month / Calendar.Hour
by Marc Dirix 23 Aug '11

23 Aug '11

On 04/12/2011 11:05 AM, Mirar @ Pike developers forum wrote: > That's an old bug that I thought would be fixed by now. Pike optimizes > the + call and calls `+ with more than one argument. The Calendar > module ignores all other arguments than the first. > > (I think it's that one anyway.) Ok, then I have to wait for the new debian package (still on 7.8.352)

8 12

7.8 segfault
by Bill Welliver 28 Jun '11

28 Jun '11

I've migrated a fairly complex application that was running fine under Pike 7.6 and am getting a number of different situations that cause segfaults. I'm not able to completely rule out the possibility that there's a non-core pike c-module that may be to blame, but the module code has been running well and without any problems of this sort for a number of years. The GDB backtraces look like this: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -145934672 (LWP 2582)] 0x081276e5 in low_object_index_no_free (to=0xffaaad58, o=0x88bfa78, f=67) at /root/Pike-v7.8.352/src/object.c:1252 1252 add_ref(to->u.dummy=dummy); (gdb) bt #0 0x081276e5 in low_object_index_no_free (to=0xffaaad58, o=0x88bfa78, f=67) at /root/Pike-v7.8.352/src/object.c:1252 #1 0x08133599 in index_no_free (to=0xffaaad58, what=0xf720f260, ind=0xffaaad60) at /root/Pike-v7.8.352/src/operators.c:87 #2 0x08076d57 in opcode_F_STRING_INDEX (arg1=702) at /home/zino/hack-local/Pike/7.8-distmaker/src/interpret_functions.h:1854 #3 0xf61c8a04 in ?? () #4 0x000002be in ?? () #5 0xf7610160 in __after_morecore_hook () from /lib/libc.so.6 #6 0xffaaad88 in ?? () #7 0x08a03870 in ?? () #8 0x00000000 in ?? () Any suggestions? This is 7.8.352 on an intel atom (64-bit debian). Best, Bill

2 1

Re: possible sscanf misfeatures
by Mirar ＠ Pike developers forum 22 Jun '11

22 Jun '11

> sprintf("%+2c",17); (26) Result: "+\0\21" Can't ever be what you want...

1 0

possible sscanf misfeatures
by H. William Welliver III 22 Jun '11

22 Jun '11

I don't recall if anyone else has reported the following problems with sscanf() or not. I'm using 7.8.352 and having the following problems: 1. The + and - modifiers to %c don't seem to work in combination, even though it seems reasonable that one might want to decode a signed value in big endian order. Separately they work fine. 2. The - modifier does not work with %F. I'm currently using a workaround of reading in the bytes as an array, reversing them and then feeding them back into sscanf(). Bill

5 16

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel June 2011