Re: Receiving many more rows than expected

From: Vincent de Phily <vincent(dot)dephily(at)mobile-devices(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Receiving many more rows than expected
Date: 2014-05-09 12:36:36
Message-ID: 1435843.koQszfdCq7@moltowork
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Friday 09 May 2014 07:01:32 Tom Lane wrote:
> Vincent de Phily <vincent(dot)dephily(at)mobile-devices(dot)fr> writes:
> > In case it changes anything, this is the uncut (but still anonimized)
> >
> > function:
> > query = """UPDATE foo SET processing = 't' WHERE id IN
> >
> > (SELECT id FROM foo WHERE processing = 'f' ORDER BY id ASC
> > LIMIT %d
> >
> > FOR UPDATE)
> >
> > RETURNING *""" % (conf_getint('DEFAULT', 'push_count', 5000),)
>
> Well, of course this view of things exposes a relevant failure mode
> you hadn't mentioned: maybe sometimes the conf_getint() call returns
> something other than 5000?

True. But I've commented already that I'd be very surprised (and wouldn't know
how to begin) if that value was faulty (even though it would explain things
nicely), because
* It is parsed once at program start (using python's ConfigParser library)
* It has the correct value of 5000 in most cases (as demonstrated by the
frequency of number of rows returned)
* There is no sign that I exited the loop (and therefore got the opportunity
to change the value of the query) before I start receiving overlong results.

Still, I agree it's suspicious, so I'm now logging the query string whenever I
get over 5000 results (hardcoded). We'll see next time it happens.

--
Vincent de Phily

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Albe Laurenz 2014-05-09 13:24:44 Re: Oracle to PostgreSQL replication
Previous Message Tom Lane 2014-05-09 11:01:32 Re: Receiving many more rows than expected