The following bug has been logged online:
Bug reference: 1450
Logged by: Dirk
Email address: [EMAIL PROTECTED]
PostgreSQL version: ?
Operating system: Qnx
Description:unknown symbols
Details:
Hi,
I try to resolv some test on an qnx based system, but there is
with
. This is on 7.0 on Linux 2.2.10. I can't get more
about this error but I definately can not dump the db. Though the
migration from 6.5.3 to 7.0 went smooth.
Any suggestions?
Dirk
?
Regards,
Dirk
Dirk Lutzebaeck writes:
> ERROR: btree: index item size 3048 exceeds maximum 2717
>
> This is on 7.0.2 while doing an INSERT. The INSERT aborts and returns
> this error. It just occurred now for the first time and now everytime.
> There are several indexes defined on this
these messages before. I have
compiled the source on my own (egcs 2.91.66).
Can I downgrade from 7.0.3 to 7.0.2 without dump/restore?
Dirk
Tom Lane writes:
> Dirk Lutzebaeck <[EMAIL PROTECTED]> writes:
> > I observe occasionaly crashes on 7.0.3 under medium load:
>
> > Backend message type 0x49 arrived while idle
> > Backend message type 0x44 arrived while idle
> > Backend message typ
Tom Lane writes:
> Dirk Lutzebaeck <[EMAIL PROTECTED]> writes:
> > It may be that there is some kernel corruption appearing here. I'm
> > using kernel nfs on Linux 2.2.10 with a Solaris8 i86pc client. I saw
> > some weird NFS error messages on the Linux syst
I tried to do an INSERT using
> > SELECT ... ORDER BY:
> >
> > ERROR: ORDER BY is not allowed in INSERT/SELECT
Is 7.1 able to do INSERT/SELECT with ORDER BY and LIMIT ?
Dirk
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
table in the application. No
indexes were defined for this table.
I cannot get either run vacuum nor pg_dump with success.
Is there any insight to this? I looked up the email archives but could
find a way to get rid of this problem.
Dirk
---(end of broadcast)
Tom Lane writes:
> Dirk Lutzebaeck <[EMAIL PROTECTED]> writes:
> > Hi, I have the follow problem when vacuum'ing on 7.1.3:
> > ERROR: cannot find attribute 1 of relation docmatchsel
> > Then I tried to reindex the table in standalone mode which gives:
> &
create a table that already exists it should return the correct error. ( same for an index, etc... )
Regards,
Dirk Jacobs
the global OID
counter stayed at 40.000 so OIDs will be allocated again!
Thanks for help,
Dirk
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
This is not a large object. We are seeing rows with duplicate oids
because the OID counter is not changed after the dump (exported with
--oids) is being loaded.
How does 8.1 prevent to allocate duplicate OIDs?
Regards,
Dirk
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]>
True.
Dirk
Tom Lane wrote:
=?ISO-8859-1?Q?Dirk_Lutzeb=E4ck?= <[EMAIL PROTECTED]> writes:
This is not a large object. We are seeing rows with duplicate oids
because the OID counter is not changed after the dump (exported with
--oids) is being loaded.
How does 8.1 prev
ize(1784, 6012, '1923328-8-0-0');
NOTICE: ("Seq Scan on c (cost=0.00..344372.82 rows=1 width=164)")
NOTICE: (" Filter: ((code = $2) AND (voi = $3) AND (val1 IS NULL))")
setsize
-
0
(1 row)
Bummer, a sequential scan is being run.
Any clues? Has this behaviour changed for a while?
Regards,
Dirk
the minor
8.1 releases.
In any case I would see this as a security problem because you cannot
control sql code injection easily (as with using DBD::Pg) if you have
to pass parameters in the SQL string to use partial indexes.
Regards,
Dirk
Simon Riggs wrote:
On Mon, 2006-07-10 at 12:22 +0200, D
Ok, we checked our client code to eliminate this problem. Thanks for
the doc patch.
Regards,
Dirk
Simon Riggs wrote:
On Mon, 2006-07-10 at 13:35 +0200, Dirk Lutzebäck wrote:
In any case I would see this as a security problem because you cannot
control sql code injection easily
The following bug has been logged online:
Bug reference: 3516
Logged by: Dirk Tilger
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Linux with Intel compiler on ia64
Description:Incomplete #ifdef statement in s_lock.h
Details:
I have
On Sun, Aug 05, 2007 at 11:20:18AM -0400, Tom Lane wrote:
> "Dirk Tilger" <[EMAIL PROTECTED]> writes:
> > Operating system: Linux with Intel compiler on ia64
>
> > I have been compiling postgresql 8.0, 8.1 and 8.2.4 with the Intel compiler
> > in the pas
The following bug has been logged online:
Bug reference: 3693
Logged by: Dirk Moebius
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Windows 2000
Description:PSQLException when using ResultSet.getLong(String) in
turkish locale
Details
Hi,
I try to resolv some test on an qnx based system,
but there is
with every command I use an unknown symbol :
wcwidth
The postgresql system could not resolv all
symbols.
The installation is made from the standard
repository used on qnx.
greetings
I've also come across this in 7.4. You could also use:
SELECT NULL AS Test
UNION ALL SELECT NULL::int
UNION ALL SELECT 0
Dirk
Tom Lane wrote:
"" <[EMAIL PROTECTED]> writes:
The following query should not raise an error ("ERROR: UNION types text and
integer cannot be
The following bug has been logged online:
Bug reference: 1563
Logged by: Dirk Raetzel
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2
(mingw-special)
Description:wrong week returnded by
The following bug has been logged online:
Bug reference: 1647
Logged by: Dirk Bade
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: SUSE LINUX 7.3
Description:shows version 7.1, doesnt create tablespaces etc.
Details:
postgresql-8.0.1
The following bug has been logged online:
Bug reference: 1774
Logged by: Dirk Jagdmann
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: i686 Linux 2.6
Description:ecpg preprocessor produces a wrong varchar struct
Details:
The ecpg
The following bug has been logged online:
Bug reference: 1975
Logged by: Dirk Pirschel
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.4
Operating system: AIX
Description:Postgres 8.0.4 build fails on AIX
Details:
Postgres 8.0.4 build fails on AIX.
$cd
Hi,
I get the following error when I call:
# pg_dump db
pg_dump: schema with OID 559701082 does not exist
this happens with 8.0.1 on RHEL 3.0. I cannot dump the database neither
with --schema-only or --data-only.
What can I do?
Thanks for help,
Dirk
---(end of
Yes, I think so. What search path do you mean? These tables were all
temporary tables.
Dirk
Tom Lane wrote:
=?ISO-8859-1?Q?Dirk_Lutzeb=E4ck?= <[EMAIL PROTECTED]> writes:
The problem I'm facing is the following:
cs1=# select relname from pg_class where relna
I have found and deleted an entry with pg_class.relnamespace=559701082
but nowhere else. I still cannot dump the schema. Is there something
like a system catalog integrity checker?
The problem I'm facing is the following:
cs1=# select relname from pg_class where relname like 'bm%';
Hi Tom,
I have now deleted every temp table I know from pg_temp_nnn using your
approach but still can't dump the schema:
pg_dump: schema with OID 559701082 does not exist
I could'nt find any reference to 559701082 in pg_class, pg_namespace
or pg_proc.
Regards,
Dirk
Tom
Yes, I finally found the reference in pg_type.
Thanks for your help!
Regards,
Dirk
Tom Lane wrote:
=?ISO-8859-1?Q?Dirk_Lutzeb=E4ck?= <[EMAIL PROTECTED]> writes:
I have now deleted every temp table I know from pg_temp_nnn using your
approach but still can't dump the schem
Hi Tom,
* Tom Lane wrote on Sat, 03 Dec 2005 at 13:11 -0500:
> * Dirk Pirschel writes:
>
> > No answer to bug reports 1975 and 2055 yet. Are you going to fix these
> > issues, or is AIX currently unsupportet?
>
> You seem to have a problem with missing SSL in the link, bu
--prefix=$HOME/software --with-includes=/client/include
--with-libs=/client/lib
$ make
[...]
All of PostgreSQL successfully made. Ready to install.
$ make install
[...]
PostgreSQL installation complete.
Your patch works fine :-) Thanks!
Regards,
-Dirk
--
"If Microsoft can change and comp
rwxrwx 1 root system 42 Nov 18 2004 libpq.so ->
/sw/rs_aix52/postgresql-7.4.6/lib/libpq.so
lrwxrwxrwx 1 root system 44 Nov 18 2004 libpq.so.3 ->
/sw/rs_aix52/postgresql-7.4.6/lib/libpq.so.3
Regards,
-Dirk
--
Close the windows - the penguin is freezing
pg
The following bug has been logged online:
Bug reference: 5740
Logged by: Dirk Heinrichs
Email address: dirk.heinri...@altum.de
PostgreSQL version: 8.4.5
Operating system: Linux
Description:contrib/spi/moddatetime.c doesn't work with timezones.
Details:
Am 02.11.2010 23:09, schrieb Dimitri Fontaine:
> So I guess that you need to modify very little code to get the trigger
> to work for both types.
Please find the patch attached. It's against 8.4.5.
Bye...
Dirk
diff -u spi.old/moddatetime.c spi/moddatetime.c
--- spi.old/mo
ther patch, hope my limited C skills are
sufficient... Works here, at least.
BTW: Is there a way to achieve the same in pure PL/pgSQL or PL/perl?
Bye...
Dirk
diff -u spi.old/moddatetime.c spi/moddatetime.c
--- spi.old/moddatetime.c 2010-10-01 15:35:31.0 +0200
+++ spi/moddatetime
37 matches
Mail list logo
