Federico Di Gregorio | 1 Dec 16:18 2003

Re: mxDateTime used by Psycopg truncates timestamps to 2 decimal places.

Il sab, 2003-11-29 alle 05:07, Scott Chapman ha scritto:
[snip]
>  B<br />              | 2003-11-28 19:03:10.244694
>  Here's a test.<br /> | 2003-11-28 19:20:24.397383
>  A<br />              | 2003-11-28 19:21:22.60825
> 
> Is there any way to make psycopg NOT truncate these entries?

fast answer: yes, install a dedicate typecaster and convert the string
to wathever you like. see doc/examples/usercast.py for example code on
how to install custom typecasters.

I don't know if the problem is in psycopg or mx.DateTime but I'll check
and fix it if in psycopg.

hope this helps,
federico

--

-- 
Federico Di Gregorio                         http://people.initd.org/fog
Debian GNU/Linux Developer                                fog@...
INIT.D Developer                                           fog@...
  I terminali seriali sono in via di estinzione (infatti quello che
   c'era si è estinto)                                 -- Simone Caldana
_______________________________________________
Psycopg mailing list
Psycopg@...
http://lists.initd.org/mailman/listinfo/psycopg
(Continue reading)

Sebastien Bigaret | 1 Dec 16:46 2003
Picon
Picon

Errors ignored for cnx.commit()


        Hi Federico & all,

  I've just noticed that psycopg ignores and discards (at least some -)
  errors happening when a cnx is committed.

DB schema:
----------
CREATE TABLE A ( ID INTEGER NOT NULL, FK_B INTEGER);
CREATE TABLE B ( ID INTEGER NOT NULL );
ALTER TABLE A ADD PRIMARY KEY (ID);
ALTER TABLE B ADD PRIMARY KEY (ID);
ALTER TABLE A ADD CONSTRAINT b FOREIGN KEY (FK_B) REFERENCES B(ID) INITIALLY DEFERRED;

python code: (psycopg compiled w/ PSYCHOTIC_DEBUG)
------------
>>> import psycopg
>>> cnx=psycopg.connect("host=localhost dbname=AB user=postgres")
>>> cur=cnx.cursor()
>>> cur.execute("INSERT INTO A ( FK_B, ID ) VALUES ( 1,1 )")
>>> cnx.commit()
[10184] curs_commitall(): acquiring lock
[10184] curs_commitall(): lock acquired
[10184] curs_commitall(): commit on 2 cursors
[10184] curs_commitall(): acquired lock on keeper 0x8185860
[10184] commit_pgconn(): pgconn = 0x81855a0, level = 2, status = 1
[10184] commit_pgconn(): query executed
[10184] commit_pgconn(): result is NOT OK
[10184] psyco_curs_close(): closing cursor at 0x815c9a8
[10184] pgconn_resolve_critical(): resolved
(Continue reading)

Sebastien Bigaret | 1 Dec 16:52 2003
Picon
Picon

Re: Errors ignored for cnx.commit()


I wrote:
[...]
>   Of course the code used in _psyco_curs_execute() to handle the error
>   can be duplicated in psyco_conn_commit(), given that curs_commitall()
>   checks the status returned by commit_pgconn() and forwards the error
>   to the caller. I would have submitted the quite straightforward patch
>   doing this, if only I knew what should be done in the loop committing
>   the cursors: should the loop be immediately stopped? Is there
>   something that should be done for the cursors that succeeded in
>   committing their changes before the error happens?

I forgot to tell that this pb annoys me and that I'll be happy to
propose a patch for this if I can get answers to the questions above ;)

-- Sébastien.
Federico Di Gregorio | 1 Dec 23:27 2003

Re: Errors ignored for cnx.commit()

Il lun, 2003-12-01 alle 16:52, Sebastien Bigaret ha scritto:
> I wrote:
> [...]
> >   Of course the code used in _psyco_curs_execute() to handle the error
> >   can be duplicated in psyco_conn_commit(), given that curs_commitall()
> >   checks the status returned by commit_pgconn() and forwards the error
> >   to the caller. I would have submitted the quite straightforward patch
> >   doing this, if only I knew what should be done in the loop committing
> >   the cursors: should the loop be immediately stopped? Is there
> >   something that should be done for the cursors that succeeded in
> >   committing their changes before the error happens?
> 
> I forgot to tell that this pb annoys me and that I'll be happy to
> propose a patch for this if I can get answers to the questions above ;)

give me 24h and i'll answer. i don't have a single sec right now. :(
(this mail is just to tell you i'am not ignoring this serious problem,
thank you very much for reporting it.)

--

-- 
Federico Di Gregorio                         http://people.initd.org/fog
Debian GNU/Linux Developer                                fog@...
INIT.D Developer                                           fog@...
                              Viviamo in un mondo reale, Ciccio. -- Lucy
_______________________________________________
Psycopg mailing list
Psycopg@...
http://lists.initd.org/mailman/listinfo/psycopg
(Continue reading)

Geoff Davis | 2 Dec 21:20 2003
Picon

ZPsycopgDA and PostgreSQL 7.4

One other change that needs to be made for PostgreSQL 7.4 is the code in
ZPsycopgDA that handles problems with concurrent updates.  I believe that
line 212 of db.py should be changed to "ERROR: could not serialize access
due to concurrent update"

Also __psycopg_versions__ in DA.py (line 86) needs to have 1.1.11 added.

Geoff
Sebastien Bigaret | 2 Dec 15:11 2003
Picon
Picon

Re: Errors ignored for cnx.commit()


Federico Di Gregorio <fog@...> wrote:
> Il lun, 2003-12-01 alle 16:52, Sebastien Bigaret ha scritto:
> > I wrote:
> > [...]
> > >   Of course the code used in _psyco_curs_execute() to handle the error
> > >   can be duplicated in psyco_conn_commit(), given that curs_commitall()
> > >   checks the status returned by commit_pgconn() and forwards the error
> > >   to the caller. I would have submitted the quite straightforward patch
> > >   doing this, if only I knew what should be done in the loop committing
> > >   the cursors: should the loop be immediately stopped? Is there
> > >   something that should be done for the cursors that succeeded in
> > >   committing their changes before the error happens?
> > 
> > I forgot to tell that this pb annoys me and that I'll be happy to
> > propose a patch for this if I can get answers to the questions above ;)
> 
> give me 24h and i'll answer. i don't have a single sec right now. :(
> (this mail is just to tell you i'am not ignoring this serious problem,
> thank you very much for reporting it.)

Okay, fine, I'll add further comments then ;)

  You'll find enclosed my first attempt for a patch, just in case it
might help to save some time. I made the following assumptions:

- a cursor that failed should be usable again after the exception is
  raised by commit(), so the 'critical state' should be reset after
  commit(),

(Continue reading)

Federico Di Gregorio | 4 Dec 11:36 2003

Re: ZPsycopgDA and PostgreSQL 7.4

Il mar, 2003-12-02 alle 21:20, Geoff Davis ha scritto:
> One other change that needs to be made for PostgreSQL 7.4 is the code in
> ZPsycopgDA that handles problems with concurrent updates.  I believe that
> line 212 of db.py should be changed to "ERROR: could not serialize access
> due to concurrent update"
> 
> Also __psycopg_versions__ in DA.py (line 86) needs to have 1.1.11 added.

will be in next release. thank you very much.

--

-- 
Federico Di Gregorio                         http://people.initd.org/fog
Debian GNU/Linux Developer                                fog@...
INIT.D Developer                                           fog@...
  We are all dust, Saqi, so play the lute
                    We are all wind, Saqi, so bring wine. -- Omar Khayam
_______________________________________________
Psycopg mailing list
Psycopg@...
http://lists.initd.org/mailman/listinfo/psycopg
Federico Di Gregorio | 4 Dec 22:24 2003

Re: Errors ignored for cnx.commit()

Il mar, 2003-12-02 alle 15:11, Sebastien Bigaret ha scritto:
[snip]
>   Note that I choose to raise DatabaseError, just because for this 1st
> draft, I did not want to check for IntegrityError vs. ProgrammingError
> as this is done in _psyco_curs_execute() (plus I'm not sure a
> ProgrammingError can happen at this point, but who knows...).

i think this is the right short-term solution for the 1.1.x series. will
be in next release, due this weekend. i really hope 1.1.12 will be the
*last* 1.1.x release for a long time and use my free time to finish 2.0.
:)

thank you very much for the fix. if you want to add a check for
IntegrityError that would be great, but we can do without it right now.

federico

--

-- 
Federico Di Gregorio                         http://people.initd.org/fog
Debian GNU/Linux Developer                                fog@...
INIT.D Developer                                           fog@...
            Bhoe, bhe, bhe. Sono brutto e cattivo. Brutto lama! -- Cuzco
_______________________________________________
Psycopg mailing list
Psycopg@...
http://lists.initd.org/mailman/listinfo/psycopg
Menno Smits | 5 Dec 01:31 2003

Determining the process ID of a postgresql backend

Hi all,

Just thought I'd share this little hack which can be used to determine 
the process id of the postgresql backend you're talking to. Only works 
for non-serialized connections and assumes autocommit(0). I'd be 
interested in alternative ways of doing this. Could psycopg report the pid?

We needed this so we could renice the backend process to a lower 
priority for an intensive long running background query (yes you need to 
be running as the same user as the postgresql backend or root). There 
may be other uses...

---< snip >-----------------------

import time
import os
import psycopg

def pgbepid(cnx):
     """Return the pid of the backend attached to the psycopg connection

     Passing in a non-serialized connection will probably not work as
     expected.

     Returns None if PID could not be determined (some sort of error)
     May also raise psycopg.Error
     """
     notify_name = 'dbpid_%d_%d' % (os.getpid(), time.time())

     c = cnx.cursor()
(Continue reading)

Sebastien Bigaret | 5 Dec 18:19 2003
Picon
Picon

Re: Errors ignored for cnx.commit()


Federico Di Gregorio <fog@...> wrote:
> Il mar, 2003-12-02 alle 15:11, Sebastien Bigaret ha scritto:
> [snip]
> >   Note that I choose to raise DatabaseError, just because for this 1st
> > draft, I did not want to check for IntegrityError vs. ProgrammingError
> > as this is done in _psyco_curs_execute() (plus I'm not sure a
> > ProgrammingError can happen at this point, but who knows...).
> 
> i think this is the right short-term solution for the 1.1.x series. will
> be in next release, due this weekend. i really hope 1.1.12 will be the
> *last* 1.1.x release for a long time and use my free time to finish 2.0.
> :)

Okay, well, my best wishes for that then ;)

> thank you very much for the fix. if you want to add a check for
> IntegrityError that would be great, but we can do without it right now.

  In fact, we'd need to raise IntegrityError if, and only if, all errors
  that were raised are integrity errors. I don't really think this is
  worth the effort, I also think we can live w/ DatabaseError at this
  point (esp. because I do not have much time forn that either :)

Anyway, you'll find attached a new patch. Differences with the first one
are:

- it correctly checks that the errors dictionary is created (if it
  couldn't be created, the value attached to the exception is None),

(Continue reading)


Gmane