The following bug has been logged on the website:
Bug reference: 8167
Logged by: Nelson Minar
Email address: nel...@monkey.org
PostgreSQL version: 9.2.4
Operating system: MacOS 10.8.3
Description:
This report and supporting files are available at
https
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
The following bug has been logged online:
Bug reference: 5431
Logged by: Evan Nelson
Email address: ean5...@gmail.com
PostgreSQL version: 8.4
Operating system: Ubuntu 9.10
Description:CREATE USER is not case sensitive, but psql command line
arguments are
Details
eta it since
I am porting more that million lines of code from Informix ESQL to
Postgres. I am not sure how to get the latest version since
I am new to the open source game.
Thanks.
Tim Nelson
---(end of broadcast)---
TIP 1: subscribe and unsubscr
;" in the first structure definition.
3. reverse the entries of the structure host variables.
Thanks again.
-Original Message-----
From: Tim Nelson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 09, 2002 8:26 AM
To: '[EMAIL PROTECTED]'
Subject: [BUGS] ecpg "aborts" on str
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
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
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 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 l
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
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 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 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
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 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
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 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
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, 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
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 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
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
ut of the box parameters that could
probably be tweaked for better performance but even then, Postgres is
kicking the pants out of MySQL. I'm very impressed - yall have a great
product!!
On Sat, Oct 15, 2011 at 6:33 PM, Alex Hunsaker wrote:
> On Sat, Oct 15, 2011 at 14:16,
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 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:
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
Thanks for the reply; glad it looks like a probable bug with a
straightforward fix.
FWIW, here's a discussion from last year that looks like people hitting the
same problem. Same mysterious EINVAL logged opening a file, on Macs. No
conclusion in that discussion.
http://comments.gmane.org/gmane.co
I've tested Tom Lane's fix, on 9.2.4 on my Mac, and it seems to have solved
the problem. Thanks!
https://github.com/postgres/postgres/commit/6563fb2b45146852601e63828308fe04fb03b9e9
The following bug has been logged online:
Bug reference: 5474
Logged by: Nelson da Silva
Email address: ndsfantas...@hotmail.com
PostgreSQL version: 8.0.2.1
Operating system: Windows XP
Description:Installation
Details:
An error ocurred executing the Microsoft VC
The following bug has been logged on the website:
Bug reference: 6341
Logged by: Nelson Marques
Email address: nelson-m-marq...@ext.ptinovacao.pt
PostgreSQL version: 8.4.10
Operating system: Red Hat Enterprise Linux 5
Description:
Hi all,
Currently your binary
sion.
I would also take this opportunity to express my sincere votes of a Merry
Christmas and a Happy Year to the developing team of PostgreSQL, all the
packagers and distributors and everyone else in the ecosystem.
Best Regards,
NM
Melhores cumprimentos,
Nelson M. Marques
__
of free software, if you don't like, we can always work it out
our own way.
I should've digged up more information before filing this report.
Thanks for your great work with PostgreSQL and Fedora/RH packaging.
BR,
NM
Melhores cumprimentos,
Nelson M. Marques
Qualquer versao que instalo da erro conforme abaixo :
An error ocurred executing the Microsoft VC++ runtime installer, poderiam me
dar uma dica de solução ?
Obrigado
_
DIVIRTA SEUS AMIGOS
34 matches
Mail list logo
