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
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> 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:
> 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
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
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
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
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
"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
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
"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;
"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
"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.
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
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
"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
"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
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
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: 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
20 matches
Mail list logo
