Christian J Dietrich | 12 Feb 2008 21:07
Picon

Copy_from gets stuck with bigger input file

Dear list,

I am experiencing some problems with copy_from() when feeding it with
input files that are quite large (spoken in number of lines, not file 
size). If a file exceeds a certain number of lines, copy_from simply 
hangs and does not return. I am using psycopg2 2.0.6. PostgreSQL is 
version 8.2.4.

In detail, I tried to feed the table as defined below:
create table test_2 (my_num int);

a) - created a file of 118k lines, each line is just "30000\n" (could
      be any string)
    - fed it into the DB via psycopg2

b) - added 1k lines, each line is just "30000\n" to the file before
    - fed it to the DB via psycopg2

Although a) works fine for me, b) just stucks. To me it's not clear
what happens here, since neither CPU nor memory is wasted during this
time. SIGINT does not interrupt the copy_from() call, first SIGTERM
actually stops the computation. Looks like a memory story to me, or some
constraints of stdin. Apparently the number of lines is not the only
criteria, since copying tables with multiple columns leads to the same
problem with less rows.

Would be great if someone could help me out. Just for completeness, both
scenarios worked well using the cmd line client psql combined with COPY. 
Here are the file sizes:
692K  /tmp/input118k
(Continue reading)

Phil Frost | 13 Feb 2008 14:59
Favicon

Re: Copy_from gets stuck with bigger input file

I encountered this problem some time ago. I don't think I found a  
solution. See:
http://lists.initd.org/pipermail/psycopg/2007-June/005552.html
http://lists.initd.org/pipermail/psycopg/2007-June/005553.html

On Feb 12, 2008, at 15:07 , Christian J Dietrich wrote:

> Dear list,
>
> I am experiencing some problems with copy_from() when feeding it with
> input files that are quite large (spoken in number of lines, not file
> size). If a file exceeds a certain number of lines, copy_from simply
> hangs and does not return. I am using psycopg2 2.0.6. PostgreSQL is
> version 8.2.4.
>
> In detail, I tried to feed the table as defined below:
> create table test_2 (my_num int);
>
> a) - created a file of 118k lines, each line is just "30000\n" (could
>       be any string)
>     - fed it into the DB via psycopg2
>
> b) - added 1k lines, each line is just "30000\n" to the file before
>     - fed it to the DB via psycopg2
>
> Although a) works fine for me, b) just stucks. To me it's not clear
> what happens here, since neither CPU nor memory is wasted during this
> time. SIGINT does not interrupt the copy_from() call, first SIGTERM
> actually stops the computation. Looks like a memory story to me, or  
> some
(Continue reading)

psycopg | 13 Feb 2008 17:06
Favicon
Gravatar

[psycopg] #211: Incorrect memory allocation in connection_type.c

#211: Incorrect memory allocation in connection_type.c
----------------------+-----------------------------------------------------
 Reporter:  ctheune   |       Owner:  fog          
     Type:  defect    |      Status:  new          
 Priority:  high      |   Milestone:  PSYCOPG 2.0.7
Component:  psycopg2  |     Version:  2.0.5        
 Severity:  critical  |    Keywords:               
----------------------+-----------------------------------------------------
 Setting the client encoding to a string that does not contain an
 underscore or dash ('_', '-') causes an incorrect memory allocation
 because strlen() is used for memory allocation where strlen()+1 needs to
 be used.

 The attached patch fixes the problem.

 The crash only appears stochastically but causes segfaults on a somewhat
 busy Zope server within less than 6-10 hours.

 Note: This is actually an error in version 2.0.6 but the dropdown doesn't
 have this for a choice.

--

-- 
Ticket URL: <http://www.initd.org/tracker/psycopg/ticket/211>
psycopg <http://initd.org/>
psycopg
Nathan | 15 Feb 2008 20:10
Picon
Gravatar

Error during "SELECT" using psycopg 2.0.2

Hi, I'm new to this list.  I've been using psycopg for a few years
now, but have just recently begun experiencing problems with one of my
scripts that I've started using more often than I used to.

I've got a python script (python 2.4.2 on 32-bit linux) that uses
python threads and psycopg (2.0.2) to connect to postgres (8.2.3).
The threads each do a bunch of selects, inserts, updates, and deletes,
and I've started intermittently having crashes with the following
error:

Exception in thread Thread-45:
Traceback (most recent call last):
  File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
    self.run()
[snip]
OperationalError: ERROR:  SET TRANSACTION ISOLATION LEVEL must be
called before any query

The oddest thing to me is the error occurs on a SELECT statement in the form of:

SELECT col1, col2, col3 from table1 where col1='val1' and col2='val2';

...which seems like the last kind of statement that would trip an error.

Where should I look next to debug this?  As this crash happens
_sometimes_ (maybe 15% of the time), I'm having a hard time
duplicating it (which seems typical for thread-related errors).  I sit
down to debug it when I find it has happened, run the script again so
I can try to isolate the crash but the script successfully completes,
so I have to wait another day for more data to be available to
(Continue reading)

Federico Di Gregorio | 16 Feb 2008 18:00
Favicon
Gravatar

Re: Error during "SELECT" using psycopg 2.0.2


Il giorno ven, 15/02/2008 alle 12.10 -0700, Nathan ha scritto:
> I've got a python script (python 2.4.2 on 32-bit linux) that uses
> python threads and psycopg (2.0.2) to connect to postgres (8.2.3).
> The threads each do a bunch of selects, inserts, updates, and deletes,
> and I've started intermittently having crashes with the following
> error:
> 
> Exception in thread Thread-45:
> Traceback (most recent call last):
>   File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
>     self.run()
> [snip]
> OperationalError: ERROR:  SET TRANSACTION ISOLATION LEVEL must be
> called before any query

Are you using one connection per thread? Also, before going on make sure
to use an up to date psycopg, like 2.0.6.

federico

--

-- 
Federico Di Gregorio                         http://people.initd.org/fog
Debian GNU/Linux Developer                                fog@...
INIT.D Developer                                           fog@...
 I porcellini di terra sono davvero Crostacei! Non lo sapevo!
  Certo che sono crostacei, hanno la crosta!
  Allora la pizza รจ un crostaceo?!               -- discorso all'ESC2k07
(Continue reading)

psycopg | 16 Feb 2008 21:56
Favicon
Gravatar

Re: [psycopg] #171: #ifdef PSYCOPG_DEBUG , defined by default??

#171: #ifdef PSYCOPG_DEBUG , defined by default??
----------------------+-----------------------------------------------------
 Reporter:  kumar303  |        Owner:  fog          
     Type:  defect    |       Status:  assigned     
 Priority:  low       |    Milestone:  PSYCOPG 2.0.7
Component:  psycopg2  |      Version:  2.0.5        
 Severity:  normal    |   Resolution:               
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by Eoghan):

 I also had this issue just as described with easy_install, the hack given
 above worked for me, thx.

 If it's relevant gcc is version 4.0.3

--

-- 
Ticket URL: <http://www.initd.org/tracker/psycopg/ticket/171#comment:4>
psycopg <http://initd.org/>
psycopg
Nathan | 18 Feb 2008 00:27
Picon
Gravatar

Re: Error during "SELECT" using psycopg 2.0.2

On Feb 16, 2008 10:00 AM, Federico Di Gregorio <fog@...> wrote:
> Are you using one connection per thread? Also, before going on make sure
> to use an up to date psycopg, like 2.0.6.

Each thread shares a common db connection, but creates its own cursor.
 As psycopg2.threadsafety == 2, that's supposed to be acceptable
according to: http://www.python.org/dev/peps/pep-0249/    If the
threadsafety level is not really 2, please let me know.

2.0.6?  According to the psycopg project page, 2.0.2 _IS_ the latest
version (???)  See http://www.initd.org/tracker/psycopg    ... Am I
looking in the wrong place?

~ Nathan
Adrian Klaver | 18 Feb 2008 00:30
Picon

Re: Error during "SELECT" using psycopg 2.0.2

On Sunday 17 February 2008 3:27 pm, Nathan wrote:
> On Feb 16, 2008 10:00 AM, Federico Di Gregorio <fog@...> wrote:
> > Are you using one connection per thread? Also, before going on make sure
> > to use an up to date psycopg, like 2.0.6.
>
> Each thread shares a common db connection, but creates its own cursor.
>  As psycopg2.threadsafety == 2, that's supposed to be acceptable
> according to: http://www.python.org/dev/peps/pep-0249/    If the
> threadsafety level is not really 2, please let me know.
>
> 2.0.6?  According to the psycopg project page, 2.0.2 _IS_ the latest
> version (???)  See http://www.initd.org/tracker/psycopg    ... Am I
> looking in the wrong place?

http://initd.org/pub/software/psycopg/
>
> ~ Nathan
> _______________________________________________
> Psycopg mailing list
> Psycopg@...
> http://lists.initd.org/mailman/listinfo/psycopg

--

-- 
Adrian Klaver
aklaver@...
Federico Di Gregorio | 18 Feb 2008 00:38
Favicon
Gravatar

Re: Error during "SELECT" using psycopg 2.0.2


Il giorno dom, 17/02/2008 alle 16.27 -0700, Nathan ha scritto:
> On Feb 16, 2008 10:00 AM, Federico Di Gregorio <fog@...> wrote:
> > Are you using one connection per thread? Also, before going on make sure
> > to use an up to date psycopg, like 2.0.6.
> 
> Each thread shares a common db connection, but creates its own cursor.
>  As psycopg2.threadsafety == 2, that's supposed to be acceptable
> according to: http://www.python.org/dev/peps/pep-0249/    If the
> threadsafety level is not really 2, please let me know.

You can share connections but should take care of the ordering of the
queries because all cursors from the same connection share the same SQL
session.

> 2.0.6?  According to the psycopg project page, 2.0.2 _IS_ the latest
> version (???)  See http://www.initd.org/tracker/psycopg    ... Am I
> looking in the wrong place?

The version on the tracker is a little bit out of date. Try:

http://initd.org/pub/software/psycopg/

for the last version.

federico

--

-- 
Federico Di Gregorio                         http://people.initd.org/fog
Debian GNU/Linux Developer                                fog@...
(Continue reading)

psycopg | 18 Feb 2008 14:40
Favicon
Gravatar

Re: [psycopg] #171: #ifdef PSYCOPG_DEBUG , defined by default??

#171: #ifdef PSYCOPG_DEBUG , defined by default??
----------------------+-----------------------------------------------------
 Reporter:  kumar303  |        Owner:  fog          
     Type:  defect    |       Status:  assigned     
 Priority:  low       |    Milestone:  PSYCOPG 2.0.7
Component:  psycopg2  |      Version:  2.0.5        
 Severity:  normal    |   Resolution:               
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by jamesh):

 I just tested this and could not reproduce.

 This was with gcc 4.1.3 (Ubuntu amd64), Python 2.5.1 and setuptools 0.6c6.
 It installed psycopg2 2.0.6 and no debug messages were printed when I
 imported "psycopg2" using the resulting egg.

 What version of setuptools do you see problems on, and what version do you
 not see problems on?

--

-- 
Ticket URL: <http://www.initd.org/tracker/psycopg/ticket/171#comment:5>
psycopg <http://initd.org/>
psycopg

Gmane