ust escaped when serialized
>> to XML. If were to actually contain "<", it'd be serialized as
>> "<". It should not be possible to be blindly cast to a text type, but
>> explicitly serialized as such.
>>
>>
>> At least the rev
The following bug has been logged on the website:
Bug reference: 8130
Logged by: Stefan de Konink
Email address: ste...@konink.de
PostgreSQL version: 9.2.4
Operating system: Linux
Description:
We figured out that two very close query give a massive difference
t=Statement.SUCCESS_NO_INFO;
}
try {
if (status.startsWith("INSERT"))
insert_oid = Long.parseLong(status.substring(1 +
status.indexOf(' '),
status.lastIndexOf(' &#
One thought:
What about returning Statement.SUCCESS_NO_INFO as it says in
http://docs.oracle.com/javase/6/docs/api/java/sql/BatchUpdateException.html#getUpdateCounts%28%29
and
http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#executeBatch%28%29
?
It seems better to report no numb
dea about the jdbc/java stuff but either you need to move to
a more recent version of the jdc driver your you need to change the
bytea_output guc to 'escape'.
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Am 25.09.2012 18:08, schrieb Tom Lane:
s.pro...@pharmatechnik.de writes:
The following bug has been logged on the website:
Bug reference: 7567
Logged by: Stefan Pröls
Email address: s.pro...@pharmatechnik.de
PostgreSQL version: 9.1.3
Operating system: OpenSUSE 11.4 32-Bit
The following bug has been logged on the website:
Bug reference: 7566
Logged by: Stefan Pröls
Email address: stefan.pro...@pharmatechnik.de
PostgreSQL version: 9.1.3
Operating system: OpenSUSE 11.4 32-Bit
Description:
Scenario:
1 Master, 1 Hot-Standby Slave
The following bug has been logged on the website:
Bug reference: 7509
Logged by: Stefan de Konink
Email address: ste...@konink.de
PostgreSQL version: 9.1.5
Operating system: Linux
Description:
The following is relatively fast:
bag-2012-aug=# explain select count
On 01/27/2012 07:06 PM, Marko Kreen wrote:
> On Fri, Jan 27, 2012 at 8:00 PM, Magnus Hagander wrote:
>> On Fri, Jan 27, 2012 at 18:54, Marko Kreen wrote:
>>> On Fri, Jan 27, 2012 at 7:34 PM, Stefan Kaltenbrunner
>>> wrote:
>>>> On 01/27/2012 04:20 PM,
On 01/27/2012 04:20 PM, Marko Kreen wrote:
> On Fri, Jan 27, 2012 at 01:37:11AM -0500, Tom Lane wrote:
>> Stefan Kaltenbrunner writes:
>>> from some looking at the code in pgcrypto.c it seems to me that the
>>> coding pattern in most functions there only
On 01/23/2012 08:40 PM, Stefan Kaltenbrunner wrote:
> We are using the raw decryption features of contrib/pgcrypto here to
> decode certain AES128 encrypted data. However depending on the data to
> decode and what statements have been executed in the same session before
> we are seei
27;aes-cbc/pad:none') from (select
decode('c89a929fa8dbefaa88609ea3b637d783ce926b8a0985ae02a100c0f89d8a8e5aca793d1519f5829a61b9fbd1d582fb66ff','hex')::bytea
as data, decode('636F6E73756D6572326772696430','hex')::bytea as key,
decode('2D4C526240141e029696969696969696','hex')::bytea as iv) as c;
decrypt_iv
-
/lib/postgresql/8.3/lib/pgcrypto.so\000\012\000\000\000\200\000\000\000\000\000\000\000\000
(1 row)
which seems even more of a "wtf"?!
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
as extensions and that
you are supposed to use "CREATE EXTENSION intarray;" on the SQL level
instead of manually loading sql-scripts through psql.
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
.org/projects/psqlodbc/
regards
Stefan
>
> Regards
>
> Heimo Stieg
>
>
>
> *Von:* STIEG Heimo
> *Gesendet:* Montag, 10. Oktober 2011 23:11
> *An:* robertmh...@gmail.com
> *Cc:* pgsql-bugs@postgresql.org
> *Betreff:* AW:Re: [BUGS] BUG #6247: Freeswitch will
The following bug has been logged online:
Bug reference: 6241
Logged by: Stefan Franke
Email address: ste...@franke.ms
PostgreSQL version: 9.1
Operating system: any
Description:JDBC: blob doesnot work with bytea
Details:
To persist a blob you can also use bytea
nning on the default port (say 5432 is production
and 4329 is development) and you end up issuing the wrong commands.
If we provide "automatic reconnect" we should rather do that correctly
or not at all...
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
en issues on freebsd in the past with libraries there
being compiled with threading support which caused them to get
ridiculous low stack limits.
Maybe it would be worth trying to recompile the libxml port without
threading support (if that is an option).
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
imits(especially
on 32bit boxes).
We really need to look into reducing that or putting a more prominent
"don't use bytea for anything larger than say 50MByte)
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www
QL-Standard (see
http://www.postgresql.org/docs/9.0/static/sql-keywords-appendix.html) so
you would have to quote the keyword like:
create table ftp ("user" varchar, password varchar);
in your code - but I would advise against using reserved words at all
because you will end up having
that's the on-disk size of the
table (maybe even including indexes) it is entirely believable that the
amount of data transfered through COPY on the SSL-session was much less
than 512MB.
Given the symthoms reported I would agree with Alex on suspecting a
broken openssl library.
S
On 07/23/2010 07:24 PM, Stefan Kaltenbrunner wrote:
On 07/22/2010 07:51 PM, Denise Kanyuh wrote:
Alex,
Yes -- I am aware that we are on an old release --
any plans to upgrade?
when you say - my hunch is
they do not ship binaries for AIX (7.1).
what binaries are you taking about --- we
buildfarm support on different AIX
versions, that would help you and the community in supporting AIX.
regards
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
r the table definitions, one
for the data and one for all the constraints and indexes. So basically
what pg_dump is currently doing anyway but just exposed as flags.
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresq
Stephen Frost wrote:
* Magnus Hagander (mag...@hagander.net) wrote:
On Thu, Jun 10, 2010 at 15:35, Stefan Kaltenbrunner
wrote:
that will pretty much defeat the purpose for most use cases i guess because
people will dump with the defaults and only discover the problem after the
fact.
Well, if
Robert Haas wrote:
On Thu, Jun 10, 2010 at 9:35 AM, Stefan Kaltenbrunner
wrote:
I do agree that the human readability of pg_dump is an asset in many
situations - I have often dumped out the DDL for particular objects
just to look at it, for example. However, I emphatically do NOT agree
that
Robert Haas wrote:
On Thu, Jun 10, 2010 at 9:02 AM, Stefan Kaltenbrunner
wrote:
I for myself would be rather annoyed if we started quoting all column names
in our dumps. This is seriously hampering readability and while it is
already annoying that pg_dump output is slightly different from the
used this would make it far worse.
I'm also not convinced that this is a good idea at all, using keywords
like that is always an issue and forward portability of dumps in general
is imho a pipe dream
BTW: mysql does a far better job here.
not sure I agree here but well...
Stefan
--
Sent
ssion.
yeah - I don't think pgbouncer would cause that behaviour on its own
given the provided information so I would kinda suspect that the update
was in fact never commited though that is not what the OP saw...
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
nd you are really sure that the update got commited in the
end(even if you got the "UPDATE 153" it should have been rollbacked as
soon as the connection got dropped)?
If yes I'm puzzled as well on what happened here.
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql
On 05/21/2010 12:03 PM, Jakub Ouhrabka wrote:
> Hi Stefan,
>
> thanks - but I don't understand how could the BEGIN; UPDATE xxx; be
> committed to database without explicit COMMIT and how could psql report
> "UPDATE 153" after message "The connection was reset&
d the backend stays alive
3. psql notices the lost connection and reconnects and you end up on
another backend session (or the same one that was just RESET ALL; by
pgbouncer after the UPDATE completed)
4. the ROLLBACK; does nothing because the pooled connection you are now
connected is either a different one
Thank you for the replay.
I will follow your advice. First will upgrade to 8.4 (or at least to the
latest 8.3 release), than will try to reproduce the error.
For now I will stick to using VACUUM FULL and REINDEX.
Thanks again.
Best Regards
Stefan Kirchev
On Mon, Apr 26, 2010 at 5:06 PM, Kevin
The following bug has been logged online:
Bug reference: 5439
Logged by: Stefan Kirchev
Email address: stefan.kirc...@gmail.com
PostgreSQL version: 8.3.3
Operating system: Linux
Description:Table crash after CLUSTER command
Details:
Hello,
I order to keep good
y had a dashboard or an email interface
(think of the buildfarm dashboard and the status email reports it
provides to both developers and animalowners) to make the issue more
visible I think most of the problem of "no reply at all" would (mostly)
"solve" itself.
Stefan
--
he workflow we want) is
probably not even a lot of work, but we could also use an existing
solution just as the backend engine and do the frontends ourselfs.
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Robert Haas wrote:
On Sun, Apr 11, 2010 at 7:14 AM, Stefan Kaltenbrunner
wrote:
Jasen Betts wrote:
On 2010-04-10, Stefan Kaltenbrunner wrote:
Craig Ringer wrote:
Dave Page wrote:
This basically indicates that we need an issue tracker. There, look -
now see what you made me do :-(
Please
Jasen Betts wrote:
On 2010-04-10, Stefan Kaltenbrunner wrote:
Craig Ringer wrote:
Dave Page wrote:
This basically indicates that we need an issue tracker. There, look -
now see what you made me do :-(
Please?!?
I wonder, if EDB just went ahead and set one up, would people start
using it
the lists,
what tool we should use and "do we even want one". There are tons of
discussions on that very topic in the archives (and also in the wiki).
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
release notes:
http://www.postgresql.org/docs/current/static/release.html
so if you for example want to upgrade from 8.4.1 to 8.4.3 you would
simply read the release notes for 8.4.2 and 8.4.3.
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
s should not be reported
here; please report to those projects directly. For products
closely connected with PostgreSQL, there may be an appropriate mailing list available.
updated the website with that wording - should be up on the next site
reload.
Stefan
--
Sent via pgsql-bugs mailing l
Alvaro Herrera wrote:
Stefan Kaltenbrunner escribió:
hmm - not sure that is too clear especially because I don't think
ther is only JDBC/ODBC or pgadmin (nor do I think you names match up
with how they are really called). what about doing it the other way
round like:
"This bug repor
L database, for problems with database connectors,
graphical administration tools or other external projects please report
to them directly. Alternatively you can look at the available href='/community/lists'>mailing lists and see if there is a more
apropriate list available."
of postgresql (or PLs
that require it) against libc_r causing some rather small stack limits
being imposed under some circumstances but I don't recall the details
any more...
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Sergey Konoplev wrote:
On Mon, Nov 2, 2009 at 8:25 PM, Stefan Kaltenbrunner
wrote:
Sergey Konoplev wrote:
Thanx, Tom.
So I just need to checkout REL8_4_STABLE and install it to fix my
problem, right?
that should work if it is indeed the same issue.
What if I apply this patch to 8.4.1
Sergey Konoplev wrote:
Thanx, Tom.
So I just need to checkout REL8_4_STABLE and install it to fix my
problem, right?
that should work if it is indeed the same issue.
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
Greg Stark wrote:
On Fri, Oct 30, 2009 at 11:22 AM, Stefan Kaltenbrunner
wrote:
ok I now see why you (and I) failed to reproduce the problem - it only
causes clusters/databases to crash that were actually generated using the
upthread mentioned script. it does NOT fail using a dump generated by
Stefan Kaltenbrunner wrote:
Tom Lane wrote:
Stefan Kaltenbrunner writes:
this is 8.5a2 configured with ./configure --enable-cassert
--enable-debug and just default settings(ie plain initdb with
default settings).
The OS is Debian Lenny/AMD64.
Huh. That should not be noticeably different
Tom Lane wrote:
Stefan Kaltenbrunner writes:
this is 8.5a2 configured with ./configure --enable-cassert
--enable-debug and just default settings(ie plain initdb with default
settings).
The OS is Debian Lenny/AMD64.
Huh. That should not be noticeably different from my F11/Xeon64
machine
:
Details:
I sent the following email:
pgsql-b...@postgres.org is not the same as pgsql-bugs@postgresql.org :)
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Tom Lane wrote:
Stefan Kaltenbrunner writes:
uploaded a dump of the dataset here:
http://www.kaltenbrunner.cc/files/rand_gen_data.sql
and the query that causes the segfault:
http://www.kaltenbrunner.cc/files/rand_gen_query.sql
[ scratches head... ] Still no crash here, and I tried it on a
Tom Lane wrote:
Stefan Kaltenbrunner writes:
I can easily reproduce the segfault on 8.4 and 8.5a2:
Doesn't crash here ... could we see the specific test data being used,
please?
uploaded a dump of the dataset here:
http://www.kaltenbrunner.cc/files/rand_gen_data.sql
and the query
ind") at postgres.c:3573
#8 0x082499be in ServerLoop () at postmaster.c:3366
#9 0x0824a9db in PostmasterMain (argc=3, argv=0x86d5a98) at
postmaster.c:1064
#10 0x081ea466 in main (argc=3, argv=0x86d5a98) at main.c:188
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
--On 27. September 2009 14:36:45 -0400 Robert Haas
wrote:
On Sun, Sep 27, 2009 at 11:36 AM, Tom Lane wrote:
Robert Haas writes:
On Sat, Sep 26, 2009 at 12:35 PM, Tom Lane wrote:
Well, yeah. That's exactly how it's documented to work: an ON INSERT
rule is executed after the INSERT pro
The following bug has been logged online:
Bug reference: 5081
Logged by: Stefan
Email address: s...@drbott.de
PostgreSQL version: 8.3.7
Operating system: FreeBSD 7.2
Description:ON INSERT rule does not work correctly
Details:
I'm trying to impleme
at maven or an
"artifact" I would be stillf confused as to what you consider a bug here.
The official website for the JDBC driver is http://jdbc.postgresql.org/
with downloads at http://jdbc.postgresql.org/download.html.
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@post
ile system backup or from a dump
generated by pg_dump?
Stefan
--
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: 4930
Logged by: Stefan Kirchev
Email address: stefan.kirc...@gmail.com
PostgreSQL version: 8.3.3
Operating system: Linux
Description:Missing attributes
Details:
One of the tables failed to drop and now it
t to text first.
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
on current head.
Sepcifically:
git clone up to and including the on liner patch by you:
86a4abb3a187bf2cc548aedd58125274ac724b1c
Tweak distribute_qual_to_rels so that when we decide a pseudoconstant ...
and cannot reproduce the failure anymore in this version. :)
Thanks for the timely investigation of
On Wed, May 06, 2009 at 01:26:05PM -0400, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
> > Tom Lane wrote:
> Oh! What is happening is that to_number(1) is being reduced to constant
> NULL, whereupon it concludes that ad_tab_id=to_number(1) is constant
> NULL, ergo the EXISTS
Tom Lane wrote:
Stefan Kaltenbrunner writes:
Tom Lane wrote:
Thank you for the report, but I do not see any problem when trying the
test case here. Do you have any nondefault planner parameter settings?
hmm weird - the testcase crashes for me as well on 8.4B1:
I was trying it on HEAD
On Wed, May 06, 2009 at 10:33:11AM -0400, Tom Lane wrote:
> Stefan Huehner writes:
> > I noticed the following bug when testing an application (openbravo 2.40) on
> > postgresql 8.4:
>
> Thank you for the report, but I do not see any problem when trying the
> test cas
Tom Lane wrote:
Stefan Huehner writes:
I noticed the following bug when testing an application (openbravo 2.40) on
postgresql 8.4:
Thank you for the report, but I do not see any problem when trying the
test case here. Do you have any nondefault planner parameter settings?
hmm weird - the
did have to_number(?) via jdbc-preparedstatement and
passing the parameter via setString, thus using the to_number(text) function.
But the same assertion does also happen with the query shown above..
Feel free to ask for any more needed information.
Regards,
Stefan
--
-- PostgreSQL database
tting statistics to >
1000 is "new" in 8.4...
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
toward a successful compiling of the database.
If you really need to build from source you should look at:
http://www.postgresql.org/docs/8.3/static/install-win32.html
however I would recommend you install postgresql using the binary
installer on windows.
Stefan
--
Sent via pgsql-bugs mailing
maximum limit of allowed clients
set in postgresql.conf.
If you want to create more connections increase the max_connections
variable or look into connection pooling.
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
s=0x84bf6ac, allParameterTypes=0, parameterModes=0,
parameterNames=0, proconfig=0, procost=1, prorows=0)
at pg_proc.c:413
#12 0x0814c014 in CreateFunction (stmt=0x8486068) at functioncmds.c:785
#13 0x08234e3a in PortalRunUtility (portal=0x84b6a0c,
utilityStmt=0x8486068, isTopLevel=1 '\00
The following bug has been logged online:
Bug reference: 4603
Logged by: Stefan Hoffmann
Email address: hof...@maxinf.de
PostgreSQL version: 7.4
Operating system: ubuntu linux server
Description:float4 error
Details:
some specific values such as 20048223 or
Perhaps the v4 generation method would work better for you?
actually this has been reported before and seems to be an issue in the
windows port of the ossp-uuid library:
http://archives.postgresql.org/pgsql-bugs/2008-05/msg00059.php
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs
you should ask them ...
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
sorts and running the box temporary out of diskspace.
Stefan
--
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: 3925
Logged by: Stefan Kunick
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3RC2
Operating system: Windows Longhorn
Description:You can delete enum elements from pg_enum, but it is
used in a table
The following bug has been logged online:
Bug reference: 3924
Logged by: Stefan Kunick
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3RC2
Operating system: Windows Longhorn
Description:Create Database with another encoding as the encoding
from postgres
also:
http://www.postgresql.org/docs/current/interactive/supported-platforms.html
which might need some updating ...
Stefan
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
[RESENDING because the attachments seems to have caused the mail to
disappear]
Oleg Kharin wrote:
Hi, Stefan
Hi Oleg!
I have readded the list and the testcases to the CC so that others can
participate in the discussion too ...
init826.sql builds necessary tables and indexes. The test
e bug report form.
you can simply reply to this mail and attach a testcase or post it on a
website for download - but we will definitly need a testcase for that ...
Stefan
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please se
.. it seem
jdbc.postgresql.org is down
works fine for me - what exact problem do you see ?
Stefan
---(end of broadcast)---
TIP 6: explain analyze is your friend
y forbid renaming indexes that are part of a constraint like that
and hint towards ALTER TABLE ADD/DROP CONSTRAINT ?
Stefan
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-noma
Diego Spano wrote:
Stefan / List, these are the steps:
1- pg_dump sicoba|gzip>/home/backups/pg_backup/backup.pg
2- createdb sicoba6
3- psql -d sicoba6 < backup.pg
And thats all.
Errors appear when trying to add rows to first table, and so on...
Find attached backup.pg.
ok just
Diego Spano wrote:
Hi Stefan,
Hi Diego!
Please keep the list CC'd so that other people can participate in the
discussion - I have readded it now ...
I test all possibilities, schema and data togheter, separated files, tar
files, plain text, from command line, from PG_Admin. But al
y dump or seperate schema/data dumps which obviously
cannot provide those guarantees.
regards
Stefan
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
to some of the contrib modules provided with
the main tarball:
http://www.postgresql.org/docs/8.3/static/pgtrgm.html
http://www.postgresql.org/docs/8.3/static/fuzzystrmatch.html
Stefan
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
ORDER BY.
That this works in other RDBMS is an artefact of their implementation
and you should probably not rely on that (and keep in mind that
clustering is a on-time operation in postgresql so modifications to the
table will change the ordering again)
Stefan
---(end
th in general and
especially on win32) and will very soon be unsupported on that platform:
http://archives.postgresql.org/pgsql-announce/2007-09/msg00010.php
Stefan
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by do
park of the default setting for
autovacuum_freeze_max_age (200M). So if you say had a 30% increase in
transactions on that day it could easily explain why autovacuum started
automatically (or something prevented the former vacuum from doing its
work).
Stefan
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Feng Chen wrote:
> VERSION = PostgreSQL 8.1.2
this could be
http://archives.postgresql.org/pgsql-committers/2006-01/msg00287.php
which is fixed in 8.1.3 and later - so you really should look into
upgrading to 8.1.9 as soon as possible ,,,
Stefan
---(end of broadc
-13T10:12:15+00:00 DETAIL: could not create file
> "pg_subtrans/0201": File exists
what version of postgresql is this exactly ? there is a problem in older
8.1 versions that could cause this error under high transaction rates.
Stefan
---(end of broadcast)---
TIP 6: explain analyze is your friend
just fine.
Stefan
---(end of broadcast)---
TIP 6: explain analyze is your friend
[adding -bugs back again]
Dmitry Dmitriev wrote:
Stefan,
We have checked the new ODBC driver V08.02.04.02 with expanded number of
connection.
But now we have got the new problem. The PostgreSQL server unexpected
crashes when number of opened connections reach about 160.
We checked it through
[added -bugs back to the CC]
Dmitry Dmitriev wrote:
> Stefan,
>
> Thank you for quick response.
> I guess that this problem with ODBC driver.
> The following file fragment psqlodbc.h from official PostgreSQL web site:
> http://wwwmaster.postgresql.org/download/mirror
lear to me if you are complaing about a problem in the ODBC
driver or postgresql. postgresql itself will limit the amount of
connections it can accept to the value of max_connections in
postgresql.conf. Maybe you could tell us a bit more about the actual
error your are getting ?
Stefan
-
on host "192.168.1.98" and accepting
> TCP/IP connections on port 5432?
well "no route to host" is a network level problem - either you client
is not connected (physically or logically) to that network at all - your
you have a firewall on either the client or the ser
tgresql.org/docs/current/static/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING
- example 37-1
the actual "standard" way to do that is by using MERGE with afaik
neither MySQL nor SQLite implement - but the correct solution is
documented and not really difficult to find.
Stefan
---
ng here - what kind of "clustering"
are you talking about ?
Stefan
---(end of broadcast)---
TIP 6: explain analyze is your friend
ll get improved (through plan invalidation) in the upcoming
8.3 release of postgresql too in a way that will not require the EXECUTE
workaround any more.
Stefan
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating
The following bug has been logged online:
Bug reference: 3223
Logged by: Stefan Kaltenbrunner
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.8
Operating system: FreeBSD 6.2STABLE
Description:Testbugreport for new wwwmaster
Details:
testing the bugreport
ql console.
> Shouldn't PostgreSQL inform someway why it's not going to insert that row?
well you have not show us the source of the trigger and tables involved
but most likely your (BEFORE?) trigger is actively suppressing the
insert of the row. And an insert that is not actually ins
resql service(from that error message I
assume you are running windows) is actually running and configured to
listen on that interface (it should be by default but somebody might
have changed that.
Another possibility would be some kind of firewall that is blocking the
request - if you ha
i read
http://jdbc.postgresql.org/download.html correctly pg74.216.jdbc3 is not
the version that should be used against a 8.1 backend.
Stefan
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
1 - 100 of 122 matches
Mail list logo
