On 12/4/15 4:15 AM, Peter J. Holzer wrote:
On 2015-12-03 10:02:18 -0500, Tom Lane wrote:
>"Peter J. Holzer" writes:
> >Can those signals be safely ignored? Just blocking them (so that they
> >are delivered after the UDF finishes) might be safer. But even that may
> >be a problem: If the UDF th
On 2015-12-03 10:02:18 -0500, Tom Lane wrote:
> "Peter J. Holzer" writes:
> > Can those signals be safely ignored? Just blocking them (so that they
> > are delivered after the UDF finishes) might be safer. But even that may
> > be a problem: If the UDF then executes some SQL, could that rely on
>
"Peter J. Holzer" writes:
> Can those signals be safely ignored? Just blocking them (so that they
> are delivered after the UDF finishes) might be safer. But even that may
> be a problem: If the UDF then executes some SQL, could that rely on
> signals being delivered? I have no idea.
The minute
On 2015-12-02 19:07:55 -0600, Jim Nasby wrote:
> On 12/2/15 9:26 AM, Peter J. Holzer wrote:
> >As explained in backend/utils/misc/timeout.c, the timers are never
> >cancelled: If a timeout is cancelled, postgres just sees that it has
> >nothing to do and resumes whatever it is doing.
>
> Hrm, if t
On 12/2/15 9:26 AM, Peter J. Holzer wrote:
As explained in backend/utils/misc/timeout.c, the timers are never
cancelled: If a timeout is cancelled, postgres just sees that it has
nothing to do and resumes whatever it is doing.
Hrm, if those timers are really just for auth purposes then perhaps
On 2015-12-01 20:55:02 +0100, Peter J. Holzer wrote:
> On 2015-12-01 18:58:31 +0100, Peter J. Holzer wrote:
> > I suspect such an interaction because I cannot reproduce the problem
> > outside of a stored procedure. A standalone Perl script doing the same
> > requests doesn't get a timeout.
[...]
>
On 2015-12-01 13:13:27 -0500, Tom Lane wrote:
> "Peter J. Holzer" writes:
> > Postgres worker processes are single-threaded, are they? Is there
> > something else which could interact badly with a moderately complex
> > multithreaded I/O library used from a stored procedure?
>
> Yes, lots. If y
On 2015-12-01 18:58:31 +0100, Peter J. Holzer wrote:
> I suspect such an interaction because I cannot reproduce the problem
> outside of a stored procedure. A standalone Perl script doing the same
> requests doesn't get a timeout.
>
> I guess Alvaro is right: I should strace the postgres worker pr
On 2015-12-01 10:20:09 -0800, Adrian Klaver wrote:
> On 12/01/2015 09:58 AM, Peter J. Holzer wrote:
> >On 2015-12-01 07:16:04 -0800, Adrian Klaver wrote:
> >>On 12/01/2015 06:51 AM, Peter J. Holzer wrote:
> >>>A rather weird observation from the log files of our server (9.5 beta1):
> >>>
> >>>2015-
On 12/01/2015 09:58 AM, Peter J. Holzer wrote:
On 2015-12-01 07:16:04 -0800, Adrian Klaver wrote:
On 12/01/2015 06:51 AM, Peter J. Holzer wrote:
A rather weird observation from the log files of our server (9.5 beta1):
2015-12-01 09:23:37 CET [26265]: [42-1] user=fragner,db=wds,pid=26265 WARNIN
"Peter J. Holzer" writes:
> But there is something else which may be relevant: ØMQ uses threads
> internally, and I don't actually know whether zmq_msg_recv returning
> means that the read(2) call (or whatever) on the socket terminates.
... ugh ...
> Postgres worker processes are single-threaded
On 2015-12-01 07:16:04 -0800, Adrian Klaver wrote:
> On 12/01/2015 06:51 AM, Peter J. Holzer wrote:
> >A rather weird observation from the log files of our server (9.5 beta1):
> >
> >2015-12-01 09:23:37 CET [26265]: [42-1] user=fragner,db=wds,pid=26265
> >WARNING: Use of uninitialized value $succ
On Tue, Dec 1, 2015 at 8:51 AM, Peter J. Holzer wrote:
> What could cause a plperlu procedure to freeze for 68
> seconds between the call to confess and its output?
> Another weird thing: $success is undef because a ØMQ rpc call[1] timed
> out (after 60 seconds, which is also a mystery, because
Peter J. Holzer wrote:
> Two messages from the same line of the same plperlu stored procedure, 68
> seconds apart. So what is this line 36?
>
> confess "impossible result '$success' (payload=$payload)";
>
> What? The first message clearly comes from interpolating $success
> (which is undef a
On 12/01/2015 06:51 AM, Peter J. Holzer wrote:
A rather weird observation from the log files of our server (9.5 beta1):
2015-12-01 09:23:37 CET [26265]: [42-1] user=fragner,db=wds,pid=26265 WARNING:
Use of uninitialized value $success in concatenation (.) or string at
/usr/local/share/perl/5.
A rather weird observation from the log files of our server (9.5 beta1):
2015-12-01 09:23:37 CET [26265]: [42-1] user=fragner,db=wds,pid=26265 WARNING:
Use of uninitialized value $success in concatenation (.) or string at
/usr/local/share/perl/5.20.2/WDS/Macrobond/Utils.pm line 36.
2015-12-01 0
16 matches
Mail list logo
