Thread: Having no luck with getting pgbench to run multiple times

Hi everyone,

Am trying my hand at a bit of C code again.  Specifically am trying to
get Tatsuo's "pgbench" code to loop around more than once, but it keeps
on hanging forever at this line:

if ((nsocks = select(maxsock + 1, &input_mask, (fd_set *) NULL,(fd_set *) NULL, (struct timeval *) NULL)) < 0)
{

etc

Running this on a FreeBSD 4.6.2 system with PostgreSQL 7.2.2 and gcc
2.95.3.  Looking around the Net seems to say that hangs like this are
caused by the select blocking, but that's not helping me any with
knowing what to do.

Does anyone have an idea of what I can do, or maybe have a few minutes
to look at my code and point out the problem?

:-)

Regards and best wishes,

Justin Clift

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."  - Indira Gandhi

Well, you'll probably want to pass in a valid timeval structure if you
don't want it to block.

Basically, that snippet tells select on the list of sockets, looking for
sockets that have data to be read while waiting forever.  That means it
will block until something appears on one of the sockets your
monitoring.


Greg


On Thu, 2002-09-19 at 13:43, Justin Clift wrote:
> Hi everyone,
>
> Am trying my hand at a bit of C code again.  Specifically am trying to
> get Tatsuo's "pgbench" code to loop around more than once, but it keeps
> on hanging forever at this line:
>
> if ((nsocks = select(maxsock + 1, &input_mask, (fd_set *) NULL,
>     (fd_set *) NULL, (struct timeval *) NULL)) < 0)
> {
>
> etc
>
> Running this on a FreeBSD 4.6.2 system with PostgreSQL 7.2.2 and gcc
> 2.95.3.  Looking around the Net seems to say that hangs like this are
> caused by the select blocking, but that's not helping me any with
> knowing what to do.
>
> Does anyone have an idea of what I can do, or maybe have a few minutes
> to look at my code and point out the problem?
>
> :-)
>
> Regards and best wishes,
>
> Justin Clift
>
> --
> "My grandfather once told me that there are two kinds of people: those
> who work and those who take the credit. He told me to try to be in the
> first group; there was less competition there."
>    - Indira Gandhi
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html

Hi Greg,

That's cool.  Played with it for a while longer, then found out that the
order that it was being called in didn't work very well as the select()
was executed after all the required sockets had been closed/ended.

So, it just meant a re-ordering of things, and it's now working alright.

Am just "fine tuning" this util, and it's looking to be pretty nifty. 
It automatically tunes local or remote PostgreSQL databases (currently
it's limited to the shared_buffers, sort_mem, and vacuum_mem
variables).  But it's a start.  :)

Regards and best wishes,

Justin Clift


Greg Copeland wrote:
> 
> Well, you'll probably want to pass in a valid timeval structure if you
> don't want it to block.
> 
> Basically, that snippet tells select on the list of sockets, looking for
> sockets that have data to be read while waiting forever.  That means it
> will block until something appears on one of the sockets your
> monitoring.
> 
> Greg


-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."  - Indira Gandhi