jw=# CREATE TABLE base ( CHECK (tableoid = 'base'::regclass) );
CREATE TABLE
jw=# \d base
Table "public.base"
Column | Type | Modifiers
+--+---
Check constraints:
"base_tableoid_check" CHECK (tableoid = 'base'::regclass::oid)
jw=# INSERT INTO base DEFAULT VALUES ;
ERRO
维 姜 wrote:
jw=# CREATE TABLE base ( CHECK (tableoid = 'base'::regclass) );
CREATE TABLE
jw=# \d base
Table "public.base"
Column | Type | Modifiers
+--+---
Check constraints:
"base_tableoid_check" CHECK (tableoid = 'base'::regclass::oid)
jw=# INSERT INTO base DEFAULT
On Tue, Apr 11, 2006 at 03:11:46PM +0800, ??? ??? wrote:
> jw=# CREATE TABLE base ( CHECK (tableoid = 'base'::regclass) );
> CREATE TABLE
> jw=# \d base
> Table "public.base"
> Column | Type | Modifiers
> +--+---
> Check constraints:
> "base_tableoid_check" CHECK (table
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Apparently a new row's tableoid isn't set until the row is actually
> inserted.
I believe that's true of all the system columns. If you're using oid,
for example, that's not assigned either until heap_insert().
This behavior doesn't seem unreasonable to
Tom Lane 写道:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
>
>> Apparently a new row's tableoid isn't set until the row is actually
>> inserted.
>>
>
> I believe that's true of all the system columns. If you're using oid,
> for example, that's not assigned either until heap_insert().
>
> This
Sorry about the delay in responding. We had a bit of difficulty with
the test machine. Kevin is also on vacation this week.
The problem is repeatable with a VACUUM. I've found the offending
block. A (partial) pg_filedump of that block is pasted in below. I'm a
little lost as to what the next
"Peter Brant" <[EMAIL PROTECTED]> writes:
> PANIC: right sibling is not next child in "Panel_pkey", parent is 271
Hmm ... that's not actually enough info to tell us where to look,
is it :-(. Please add the following variables to the elog message, or
gdb for them if you can:
target
I have installed PostGreSql on a flash memory drive. How do I start the shell command?
Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries for just 2¢/min with Yahoo! Messenger with Voice.
The following bug has been logged online:
Bug reference: 2387
Logged by:
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.3
Operating system: Linux 2.4.22
Description:Incorrect sorting of timestamp with time zone
Details:
When sorting by "timestamp with tim
The following bug has been logged online:
Bug reference: 2386
Logged by: Patrick Headley
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.4 +
Operating system: Windows XP
Description:pg_restore doesn't restore large objects
Details:
I have been trying to res
The following bug has been logged online:
Bug reference: 2388
Logged by: Hugo Quisbert
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: Windows XP
Description:PostsgreSQL fails under isntallation
Details:
PostgreSQL do fails under installat
Hello,
I'm posted a short modification of the kill command.
The INSTALL file mention the command "kill `cat
/usr/local/pgsql/data/postmaster.pid`" but the pid file contain the pid
but not only, it also contain data directory and some numbers (memory
usage ?, database characteristic ?)
So wh
"" <[EMAIL PROTECTED]> writes:
> SELECT time_stamp, time_stamp_with_zone from timetest order by
> time_stamp_with_zone;
> I get the following result:
> time_stamp | time_stamp_with_zone
> -+
> 2006-09-23 20:01:00 | 2006-09-23 23:01:00+00
>
julien <[EMAIL PROTECTED]> writes:
> The INSTALL file mention the command "kill `cat
> /usr/local/pgsql/data/postmaster.pid`" but the pid file contain the pid
> but not only, it also contain data directory and some numbers (memory
> usage ?, database characteristic ?)
Hm, I wonder why this docu
"Patrick Headley" <[EMAIL PROTECTED]> writes:
> Description:pg_restore doesn't restore large objects
At no point did you show us exactly what you did or exactly what went
wrong, so even though this report has a lot of version-number details,
it's just about useless :-(. Please see the rep
Martín is not subscribed apparently.
- Forwarded message from Martin Marques -
From: Martin Marques
To: pgsql-bugs@postgresql.org
Cc: Alvaro Herrera <[EMAIL PROTECTED]>
Date: Tue, 11 Apr 2006 16:34:43 -0300
Subject: BUG in logs
Organization: Cetul - UNL
I encountered a rare BUG in the
> From: Martin Marques
> I encountered a rare BUG in the way PG is logging. Let me first enlight with
> some configuration I have and PG version:
Perhaps I'm missing something but I think it's not a bug but a
configuration problem.
> log_min_error_statement| panic
If you set this one to e
Try as I might, I wasn't able to get a JIT debugger give me a memory
dump. It seems like postgres.exe is not really crashing in the
"unhandled exception" sense (see gdb log below)? Am I missing a
configure option?
(As an aside, what's the best way to get a core dump on Windows? Can
gdb read mem
"Peter Brant" <[EMAIL PROTECTED]> writes:
> I ended up modifying the elog again with the following results:
> PANIC: right sibling is not next child in "Panel_pkey", parent is 271,
> target is 635, rightsib is 629, nextoffset is 87
OK, so the part of the pg_filedump info we need to see is items 8
The index data isn't sensitive, but I should ask for permission
nonetheless. I'll send over the '-f' output tomorrow morning.
Pete
***
* PostgreSQL File/Block Formatted Dump Utility - Version 8.1.1
*
* File: 180571
* Options used:
Also, when I tried to run a database-wide VACUUM ANALYZE VERBOSE it
actually doesn't even get to Panel and errors out with:
INFO: analyzing "public.MaintCode"
INFO: "MaintCode": scanned 1 of 1 pages, containing 19 live rows and 0
dead rows; 19 rows in sample, 19 estimated total rows
ERROR: dupl
"Peter Brant" <[EMAIL PROTECTED]> writes:
> Also, when I tried to run a database-wide VACUUM ANALYZE VERBOSE it
> actually doesn't even get to Panel and errors out with:
> ERROR: duplicate key violates unique constraint
> "pg_statistic_relid_att_index"
Hm, my eyebrows just disappeared over the b
22 matches
Mail list logo
