Re: Query cancelled errors - Mailing list pgsql-novice

From Jason Hihn
Subject Re: Query cancelled errors
Date
Msg-id NGBBLHANMLKMHPDGJGAPMEABCNAA.jhihn@paytimepayroll.com
Whole thread Raw
In response to Re: Query cancelled errors  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-novice
I don't no hup pg_ctl ever and I'm fine. (Though I am on Linux)

And you mentioned SIGINT. I'd have thought that disconnecting would only
send a SIGHUP?

I'm betting there is some external resource management screwing with it.
(processor/memory quota?)


> -----Original Message-----
> From: pgsql-novice-owner@postgresql.org
> [mailto:pgsql-novice-owner@postgresql.org]On Behalf Of Tom Lane
> Sent: Tuesday, September 16, 2003 3:09 PM
> To: David Rickard
> Cc: pgsql-novice@postgresql.org
> Subject: Re: [NOVICE] Query cancelled errors
>
>
> David Rickard <David.Rickard@GTScompanies.com> writes:
> >>> ERROR:  Query was cancelled.
>
> > postmaster is running in the background; started via:
> > pg_ctl start -D PG_DATA -s -l PG_LOG -o '-i'
>
> Hm.  I notice that pg_ctl does not use "nohup" to start the postmaster,
> which seems like a really bad idea now that I think about it.  Do things
> get better if you make the relevant section of pg_ctl look like
>
>     if [ -n "$logfile" ]; then
>         nohup "$po_path" ${1+"$@"} </dev/null >>$logfile 2>&1 &
>     else
>         # when starting without log file, redirect stderr to stdout, so
>         # pg_ctl can be invoked with >$logfile and still have pg_ctl's
>         # stderr on the terminal.
>         nohup "$po_path" ${1+"$@"} </dev/null 2>&1 &
>     fi
>
> ?
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>


pgsql-novice by date:

Previous
From: Tom Lane
Date:
Subject: Re: Query cancelled errors
Next
From: Jason Hihn
Date:
Subject: Re: Query cancelled errors