Martin Pitt writes:
> The updated patch only uses the gcc builtins if there is no explicit
> implementation, but drops the arm one as this doesn't work on ARMv7
> and newer, as stated in the original mail.
Getting this thread back to the original patch ... I'm afraid that if we
apply this as-is,
On 19/12/2011 11:14 PM, Andrea Grassi wrote:
Hi, Craig
Now my process is blocked and I have the case in my hands.
Do you have something to ask me in order to have more details ?
As I tend to agree with Tom re this being a kernel issue, try (as root):
# Enable stack dumps etc via sysrq
echo 8 >
On 21/12/2011 1:42 AM, Tom Lane wrote:
Hrm. What's with the 48 bytes in the client's receive queue? Surely
the kernel should be reporting that the socket is read-ready, if it's
got some data. I think you've found an obscure kernel bug somehow
it's failing to wake the poll() caller.
I've
Tom Lane wrote:
> On reflection what seems most likely is simply that turning these
> otherwise-inlineable SQL functions into SECURITY DEFINER disabled
> inline-ing them, resulting in catastrophic degradation of the
> generated plans, such that they took a lot longer than you were
> accustomed t
"Kevin Grittner" writes:
> ... It wasn't even clear to me that it was
> OK to have one security definer function call another, based on the
> code comment I quoted, so I didn't want to spend more hours on
> attempting to create a test case if it simply wasn't supported.
Yes, that's definitely *s
Tom Lane wrote:
> "Kevin Grittner" writes:
>> No comments on this?
>
> If there was a reproducible test case in your original message,
> I didn't see it, so I assumed you intended to investigate further
> on your own. It wasn't even clear to me that this was a Postgres
> bug rather than some er
"Kevin Grittner" writes:
> No comments on this?
If there was a reproducible test case in your original message,
I didn't see it, so I assumed you intended to investigate further
on your own. It wasn't even clear to me that this was a Postgres
bug rather than some error in your trigger logic.
No comments on this? It seems to me that at a minimum this needs
better documentation of a limitation, and the conditions under which
you hit the problem. I'm not sure there isn't an outright bug here.
We would like to flag all of our trigger functions as SECURITY
DEFINER, but there are triggers
Simon Riggs writes:
> On Tue, Dec 20, 2011 at 5:50 PM, Peter Geoghegan
> wrote:
>> In fact, that macro is defined in access/htup.h...should it be?
> IMHO comment is wrong, code is in the right place.
It used to be in heapam.h ... evidently, whoever moved it missed this
comment.
On Tue, Dec 20, 2011 at 5:50 PM, Peter Geoghegan wrote:
> Line 834 of heapam.c has the following comment:
>
> /*
> * This is formatted so oddly so that the correspondence to the macro
> * definition in access/heapam.h is maintained.
> */
>
> In fact, that macro is defined in access/htup.h...sho
Line 834 of heapam.c has the following comment:
/*
* This is formatted so oddly so that the correspondence to the macro
* definition in access/heapam.h is maintained.
*/
In fact, that macro is defined in access/htup.h...should it be?
--
Peter Geoghegan http://www.2ndQuadrant.com/
Postg
"Andrea Grassi" writes:
> This is the server side stack kept by gdb:
> [ server is waiting to receive something from client ]
> The netstat command on client and server connection has this output:
> The first line should be the server, the second the client.
> Proto Recv-Q Send-Q Local Address
This is the server side stack kept by gdb:
(gdb) bt full
#0 0x2b6488588ae5 in recv () from /lib64/libc.so.6
No symbol table info available.
#1 0x00550cd2 in secure_read ()
No symbol table info available.
#2 0x005563a4 in pq_recvbuf ()
No symbol table info available.
#3 0x00
"Andrea Grassi" writes:
> #0 0xe410 in __kernel_vsyscall ()
> No symbol table info available.
> #1 0xf76539cb in poll () from /lib/libc.so..
> #2 0xf770d39a in pqSocketCheck () from /home/pg/pgsql/lib-32/libpq.so.5
> #3 0xf770d49d in pqWaitTimed () from /home/pg/pgsql/lib-32/libpq.so.5
>
You wrote:
> I also have a client suffering an occasional 'application hang' running Suse
> 11.2 and postgressql 8.4
> on an 8 core box which is not reproducable in a VMWare test environment.
> Access to postgres is libpq 127.0.0.1 as well.
> Unfortunately the client must restart ASAP and I ha
This is the output of "bt full" command in gdb of my test program.
In this case the libpqs was not compiled in debug-mode.
(gdb) bt full
#0 0xe410 in __kernel_vsyscall ()
No symbol table info available.
#1 0xf76539cb in poll () from /lib/libc.so.6
No symbol table info available.
#2 0xf770
Excerpts from Andrea Grassi's message of mar dic 20 06:01:55 -0300 2011:
> Sorry if I insist, but now I have the case at hand (my test program is now
> blocked), so I can check and verify all what you want.
> I would like to know if it can be a libpq bug or if you think the fault is
> due to a s
I also have a client suffering an occasional 'application hang' running
Suse 11.2 and postgressql 8.4 on an 8 core box which is not reproducable
in a VMWare test environment.
Access to postgres is libpq 127.0.0.1 as well. Unfortunately the client
must restart ASAP and I have not produced a 'test
Sorry if I insist, but now I have the case at hand (my test program is now
blocked), so I can check and verify all what you want.
I would like to know if it can be a libpq bug or if you think the fault is due
to a system bug or to a machine issue and in this case I would be grateful if
you could
19 matches
Mail list logo
