The following bug has been logged on the website:
Bug reference: 8465
Logged by: Jan Mate
Email address: jan.m...@inf-it.com
PostgreSQL version: 9.3.0
Operating system: all
Description:
Hi PostgreSQL team,
today I tried to upgrade from 9.2 to 9.3
The following bug has been logged on the website:
Bug reference: 7838
Logged by: Jan Mate
Email address: jan.m...@inf-it.com
PostgreSQL version: 9.2.2
Operating system: Debian GNU/Linux
Description:
Today I tried to upgrade from 9.1.7 to 9.2.2 by using
y to handle it sanely.
By the way, I agree that the caching in PL/Python (and PLs in general)
is ugly and ad hoc. Having to share memory management with the embedded
PL doesn't help, though.
Cheers,
Jan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Am 22.01.2013 14:47, schrieb Marc Balmer:
> no. Your syntax is wrong.
Well - it's not exactly 'my' syntax - see:
uuid-ossp--1.0.sql
uuid-ossp--unpackaged--1.0.sql
>> I had to replace the hyphen in file names and in the scripts to make the
>> module work.
>>
> That is the wrong "fix". The hyphe
The following bug has been logged on the website:
Bug reference: 7820
Logged by: Jan-Peter Seifert
Email address: jan-peter.seif...@gmx.de
PostgreSQL version: 9.1.7
Operating system: Windows 7 64-bit
Description:
The statement:
'CREATE EXTENSION uuid-ossp&#
That would be definitely much more comfortable solution.
Problem was really in newlines \n vs. \r\n. Replace \r\n -> \n solved
problem.
Thanks a lot.
2012/10/13 Craig Ringer
> On 10/10/2012 03:07 AM, Jan Vodička wrote:
>
>> = not able to unpack, invalid
>>
>>
Thanks. I've already looked. Problem was that Windows replaced '\n' to
'\r\n', replacing bytes back '\r\n' -> '\n' solved the problem. It was
working on 16GB gzip package.
It should be nice to mention this behavior somewhere.
Jan Vodicka
2012/10
e.
2012/10/9 Ryan Kelly
> On Tue, Oct 09, 2012 at 02:20:40PM +, hrt...@gmail.com wrote:
> > The following bug has been logged on the website:
> >
> > Bug reference: 7590
> > Logged by: Jan Vodička
> > Email address: hrt...@gmail.com
>
So is there any way how to get plain sql from this "corrupted" backup?
It would be nice to mention this behavior in manual.
2012/10/9 Tom Lane
> hrt...@gmail.com writes:
> > The following bug has been logged on the website:
> > Bug reference: 7590
> >
$-parameters for the prepared SPI plan. The parser rejects ordering by
non-integer constants, but it does not reject ordering by $-parameters
or constant expressions. (maybe it should). You can for example
SELECT * FROM something ORDER BY 'foo'||'bar';
Jan
--
Anyone wh
The following bug has been logged on the website:
Bug reference: 6722
Logged by: Jan-Peter Seifert
Email address: jan-peter.seif...@gmx.de
PostgreSQL version: 9.1.4
Operating system: Windows 7 Enterprise (64-bit)
Description:
Hello,
it seems that the debugger
The following bug has been logged online:
Bug reference: 6274
Logged by: Jan-Peter Seifert
Email address: jan-peter.seif...@gmx.de
PostgreSQL version: 9.1
Operating system: any
Description:documentation on pg_attribute.atttypmod
Details:
Hello,
it looks like that
Introduction
I wrote small java program which performs some selects in
one transaction (and thread) and one delete in another transaction and
thread on the same table holding one record initially.
ENVIRONMENT
OS:
Centos 5.5 kernel 2.6.18-194.32.1.el5
Postgresql: 9.0.4
jdbc driver:
9.0-801 JDBC
ne encoding for
locale "sv_SE.UTF8": codeset is "IBM-1208"
DETAIL: Please report this to .
WARNING: could not determine encoding for locale "sv_SE.UTF8": codeset is
"IBM-1208"
DETAIL: Please report this to .
ok
...
Med vänliga hälsningar / With kind regards /
On 3/28/2011 8:07 PM, Tom Lane wrote:
Jan Wieck writes:
I somehow fail to see how this complete reversal of who does what and
affecting code in entirely different parts of the system will qualify
for patching back releases.
I don't think any of the proposals make sense for back-pat
al of who does what and
affecting code in entirely different parts of the system will qualify
for patching back releases.
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To m
The following bug has been logged online:
Bug reference: 5878
Logged by: Jan-Peter Seifert
Email address: jan-peter.seif...@gmx.de
PostgreSQL version: 8.4.7
Operating system: Ubuntu 10.04 LTS
Description:BTREE_BUILD_STATS causes 'make check' to fail
Detail
The following bug has been logged online:
Bug reference: 5874
Logged by: Jan-Peter Seifert
Email address: jan-peter.seif...@gmx.de
PostgreSQL version: 8.4.7
Operating system: Windows 7 64-Bit
Description:pg_dumpall CREATE DATABASE statements 'missing'
The following bug has been logged online:
Bug reference: 5727
Logged by: Jan Kantert
Email address: jan-postg...@kantert.net
PostgreSQL version: 9.0.1
Operating system: Ubuntu 10.04 x86_64 2.6.32-22-server #33-Ubuntu SMP
x86_64 GNU/Linux
Description:Indexes broken in
On Sunday, June 13, 2010, Tom Lane wrote:
> "Jan Merka" writes:
> > After installing postgresql 8.4.4 from sources, I am getting an error
> > ERROR: cache lookup failed for function 2071
> >
> > Test case:
> >
> > SELECT date '2010-01-01&#
The following bug has been logged online:
Bug reference: 5504
Logged by: Jan Merka
Email address: me...@highsphere.net
PostgreSQL version: 8.4.4 and 8.4.3
Operating system: Linux
Description:cache lookup failed for function
Details:
After installing postgresql
version??
Thanks.
Maxi
(sory my english)
Try this link:
http://code.google.com/p/visionmap/wiki/psqlODBC
/Jan-Ivar
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 5086
Logged by: Pieter-Jan
Email address: pieter-jan.beck...@hotmail.com
PostgreSQL version: 8x
Operating system: Windows 7 professional
Description:Install doesnt work
Details:
When I try to install
Jan-Ivar Mellingen skrev:
> One of our customers discovered that by replacing <>TRUE with =FALSE in
> a query of a table containing 750.000 records reduced the query time
> from about 12 seconds to about 60 milliseconds!
>
> The problematic query looks like this:
> SELEC
I overlooking something?
This was verified on PostgreSQL 8.3.7, both on Windows Xp and Ubuntu 8.10.
Some relevant details from the table definition:
CREATE TABLE alarmlogg
(
id serial NOT NULL,
alarm_status character varying(1) DEFAULT ''::character varying,
logg_avsluttet boolea
The following bug has been logged online:
Bug reference: 4863
Logged by: Jan-Peter Seifert
Email address: jan-peter.seif...@gmx.de
PostgreSQL version: 8.4 RC1
Operating system: Windows
Description:postgresql.conf typo in log_line_prefix
Details:
log_line_prefix is
Tom Lane wrote:
Thank you very much for your quick reply. I wanted to do some testing
before reporting back.
> "Jan-Peter Seifert" writes:
>> there's a problem with renaming sequences in our databases.
>
> I don't think there's really a problem here
The following bug has been logged online:
Bug reference: 4582
Logged by: Jan-Peter Seifert
Email address: jan-peter.seif...@gmx.de
PostgreSQL version: 8.3.5
Operating system: Windows xp
Description:Renaming sequences and default value
Details:
Hello PostgreSQL-Team
The following bug has been logged online:
Bug reference: 4400
Logged by: Jan-Peter Seifert
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: Windows xp Professional
Description:initdb doesn't work with partition D:
Details:
The following bug has been logged online:
Bug reference: 4098
Logged by: Jan-Peter Seifert
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2
Operating system: Windows xp
Description:Encoding problems
Details:
The encoding of the source db/server is LATIN1
The following bug has been logged online:
Bug reference: 4019
Logged by: Jan Strube
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3
Operating system: openSUSE Linux 10.2
Description:Comparison of user defined domain doesn't work
Details:
Hi,
I think
The following bug has been logged online:
Bug reference: 3964
Logged by: Jan-Peter Seifert
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.0
Operating system: Windows xp sp2 German
Description:Parsing error in Stack Builder with LATIN1 client
encoding
The following bug has been logged online:
Bug reference: 3937
Logged by: Jan Mate
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.6
Operating system: Linux & Mac OS X
Description:timestamp null value comparison in subquery using IN/NOT
IN
Det
The following bug has been logged online:
Bug reference: 3882
Logged by: Jan Mate
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.6
Operating system: Linux and Mac OS X
Description:unexpected PARAM_SUBLINK ID
Details:
I am trying to create a row versioning
The following bug has been logged online:
Bug reference: 3868
Logged by: Jan Arne Hansen
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.6
Operating system: Windows Vista
Description:Unattended install fails
Details:
mkdir c:\postgres
msiexec /i postgresql
The following bug has been logged online:
Bug reference: 3320
Logged by: Jan Szumiec
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Windows XP
Description:Error when using INSERT...RETURNING as a subquery
Details:
Having:
CREATE TABLE
Below is the result of restoring specific tables from backup made by pgadmin using postgresql 8.1.4 for windows
Note: Same result also applies to linux distribution of postgresql 8.1.4
--
I am having problem with pg_restore 8.1.4
pg_restore: [custom archiver] out of memorypg_restore: *** aborted because of error
I got a field with a datatype of varchar(40) in one of my table
client_encoding = LATIN9
When I use COPY to transfer records to my table
I got an error message "Error: value too long for type character varying(40)"
When I check the offending record it seems that one of the character
in the fiel
This is the statement which having problem: select count(distinct empno) as counter1 from pay_master_history where empno in (select empno from pay_batch_basic_history whereorganizationid like '015003%')
and processyear = '2006' and processmonth = '05' and processbatc
The following bug has been logged online:
Bug reference: 2070
Logged by: Jan Jockusch
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.0
Operating system: Linux
Description:Encoding dependent error in comparison operators
Details:
With terminal encoding
er_ triggers get fired by the deferred queue after the
statement. The example deletes multiple rows in one statement.
Jan
--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let&
hat most of the
updates actually happen on wide rows. Otherwise, the percentage of dead
tuples in the main and toast table should be fairly similar.
Jan
--
#==#
# It's easier to get forgiveness for being wrong than
Hi,
I was wondering if the following issue is in fact a bug, or just
inconvenient behaviour...
say a table looks like this:
table
---
c (varchar)
'20'
'0'
'-10'
'klj'
'> 5'
'qwerty'
'< 6'
The query select * from table where c < 5 will return for instance the
tuple containing '20'.
In other
The following bug has been logged online:
Bug reference: 1702
Logged by: Jan Behrens
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: NetBSD
Description:Function returning nested composite types
Details:
Following input:
CREATE TYPE
The following bug has been logged online:
Bug reference: 1597
Logged by: Jan Behrens
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: Linux 2.4.29
Description:pg_dump --verbose ignores --disable-triggers
Details:
pg_dump -a --disable
e. This causes expressions having
side-effects, notably nextval(), potentially to obtain
differing values at each reference."
Anyhow, postgres (community) deserves at least my
gratitude for its consistency and coherence in
realisation. Thanks you for a quick answer. I will
look into the tr
es.
For details see the following artificial example
logging actions on "tbl" to "log" and using nextval as
an expression (code and output below). As a result the
columns tbl.id and log.id differ, unexpectedly, by
+-1.
regards, Jan
=== SQL
--
and output columns;
nevertheless, the loosening of the behaviour of "group by" doesn't seem
to sit with the restriction on "having". I also appreciate the need to
support "standard" sql - but in the absence of ambiguities, shouldn't
this expression "do wha
On 10/26/2004 6:13 PM, Bruce Momjian wrote:
I believe Slony always needs threading, it just can be used even if the
OS doesn't fully support all thread-safe functions, so on 8.0 you use
--thread_safety_force. Jan, is that correct?
Yes.
Slony allways uses pthreads and therefore it requires th
On 10/23/2004 10:08 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
On 10/22/2004 3:30 PM, Ed L. wrote:
Clean build of pgsql 7.4.5 on HPUX B.11.23 on ia64 with
--enable-thread-safety fails ... :(
Unfortunately that doesn't mean that the switch is required to cause
libp
test
if Slony works on HP-UX even if PostgreSQL is NOT configured with
--enable-thread-safety ?
Jan
Please report your platform threading info to the PostgreSQL mailing lists
so it can be added to the next release. Report all compile flags, link
flags,
functions, or libraries required for thre
er.
If it makes a difference if a pg_class page is dirty in the buffer or
copied out to disk with respect to visibility rules of the tuples
contained in it, then the whole thing is a way larger bug than the one
in MIB. First of all, committed or not, a temp object from one session
should NEVER be visib
produce this on my laptop nearly 90% of the time, but could only
reproduce it about 10% of the time on my production databases until I
figured out what the difference was, fsync.
temp tables don't use the shared buffer cache, how can
not match previous newline style
CONTEXT: COPY tmp_pg_description, line 1542: ""
initdb: failed
I use Cygwin version 1.5.9-1
What is the problem, and how does I solve this problem ?
My E-mail-address is: [EMAIL PROTECTED]
I hope to hear from you.
Best reg
POSTGRESQL BUG REPORT TEMPLATE
Your name : Jan Poslusny
Your email address : [EMAIL PROTECTED
l complain that lo-type already exists. in 7.2.3 i patched the
pg_restore code to continue, even if there were errors. and i needed this on different
occasions. would it be possible to include an "ignore-errors" flag to pg_restore?
i suspect this problem is due to the new &quo
would break other scenarios where the effects of one
action need to be visible in the next.
Jan
Dmitry Tkach wrote:
>
> Hi, everybody!
>
> I was wonderring if anyone could help me with this...
> I have created two tables and a view that joins them together, then I add a rule,
&g
On Sun, 2002-05-12 at 17:58, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > template1=> move -1 from foo;
> > MOVE 0
>
> Not sure what you expected this to do, but the response should have
> clued you that it didn't do anything. I suspect you are looking
> for "MOVE BACKWARD 1 FROM foo" ...
>
x27;);
> > FETCH ALL IN rs;
> > COMMIT;
>
> > I am getting this error after FETCH ALL
>
> > psql:errtest.sql:15: ERROR: MemoryContextAlloc: invalid request size
> > 2139062147
>
> Nasty. It looks like SPI_curs
POSTGRESQL BUG REPORT TEMPLATE
Your name : Jan Branbergen
Your email address : [EMAIL PROTECTED
Format df = new SimpleDateFormat("-MM-dd HH:mm:ss");
// Modification by Jan Thomae
String sub = s.substring(s.length() - 3, s.length()-2);
if (sub.equals("+") || sub.equals("-")) {
s = s.substring(0, s.length()-3) + "GMT"+ s.substring(s.length()
(1 row)
pgsql=# update t1 set a[1] = 'new', a[2] = 'Empty';
UPDATE 1
pgsql=# select * from t1;
a
---
{"new","bar"}
(1 row)
pgsql=# update t1 set a[1] = 'next', a[2] =
DROP TABLE implicitly drops referential ...
NOTICE message comes from. So I wonder how he got into that
state?
Jan
--
#==#
# It's easier to get forgiveness for being wrong than for being rig
e might have gotten there. And yes,
they need to either keep track of renamings or use OID's.
Jan
--
#==#
# It's easier to get forgiveness fo
Hi Tom,
I have recompiled postgres without -O2 and as far as I see
all works well now (incl. getattproperties ).
Jan
Tom Lane wrote:
> Jan Ehrhardt <[EMAIL PROTECTED]> writes:
> > Architecture (example: Intel Pentium) : SGI Octane SI (MIPS R1)
> > Operating S
POSTGRESQL BUG REPORT TEMPLATE
Your name : Jan Ehrhardt
Your email address : [EMAIL PROTECTED]
System
responding heap
tuples that controls which of them an index scan returns.
It is VACUUMs job to remove index tuples pointing to some
TID, VACUUM decided that it's no longer needed.
Jan
--
#=
will result in: "ERROR: master: Permission denied".
>
> This seems a bug to me ? Isn't it ?
Outch,
yes, we missed something here. Peter, you said you'll
probably work on the ACL stuff after 7.0. We need to
coordinate that work with th
means "delete from pg_class where relname='a'"
and then "delete from pg_type where typname='a'". Then execute vacuum,
which should, I think, synchronize indices. I tried it and it worked.
Don't you have anybody better solution?
Jan Urbanek
70 matches
Mail list logo
