Hi,
I tried reproduce this bug on CENTOS 6.4 as well as on UBUNTU 13.04.
My Base machine is Window 7 and CentOs, Ubuntu is in VM.
CENTOS :
[amul@localhost postgresql]$ uname -a
Linux localhost.localdomain 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue Apr 23
19:29:00 UTC 2013 x86_64 x86_64 x86_64
I am sorry,
My Ubuntu info was wrong in previous mail, correct one as follow
UBUNTU:
[amul@localhost postgresql]$ uname -a
Linux localhost.localdomain 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue Apr 23
19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
amul@amul:~/work/postgresql$ uname -a
Linux amul
I found a very simple repro on my machine
postgres=# select x, x, lpad('string', 100, x::text) from
generate_series(1, 1000) x;
Killed
So this is just about fetching huge data through psql.
But if I reduce the number of rows by 10 times, it gives result without
getting killed.
2014-02-20 16:16 GMT+09:00 Ashutosh Bapat ashutosh.ba...@enterprisedb.com:
Hi All,
Here is a strange behaviour with master branch with head at
(...)
Looks like a bug in psql to me. Does anybody see that behaviour?
It's not a bug, it's your VM's OS killing off a process which is using
up too
On Thu, Feb 20, 2014 at 2:32 PM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
May be each setup has it's own breaking point. So trying with larger
number might reproduce the issue.
I tried to debug it with gdb, but all it showed me was that psql received
a SIGKILL signal. I am
Ian, Pavan,
That's correct, OS is killing the process
You are correct, the OS is killing the process
3766 Feb 20 14:30:14 ubuntu kernel: [23820.175868] Out of memory: Kill
process 34080 (psql) score 756 or sacrifice child
3767 Feb 20 14:30:14 ubuntu kernel: [23820.175871] Killed process 34080
--On 20. Februar 2014 14:49:28 +0530 Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
If I set some positive value for this variable, psql runs smoothly with
any size of data. But unset that variable, and it gets killed. But it's
nowhere written explicitly that psql can run out of
On Thu, Feb 20, 2014 at 3:26 PM, Bernd Helmle maili...@oopsware.de wrote:
--On 20. Februar 2014 14:49:28 +0530 Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
If I set some positive value for this variable, psql runs smoothly with
any size of data. But unset that variable, and it
On Thu, Feb 20, 2014 at 12:07 PM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
That seems a good idea. We will get rid of FETCH_COUNT then, wouldn't we?
No, I don't think we want to do that. FETCH_COUNT values greater than
1 are still useful to get reasonably tabulated output without
Marti Raudsepp ma...@juffo.org writes:
On Thu, Feb 20, 2014 at 12:07 PM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
That seems a good idea. We will get rid of FETCH_COUNT then, wouldn't we?
No, I don't think we want to do that. FETCH_COUNT values greater than
1 are still useful to
--On 20. Februar 2014 09:51:47 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. The other reason that you can't just transparently change the
behavior is error handling: people are used to seeing either all or
none of the output of a query. In single-row mode that guarantee
fails, since some
On Thu, Feb 20, 2014 at 9:00 PM, Bernd Helmle maili...@oopsware.de wrote:
--On 20. Februar 2014 09:51:47 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. The other reason that you can't just transparently change the
behavior is error handling: people are used to seeing either all or
none
Hi All,
Here is a strange behaviour with master branch with head at
commit d3c4c471553265e7517be24bae64b81967f6df40
Author: Peter Eisentraut pete...@gmx.net
Date: Mon Feb 10 21:47:19 2014 -0500
The OS is
[ashutosh@ubuntu repro]uname -a
Linux ubuntu 3.2.0-59-generic #90-Ubuntu SMP Tue Jan 7
13 matches
Mail list logo
