Using PostgreSQL 8.4.13 on ScientificLinux 6.3 (x86_64), I noticed
that a pg_dump ran out of (local) disk space.
However, the server was still using CPU and disk resources. An strace
clearly showed this pattern:
read() = 8192
sendto(...) = -1 EPIPE
-- SIGPIPE (Broken pipe) @
The server
On Tue, Jan 31, 2012 at 2:03 PM, Robert Haas wrote:
> On Tue, Jan 31, 2012 at 10:38 AM, Jon Nelson
> wrote:
>> Example (using one of google's IPv6 addrs):
>>
>> jnelson=# select inet '0::0' - inet '2001:4860:4006:800::1011';
>> ERROR:
Example (using one of google's IPv6 addrs):
jnelson=# select inet '0::0' - inet '2001:4860:4006:800::1011';
ERROR: result is out of range
jnelson=#
--
Jon
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/
On Thu, Mar 31, 2011 at 2:58 AM, Heikki Linnakangas
wrote:
> On 30.03.2011 21:06, Jon Nelson wrote:
>>
>> The short version is that if a postgresql backend is killed (by the Linux
>> OOM handler, or kill -9, etc...) while operations are
>> taking place in a *differ
On Fri, Jul 1, 2011 at 3:27 PM, Tom Lane wrote:
> Jon Nelson writes:
>> With 8.4.7, I ran into an issue trying to explain a VIEW query.
>> After much effort, I distilled the query down and was able to
>> replicate the issue with a test script, included below.
>
> FWI
The problem was observed on CentOS 5.6 using postgresql 8.4.7 and
Scientific Linux 6.0 also using postgresql 8.4.7.
The problem could not be replicated on openSUSE 11.4 which has postgresql 9.0.3.
With 8.4.7, I ran into an issue trying to explain a VIEW query.
After much effort, I distilled the qu
On Thu, Apr 21, 2011 at 11:28 AM, Tom Lane wrote:
> Jon Nelson writes:
>> SQLAlchemy encountered an error introspecting the tables. After
>> inspecting the SQL that it was running, I boiled it down to this:
>
>> SELECT c.relname, a.attname
>> FROM pg_index i, pg_cl
I'm using SQLAlchemy which has database introspection smarts.
Basically, you point it at a database and tell it to find out what
tables are there and introspect them, the table indices, etc...
It works super.
Until today.
Yesterday, I restructured one of my tables (specifically, I dropped
one col
On Thu, Mar 31, 2011 at 2:58 AM, Heikki Linnakangas
wrote:
> On 30.03.2011 21:06, Jon Nelson wrote:
>>
>> The short version is that if a postgresql backend is killed (by the Linux
>> OOM handler, or kill -9, etc...) while operations are
>> taking place in a *differ
Please bear with me, as it's taken me a while to be able to reproduce an
issue that is worrisome.
Before I describe the problem, I am using postgresql version 8.4.5 on
CentOS 5.5 (x86_64).
The short version is that if a postgresql backend is killed (by the Linux
OOM handler, or kill -9, etc...) w
On Thu, Mar 3, 2011 at 5:10 PM, Tom Lane wrote:
> Josh Berkus writes:
>> echo $TZ returns nothing. We've checked several Ubuntu systems, and it
>> seems that Ubuntu does not set $TZ.
>
> Red Hat doesn't either; I think this is a general habit on Linux
> distros.
If you are using glibc, this is
While tracking down some issues that /might/ be kernel related, I ran
into an error message:
ERROR: concurrent delete in progress
With this SQL in a file (t.sql):
begin;
create temporary table foo as select x as a, ARRAY[x] as b FROM
generate_series(1, 1000 ) AS x;
create index foo_a_idx on
On 11/22/10, Tom Lane wrote:
> Jon Nelson writes:
>> Here is the problem: When I started benchmarking this application, I
>> noticed it (postgresql) started chewing up inodes on the logical
>> volume which houses /var/lib/pgsql. It chewed up a few thousand
>> inod
I have an application which, during the normal course of its
operation, creates a single temporary table.
BEGIN;
-- bunch of stuff here
CREATE TEMPORARY TABLE results ON COMMIT DROP AS SELECT
-- a bit more stuff here
ROLLBACK;
In this case, *every* transaction ends in a rollback.
Here is the pr
On Wed, Nov 17, 2010 at 8:57 PM, Robert Haas wrote:
> On Tue, Nov 16, 2010 at 10:48 AM, Jon Nelson
> wrote:
>> I have a process which runs in parallel creating tables which, as the
>> /final/ step in the import, gets SQL much like the following applied:
>>
>&g
I have a process which runs in parallel creating tables which, as the
/final/ step in the import, gets SQL much like the following applied:
ALTER TABLE foo INHERIT bar;
Periodically, I get this error: tuple concurrently updated
Of course, I googled for the error message and see a bunch of issue
I get this whenever debug_print_rewritten = on
WARNING: 01000: could not dump unrecognized node type: 928
LOCATION: _outNode, outfuncs.c:2787
right before
LOG: 0: rewritten parse tree:
PostgreSQL 8.4.5 on Linux x86-64
Does this sound familiar?
--
Jon
--
Sent via pgsql-bugs mailing l
On Fri, Nov 12, 2010 at 9:29 PM, Tom Lane wrote:
> Jon Nelson writes:
>> I get this whenever debug_print_rewritten = on
>> WARNING: 01000: could not dump unrecognized node type: 928
>> LOCATION: _outNode, outfuncs.c:2787
>> right before
>> LOG: 0: rewr
I get this whenever debug_print_rewritten = on
WARNING: 01000: could not dump unrecognized node type: 928
LOCATION: _outNode, outfuncs.c:2787
right before
LOG: 0: rewritten parse tree:
PostgreSQL 8.4.5 on Linux x86-64
Does this sound familiar?
--
Jon
--
Sent via pgsql-bugs mailing li
On Tue, Nov 2, 2010 at 4:34 PM, Kevin Grittner
wrote:
> Jon Nelson wrote:
>
>> If I saw this behavior ( a.b also meaning b(a) ) in another SQL
>> engine, I would consider it a thoroughly unintuitive wart
>
> I think the main reason it has been kept is the converse -- if
On Fri, Oct 29, 2010 at 2:07 PM, Tom Lane wrote:
> [ please continue any further discussion in pgsql-bugs only ]
>
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> BTW this seems pretty far off-topic for pgsql-performance.
>
>> It is once you understand what's happening. It was probably the 11
The following bug has been logged online:
Bug reference: 5384
Logged by: Jon Nelson
Email address: jnel...@jamponi.net
PostgreSQL version: 8.4.2
Operating system: openSUSE 11.2
Description:pg_dump hard-codes use of /tmp
Details:
I was trying to dump a database
22 matches
Mail list logo
