The following bug has been logged online:
Bug reference: 3695
Logged by: Roger
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3
Operating system: Windows
Description:Pgsql does not report non existing function
Details:
I've looked at 8.3 on windows and I'm u
Hello all,
I have a nasty-looking problem case. Shortly described as follows:
INSERT INTO mytable (id, value) VALUES (4242, 'úabcdú');
SELECT id FROM mytable WHERE value ILIKE '%abc%';
In environment A, the row of the ID just inserted is returned
correctly, but in environment B no rows are fo
The following bug has been logged online:
Bug reference: 3696
Logged by: Pierre-yves Strub
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5 / 8.3b
Operating system: Linux 2.6
Description:FK integrity check bypassed using rules.
Details:
Hello.
Here is a S
"Gergely Bor" <[EMAIL PROTECTED]> writes:
> I have a nasty-looking problem case. Shortly described as follows:
>
> INSERT INTO mytable (id, value) VALUES (4242, 'úabcdú');
> SELECT id FROM mytable WHERE value ILIKE '%abc%';
>
> In environment A, the row of the ID just inserted is returned
> correc
"Roger" <[EMAIL PROTECTED]> writes:
> Description:Pgsql does not report non existing function
Works fine for me:
regression=# create function foo() returns int as $$
regression$# declare x int;
regression$# begin
regression$# x := nosuchfunc(42);
regression$# end$$ language plpgsql;
CR
The following bug has been logged online:
Bug reference: 3697
Logged by: Marc Mamin
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: SuSE Linux 9.1 (i586)
Description:utf8 issue: can not reimport a table that was
successfully exported.
Det
Hello Gregory,
We'll google the initdb stuff and try it ASAP.
What I've tried is LOWER and UPPER, and they seem to return trash for
Hungarian UTF-8 characters, but they handle ASCII well. (H...
maybe ILIKE requires LOWER and UPPER to work? Would not be
illogical...)
Best regards,
Gerge
"Marc Mamin" <[EMAIL PROTECTED]> writes:
> I didn't check if all characters are valid UTF8...
They aren't ...
> select f_utf8_test('(Mozilla/4.0 (compatible; MSIE 6.0; Wind
> \xE0\xF0\xF1\xF2\xE2\xE5\xED\xED\xFB\xE9 \xE2\xFB\xF1\xF8\9
> \xE3\xEE\xF1\xF3\xE4
> xE4\xE6 \xCD\xC1 \xD0\xC1")');
In 8.
"Gergely Bor" <[EMAIL PROTECTED]> writes:
> We'll google the initdb stuff and try it ASAP.
>
> What I've tried is LOWER and UPPER, and they seem to return trash for
> Hungarian UTF-8 characters, but they handle ASCII well. (H...
> maybe ILIKE requires LOWER and UPPER to work? Would not be
> i
"Pierre-yves Strub" <[EMAIL PROTECTED]> writes:
> CREATE TABLE data (
> id INTEGER PRIMARY KEY DEFAULT nextval('sequence'),
> ref_id INTEGER NULL REFERENCES data(id) ON DELETE CASCADE
> );
> CREATE RULE data_delete_rule
> AS ON DELETE TO data WHERE OLD.ref_id IS NOT NULL
> DO INSTEAD NOTHING;
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Gergely Bor" <[EMAIL PROTECTED]> writes:
>> Environment B: Debian lenny/sid ^[1], kernel version 2.6.20.1, glibc
>> 2.6.1-5, psql 8.2.5, lc_* is hu_HU, all encondings (client, server,
>> DB) are UTF-8.
> I'm not sure this is the right answer but what ha
"Marc Mamin" <[EMAIL PROTECTED]> writes:
> Is there a recommendation how to clean these data (I know where to
> search for them)
Usually people do it by running iconv with the delete-bad-data option
on a pg_dump file.
regards, tom lane
---(end of b
On 10/25/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Yes, a poorly designed rule can invalidate all kinds of expectations
> about behavior. This isn't a bug in my humble opinion.
Yes, this was my first impression.
I was just surprised because of this: the script
CREATE TABLE dat
Thank you for your quick response,
> if you don't quote backslashes in untrusted input you'll have problems
far worse than this one
I do it now but not since by db is live...
So I probably have some invalid caraters in.
Is this an issue that must be fixed before I can upgrade to 8.3 ?
Is there
Hello.
I have problems with Postgres core dumping on FreeBSD7 (RELENG_7)
Here is backtrace from gdb postgres postgres.core:
(gdb) bt
#0 0x485dc277 in kill () from /lib/libc.so.7
#1 0x485dc1d6 in raise () from /lib/libc.so.7
#2 0x485dadda in abort () from /lib/libc.so.7
#3 0x0824c075 in errfin
Michael wrote:
> Extract from dmesg:
> pid 30622 (postgres), uid 70: exited on signal 6 (core dumped)
>
> Nothing interesting in other logs.
>
> I run FreeBSD 7.0-BETA1 on Dual-Core AMD Opteron(tm) Processor 2216
> (2394.01-MHz 686-class CPU) with ULE scheduler
> PostgreSQL 8.2.5
>
> I can't fi
Michael <[EMAIL PROTECTED]> writes:
> Here is backtrace from gdb postgres postgres.core:
> (gdb) bt
> #0 0x485dc277 in kill () from /lib/libc.so.7
> #1 0x485dc1d6 in raise () from /lib/libc.so.7
> #2 0x485dadda in abort () from /lib/libc.so.7
> #3 0x0824c075 in errfinish ()
> #4 0x0824c8b1 in
TL> Apparently s_lock_stuck ... though you might want to look at
TL> postmaster's stderr output to confirm that.
Yes, you are right
2007-10-25 23:37:12 MSD (u=picred,db=picred)PANIC: stuck spinlock (0x4880c3b0)
detected at lwlock.c:379
TL> Did you recompile Postgres? Maybe you need to. I dunn
Michael <[EMAIL PROTECTED]> writes:
> 2007-10-25 23:37:12 MSD (u=picred,db=picred)PANIC: stuck spinlock
> (0x4880c3b0) detected at lwlock.c:379
You said this was an Opteron? Why is it printing only 32-bit addresses?
> TL> Did you recompile Postgres? Maybe you need to. I dunno what the
> TL>
TL> You said this was an Opteron? Why is it printing only 32-bit addresses?
Yes, i'm using it in 32-bit mode
TL> Did you rebuild in a pre-existing PG build tree? If so, that might
TL> have resulted in a partial rebuild that could create such a problem.
TL> I'd suggest "make distclean", reconfigu
20 matches
Mail list logo
