Re: Possible reasons for copy_from to never terminate?

From: <Daniel(dot)Straight(at)Intralox(dot)com>
To: <adrian(dot)klaver(at)aklaver(dot)com>, <psycopg(at)postgresql(dot)org>
Subject: Re: Possible reasons for copy_from to never terminate?
Date: 2015-04-24 14:57:52
Message-ID: f043fadff6b74064adeae22bec43a770@usdlexch3.prod.laitram.loc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: psycopg

> So how long does it 'usually' run?

Usual is best measured in ms. The amount of data is on the order of 100-1000 lines of 10 or so columns.

> Define client.
> Are you talking about the Web client making the POST or the Flask app as client to Postgres?

I'm talking about the web client making the POST request.

> This would Postgres complaining about losing connection to presumably the code you show
> in the Flask app. Though it would be nice to know where exactly the copy_from is in the Flask flow of things.

Right, it's losing connection when I restart, but my concern is how long it was connected in the first place.

> I would say a more complete code snippet would help. Something
> encompassing how the POST data gets into the list_of_strings and then
> into the copy_from()

Sure thing. I have a Flask route which accepts POST requests with a UTF-8 plain text body.
The body is tab-separated data, timestamps and numbers. I read the data line by line using
a map over flask.request.stream, split on tabs, reformat timestamps with isoformat so
Postgres will take them, re-join with tabs and then send it all to copy_from. Here's the code.
convert_timestamps just takes known timestamp columns and replaces them with equivalent
isoformat strings. get_db returns an open psycopg2 connection.
All of this works without issue >99% of the time.

def handle_post():
lines = list(map(
lambda line_data: '\t'.join(convert_timestamps(line_data)),
map(
lambda line: line.decode('utf-8').strip().split('\t'),
flask.request.stream)))
db = get_db()
cursor = db.cursor()
cursor.copy_from(io.StringIO('\n'.join(lines)), 'tablename')
db.commit()
cursor.close()
return len(lines)

So copy_from should be getting data which is entirely in memory. I don't see how it
could never finish reading the data, which is what seems to be happening.

The incoming data is being sent over a slow connection, so sometimes it takes a while
to send, making the total server response time over a second, but it seems like by the
time copy_from is hit, it should definitely have all the data, so the slow connection
doesn't seem like it should be an issue here.

-Daniel

In response to

Responses

Browse psycopg by date

  From Date Subject
Next Message Adrian Klaver 2015-04-24 15:32:16 Re: Possible reasons for copy_from to never terminate?
Previous Message Adrian Klaver 2015-04-24 14:34:28 Re: Possible reasons for copy_from to never terminate?