The following bug has been logged on the website:
Bug reference: 8384
Logged by: Jon Barnhart
Email address: [email protected]
PostgreSQL version: 9.2.4
Operating system: Win 7 ultimate
Description:
pgsql/lib is missing libintl.dll so if you try to use libpq
: internal_flush, pqcomm.c:1108
642 STATEMENT: COPY ... to stdout;
it ran until I killed it.
--
Jon
--
Sent via pgsql-bugs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Wed, Apr 18, 2012 at 7:44 PM, Tom Lane wrote:
>
> [email protected] writes:
> > Issue: After adding one new column to each of two different tables, querying
> > pg_attribute shows the new column in one table but not the other.
>
> This is a bit hard to believe, and your log extract certainly
The following bug has been logged on the website:
Bug reference: 6601
Logged by: jon
Email address: [email protected]
PostgreSQL version: 8.4.7
Operating system: RedHat Enterprise Linux 6.2 (Linux version 2.6.32)
Description:
Not sure if this is a bug or not
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 ([email protected])
To make changes to your subscription:
http://ww
,
which is when you'd normally set a search_path on it (a dev
accidentally set it on a non-secdef function).
Thanks, and apologies for the false alarm.
/me slinks away sheepishly...
- --
Jon T Erdman (aka StuckMojo)
PostgreSQL Zealot
On 12/02/2011 12:27 AM, Tom Lane 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
The following bug has been logged online:
Bug reference: 6106
Logged by: Jon C.
Email address: [email protected]
PostgreSQL version: 9.0
Operating system: Win XP SP3
Description:JAR File has no source attachment
Details:
When running ExecSQL.java on my
The following bug has been logged online:
Bug reference: 6105
Logged by: Jon C.
Email address: [email protected]
PostgreSQL version: 9
Operating system: WinXP SP3
Description:Failed to load Main-Class manifest attribute
Details:
The following is displayed on
The following bug has been logged online:
Bug reference: 6107
Logged by: Jon C.
Email address: [email protected]
PostgreSQL version: 9.0
Operating system: Win XP SP3
Description:Invalid bug
Details:
Please accept my apologies for the most recent bug reported
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
RE foobar.column1 = baz.column1 AND table_date >= now() ;
rollback;
--
Jon
--
Sent via pgsql-bugs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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
ier to rename the attribute:
ALTER TABLE foo RENAME COLUMN bar TO baz;
psql shows the correct (new) name, 'baz'.
The SQL above shows the old name, 'bar'.
The database has not suffered any un-graceful shutdowns and shows no ill effect.
Is the SQL that SQLAlchemy is issuing wrong o
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
8k write, fsync, close 2535.765/second
8k write, close, fsync 2162.060/second
My interpretation of these values is that the drives themselves have
their write caches disabled.
Lastly, the problem has been reproduced on at least three totally
different machines.
--
Jon
.
If you are using glibc, this is expected/normal.
http://www.gnu.org/s/libc/manual/html_node/TZ-Variable.html
--
Jon
--
Sent via pgsql-bugs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 5827
Logged by: jon varona
Email address: [email protected]
PostgreSQL version: 9.0.2-1
Operating system: windows 7
Description:no consigo instalarlo
Details:
no puedo instalar el programa me pide una
;m on Linux x86_64, using postgresql 8.4.5.
--
Jon
--
Sent via pgsql-bugs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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
her a)
room for them is necessary in the LRU cache or, b) the server is shut
down. I probably have this wrong.
What can be done to remove all of the files associated with dropped
(temporary) tables _when_ the they are dropped?
I'm using 8.4.5.
--
Jon
--
Sent via pgsql-bugs mailing list (
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
issues
involving ANALYZE and even DROP function.
Is this the same root cause? Is there a fix? Is there a lock I could
take or some other approach that would prevent the error?
I thought all ALTER TABLE statements took a big fat lock to prevent
such an issue.
--
Jon
--
Sent via pgsql-bugs mailing
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
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
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
not (since frequently "types" are treated like functions in
many languages).
Therefore, I suggest that you bear these things in mind when
discussing or contemplating how the syntax should work - you probably
have many more people coming *to* postgresql from other languages than
you have use
The following bug has been logged online:
Bug reference: 5604
Logged by: Jon Erdman (aka StuckMojo)
Email address: [email protected]
PostgreSQL version: Tested 9.0, 8.3
Operating system: Ubuntu Lucid 10.04
Description:Setting NOT NULL on inherited column
The following bug has been logged online:
Bug reference: 5536
Logged by: Jon Strait
Email address: [email protected]
PostgreSQL version: 8.4.4
Operating system: Linux
Description:Disputing output for some Geometric types
Details:
Refering to Documentation
The following bug has been logged online:
Bug reference: 5384
Logged by: Jon Nelson
Email address: [email protected]
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
f partial archives these
missing deps wouldn't cause any worse failure than they otherwise would,
since they'd be just as missing if you did a normal restore vs. a
parallel one.
- --
Jon T Erdman (aka StuckMojo)
PostgreSQL Zealot
-BEGIN PGP SIGNATURE-
iEYEARECAAYFAktV/W
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> "Jon Erdman (aka StuckMojo)" writes:
>> So, I still run 7.4.5 for my medical billing app, and in playing around with
>> 8.5 at AustinPUG last week I discovered that if I try to restore one of my
>>
The following bug has been logged online:
Bug reference: 5288
Logged by: Jon Erdman (aka StuckMojo)
Email address: [email protected]
PostgreSQL version: 8.5devel, 8.4
Operating system: Debian Sid
Description:Restoring a 7.4.5 -Fc dump using -j 2 segfaults
3897 indicates this was a problem for 8.3RC3. Was this fixed in
the final release?
Jon
--
Sent via pgsql-bugs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
6..0.006 rows=0 loops=2)"
"Index Cond: (ag.jagpid = j.jobagentid)"
"-> Index Scan using pga_jobclass_pkey on pga_jobclass cl
(cost=0.00..0.75 rows=1 width=22) (actual time=0.016..0.020 rows=1 loops=2)"
" Index Cond: (cl.jclid
t be different when we have
several hundred jobs.
The cost is significantly lower but the total runtime is higher. This is on
a PostgreSQL database installed on my desktop. It has nothing to do with
Greenplum. I can't even run an explain plan on GP with that first query
because it fails.
-> Index Scan using pga_job_pkey on pga_job j
(cost=0.00..8.27 rows=1 width=141)"
" Index Cond: (sub.jlgjobid = j.jobid)"
" -> Index Scan using pga_jobagent_pkey on pga_jobagent ag
(cost=0.00..0.37 rows=1 width=44)"
"
The following bug has been logged online:
Bug reference: 3667
Logged by: Jon Roberts
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2
Operating system: Solaris
Description:Job scheduling with Greenplum fails
Details:
Greenplum doesn't support "
nted:
select cast(30 as real) / 50;
select cast(30 as numeric) / 50;
select 30::real / 50;
select 30 / 50::float;
As well as any other variations along that theme.
-Jon
--
Senior Systems Developer
Media Matters for America
http://mediamatters.org/
---(
The following bug has been logged online:
Bug reference: 2556
Logged by: Jon Watte
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.3
Operating system: Linux 2.4
Description:ODBC driver version 2.00 doesn't publish functions
correctly
Details:
Def
ot;. I then restored my DB and it worked fine.
I find it strange that it won't search Japanese strings with a locale of
Japanese... which it defaulted to doing during the Win32 Installer.
Anyways, it would be nice to have it as an option or something. If it is
there and I didn't see it.. s
The following bug has been logged online:
Bug reference: 2116
Logged by: Jon Keating
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.1
Operating system: Win 2003
Description:Searching text fields does not work in EUC_JP
Details:
Hello, I found a problem
The following bug has been logged online:
Bug reference: 1779
Logged by: Jon Rylands
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: Windows XP SP2
Description:psql.exe doesn't promt for password yet password
authentication fails
De
this all about?
Jon Wheatland
Enterprise Information Solutions, Inc.
4910 Main St., Downers Grove, IL 60515
Office: 630.512.0570 - Fax: 630.512.0568 - Mobile: 630.330.3839
ce we can't see anything until we kill the
process. then what it remembers gets dumped to the error log.
Jon Pastore RHCE, President IDE Tech,
Inc. (954) 360-0393 Office (954) 428-0442 Fax Public Key: http://www.idetech.net/keys/jpastore.asc
other
>users accessing the database (readers or writers).
>
>
> ------
> -
>
> [EMAIL PROTECTED] wrote:
> > Jon Watte ([EMAIL PROTECTED]) reports a bug
> > with a severity of 2 The low
list about 2 weeks ago about
you writing a performance tuning document and putting it up on the
website. Did this happen and I miss it, or is it still in the works?
Thanks,
Jon Poland
On Thu, 3 May 2001, Bruce Momjian wrote:
>
> Can you give me a few sample lines that you are seeing
Hi,
I'm not using pg_ctl, I'm using postmaster directly. So, in my case I
tried passing "-d0" to it, but it had no effect. Command line:
postmaster -i -d0 -D /var/pgsql/data -c syslog=2
Any ideas? I could patch the code to remove the excessive elog's in the
vacuum command, but I'd rather
50 matches
Mail list logo
