[BUGS] constraints & tableoid [pgsql8.1]
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 ; ERROR: new row for relation "base" violates check constraint "base_tableoid_check" jw=# ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] constraints & tableoid [pgsql8.1]
维 姜 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 VALUES ; ERROR: new row for relation "base" violates check constraint "base_tableoid_check" jw=# The CHECK tests the tuple that is being inserted, which doesn't include tableoid. I'm not sure if this counts as a bug or not. You might be able to do this with a trigger function (although I'm not clear what you're trying to do). -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] constraints & tableoid [pgsql8.1]
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 (tableoid = 'base'::regclass::oid) > > jw=# INSERT INTO base DEFAULT VALUES ; > ERROR: new row for relation "base" violates check constraint > "base_tableoid_check" Check the constraint with a function that logs its arguments and you'll see what's happening: test=> CREATE FUNCTION toid_check(oid, oid) RETURNS boolean AS $$ test$> BEGIN test$> RAISE INFO 'toid_check(%, %)', $1, $2; test$> RETURN $1 = $2; test$> END; test$> $$ LANGUAGE plpgsql IMMUTABLE STRICT; CREATE FUNCTION test=> CREATE TABLE base (CHECK(toid_check(tableoid, 'base'::regclass))); CREATE TABLE test=> INSERT INTO base DEFAULT VALUES; INFO: toid_check(0, 540339) ERROR: new row for relation "base" violates check constraint "base_tableoid_check" Apparently a new row's tableoid isn't set until the row is actually inserted. Tableoid would be set in an AFTER trigger, but if the intent is to prevent inheritance then enforcing the constraint with a trigger on the base table wouldn't work because triggers aren't inherited. -- Michael Fuhr ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] constraints & tableoid [pgsql8.1]
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 me. A candidate row is not a member of the table until *after* it's passed its constraint checks --- until then, it's just some values sitting in memory. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] constraints & tableoid [pgsql8.1]
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 behavior doesn't seem unreasonable to me. A candidate row is not a > member of the table until *after* it's passed its constraint checks --- > until then, it's just some values sitting in memory. > > regards, tom lane > > jw=# ALTER TABLE base DROP CONSTRAINT base_tableoid_check; ALTER TABLE jw=# ALTER TABLE base ADD CHECK (tableoid = 0); ALTER TABLE jw=# INSERT INTO base DEFAULT VALUES ; INSERT 0 1 jw=# INSERT INTO base DEFAULT VALUES ; INSERT 0 1 jw=# INSERT INTO base DEFAULT VALUES ; INSERT 0 1 jw=# select *,tableoid from base; tableoid -- 301146 301146 301146 (3 rows) jw=# \d+ base Table "public.base" Column | Type | Modifiers | Description +--+---+- Check constraints: "base_tableoid_check" CHECK (tableoid = 0::oid) Has OIDs: no ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] right sibling is not next child
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 step is though. Any pointers would be appreciated. Pete "Kevin Grittner" writes: > [2006-04-06 02:19:57.460 ] 3848 PANIC: right sibling is not next child in "Panel_pkey" This should be repeatable by re-attempting a VACUUM, right? Please find out which page exactly it's unhappy about (either gdb the crash or add a printout of the "parent" variable to the elog call in nbtpage.c), then pg_filedump the index and look to see what the index contains. regards, tom lane PANIC: right sibling is not next child in "Panel_pkey", parent is 271 *** * PostgreSQL File/Block Formatted Dump Utility - Version 8.1.1 * * File: 180571 * Options used: -R 271 -i * * Dump created on: Tue Apr 11 13:38:44 2006 *** Block 271 - Block Offset: 0x0021e000 Offsets: Lower 468 (0x01d4) Block: Size 8192 Version3Upper1952 (0x07a0) LSN: logid246 recoff 0x265d47c0 Special 8176 (0x1ff0) Items: 112 Free Space: 1484 Length (including item array): 472 -- Item 1 -- Length: 56 Offset: 8120 (0x1fb8) Flags: USED Block Id: 132 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 2 -- Length:8 Offset: 8112 (0x1fb0) Flags: USED Block Id: 201 linp Index: 1 Size: 8 Has Nulls: 0 Has Varwidths: 0 Item 3 -- Length: 56 Offset: 8056 (0x1f78) Flags: USED Block Id: 257 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 ... snip ... Item 109 -- Length: 56 Offset: 4920 (0x1338) Flags: USED Block Id: 121 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 110 -- Length: 56 Offset: 4864 (0x1300) Flags: USED Block Id: 133 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 111 -- Length: 56 Offset: 4808 (0x12c8) Flags: USED Block Id: 134 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 112 -- Length: 56 Offset: 4752 (0x1290) Flags: USED Block Id: 137 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 - BTree Index Section: Flags: 0x () Blocks: Previous (167) Next (455) Level (1) *** End of Requested Range Encountered. Last Block Read: 271 *** ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] right sibling is not next child
"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 rightsib nextoffset regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] set up on flash drive
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.
[BUGS] BUG #2387: Incorrect sorting of timestamp with time zone
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 time zone" columns the daylight-saving time
is not interpreted correctly. I have inserted equal timestamps to a table
named timetest with two columns:
Column|Type
--+-
time_stamp | timestamp without time zone
time_stamp_with_zone | timestamp with time zone
INSERT INTO timetest VALUES ('2006-09-23 22:01:00', '2006-09-23 22:01:00' at
time zone 'TST-2TDT,M3.5.0/0,M9.5.0/1');
(Where TST and TDT are freely choosen abbreviations as explained in
PostgreSQL 8.1.3 Documentation - Appendix B. Date/Time Support)
My local timezone setting is UTC. I also inserted timestamps in the time of
daylight saving switching. Now when I use the query:
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
2006-09-23 22:01:00 | 2006-09-24 00:01:00+00
2006-09-23 21:01:00 | 2006-09-24 00:01:00+00
2006-09-23 23:01:00 | 2006-09-24 01:01:00+00
2006-09-24 00:01:00 | 2006-09-24 02:01:00+00
As one can see lines 2 and 3 are in the wrong order.
Since time_stamp_with_zone is internally saved as UTC it should be possible
to sort the output corresponding to the underlying UTC timestamp correctly.
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #2386: pg_restore doesn't restore large objects
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 restore some PostgreSQL databases with a single large object in them. By single I mean a single table with one lo and only one record. Using the pg_restore utility that ships with the Windows version of PGAdmin III v1.4.1 and 1.4.2 didn't work. I was finally able to restore the databases with the pg_restore that was on the Mac OS X machine hosting the PostgreSQL Server. Postgres was compiled and installed by using the Fink project. The version on that machine is 8.1.x. Backups don't seem to be the problem as I was able to make a backup using the Windows version of pg_backup that was shipped with PGAdmin III v1.4.2. I also tried v1.4.1 and though I didn't realize it was a restore problem the backups didn't error out in any way. The restore operation did error out in the same way. I tried restoring by using the pg_restore that ships with v1.4.1 and 1.4.2 of PGAdmin III on both a Windows XP machine to a Mac OS X 10.4 server hosting PostgreSQL v8.0.7 and on a Windows Server 2003 hosting it's own Postgres server v8.0.4 and from the Windows XP machine to the Windows Server 2003 machine. None of those combinations worked. What finally worked was logging onto the Mac OS X machine and running pg_restore from the bin directory. That machine has a Fink compiled and installed version of PostgreSQL. I don't know yet if the restore will work on the G4 machines but suspect that it will. It just seems to be something to do with the Windows dll. I thgought I saw something on a custom pg_restore but I don't remember where I saw that. Maybe I was using a custom pg_restore without knowing it. If so, and if this issue isn't a bug I appologize. However, I searched on the Internet for several hours while trying to figure out what to do and cannot find anything regarding this problem. Please let me know if there is something that I may have done wrong or if you can reproduce the symptom. Patrick Headley. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2388: PostsgreSQL fails under isntallation
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 installation process. I got an alert saying: "Failed to run initdb: 1!" Besides no logfile is created. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] problem with kill script
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 when I run the above kill command I get : pcbu-testiris:/etc/rc6.d# /etc/init.d/postgres stop Stopping database server: PostgreSQL/etc/init.d/postgres: line 11: kill: /usr/local/pgsql/data: no such pid /etc/init.d/postgres: line 11: kill: (5432001) - Aucun processus de ce type /etc/init.d/postgres: line 11: kill: (9076763) - Aucun processus de ce type . So I add a "head -1" to the command : kill `cat /usr/local/pgsql/data/postmaster.pid | head -1` Julien ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2387: Incorrect sorting of timestamp with time zone
"" <[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 > 2006-09-23 22:01:00 | 2006-09-24 00:01:00+00 > 2006-09-23 21:01:00 | 2006-09-24 00:01:00+00 > 2006-09-23 23:01:00 | 2006-09-24 01:01:00+00 > 2006-09-24 00:01:00 | 2006-09-24 02:01:00+00 > As one can see lines 2 and 3 are in the wrong order. AFAICS, they are the same value, so they can be sorted in either order. Which way they'll end up depends on undocumented properties of your platform's qsort() routine. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] problem with kill script
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 documentation isn't recommending "pg_ctl stop" instead. runtime.sgml gets it right: $ kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid` but the text in installation.sgml seems much older. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2386: pg_restore doesn't restore large objects
"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 reporting suggestions at http://www.postgresql.org/docs/8.1/static/bug-reporting.html regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] [EMAIL PROTECTED]: BUG in logs]
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 way PG is logging. Let me first enlight with some configuration I have and PG version: prueba2=> SELECT version(); version PostgreSQL 8.1.0 on sparc-unknown-linux-gnu, compiled by GCC cc (GCC) 4.0.3 2005 (prerelease) (Debian 4.0.2-4) (1 row) prueba2=> select name, setting from pg_settings where name like 'log%'; name| setting +- log_connections| on log_destination| stderr log_disconnections | off log_duration | off log_error_verbosity| default log_executor_stats | off log_hostname | off log_line_prefix| <%t> log_min_duration_statement | -1 log_min_error_statement| panic log_min_messages | notice log_parser_stats | off log_planner_stats | off log_rotation_age | 1440 log_rotation_size | 10240 log_statement | all log_statement_stats| off log_truncate_on_rotation | off (18 rows) Now, when I do something like the sentence below, I get an error, which is OK: prueba2=> SELECT * FROM perfiles WHERE codigo = AND perfil = 'something here'; ERROR: error de sintaxis en o cerca de <> at character 39 LINE 1: SELECT * FROM perfiles WHERE codigo = AND perfil = 'somethin... But I should see in the logs the query and then the error, which is not what I'm getting at the momento (I only get the error, ad is shown below). <2006-04-11 16:31:03 ART>ERROR: error de sintaxis en o cerca de <> en car?cter 39 If anymore information is needed, let me know. -- - Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática| '@' || 'unl.edu.ar'; Universidad Nacional| DBA, Programador, del Litoral | Administrador - - End forwarded message - -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] [EMAIL PROTECTED]: BUG in logs]
> 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 error instead of panic, you will have your failed statements logged. > log_statement | all This one only logs successful queries so it's normal you don't have the statement in the log file if it fails. Regards, -- Guillaume ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] right sibling is not next child
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 memory dumps produced by NTSD?) I was able to attach to the running backend using gdb. That worked (kind of, see log below). 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 C:\WINDOWS\system32>C:\mingw\bin\gdb C:\pgsql\bin\postgres.exe ... snip ... (gdb) attach 2084 Attaching to program `C:\pgsql\bin\postgres.exe', process 2084 [Switching to thread 2084.0x930] (gdb) break nbtpage.c:983 Breakpoint 1 at 0x41f042: file nbtpage.c, line 983. (gdb) continue Continuing. [Switching to thread 2084.0x81c] Breakpoint 1, _bt_pagedel (rel=0x196bbb0, buf=1089, vacuum_full=0 '\0') at nbtpage.c:983 983 nbtpage.c: No such file or directory. in nbtpage.c (gdb) print parent $1 = 271 (gdb) print target $2 = 635 (gdb) print rightsib No symbol "rightsib" in current context. (gdb) print nextoffset $3 = 87 (gdb) print leftsib $4 = 636 (gdb) print rightsib No symbol "rightsib" in current context. (gdb) continue Continuing. Program exited with code 03. (gdb) Pete >>> Tom Lane <[EMAIL PROTECTED]> 04/11/06 9:19 pm >>> "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 rightsib nextoffset regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] right sibling is not next child
"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 86/87 in block 271, plus a few around them for good measure. Are the values of the keys in this index sensitive data, or are they just serial numbers of some kind? If we could see pg_dump -i -f rather than just -i, it might help. I'd like to see the dumps of pages 635, 636, 629 as well (mostly their "special space" contents). regards, tom lane ---(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
Re: [BUGS] right sibling is not next child
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: -i -R 271 * * Dump created on: Tue Apr 11 18:22:24 2006 *** Block 271 - Block Offset: 0x0021e000 Offsets: Lower 468 (0x01d4) Block: Size 8192 Version3Upper1952 (0x07a0) LSN: logid246 recoff 0x265d47c0 Special 8176 (0x1ff0) Items: 112 Free Space: 1484 Length (including item array): 472 -- ... snip ... Item 80 -- Length: 56 Offset: 3352 (0x0d18) Flags: USED Block Id: 581 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 81 -- Length: 56 Offset: 3128 (0x0c38) Flags: USED Block Id: 580 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 82 -- Length: 56 Offset: 2848 (0x0b20) Flags: USED Block Id: 606 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 83 -- Length: 56 Offset: 2736 (0x0ab0) Flags: USED Block Id: 608 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 84 -- Length: 56 Offset: 2792 (0x0ae8) Flags: USED Block Id: 601 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 85 -- Length: 56 Offset: 2120 (0x0848) Flags: USED Block Id: 640 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 86 -- Length: 56 Offset: 2176 (0x0880) Flags: USED Block Id: 635 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 87 -- Length: 56 Offset: 2232 (0x08b8) Flags: USED Block Id: 636 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 88 -- Length: 56 Offset: 2288 (0x08f0) Flags: USED Block Id: 635 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 89 -- Length: 56 Offset: 2400 (0x0960) Flags: USED Block Id: 629 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 90 -- Length: 56 Offset: 5704 (0x1648) Flags: USED Block Id: 166 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 91 -- Length: 56 Offset: 5648 (0x1610) Flags: USED Block Id: 339 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 92 -- Length: 56 Offset: 5592 (0x15d8) Flags: USED Block Id: 372 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 93 -- Length: 56 Offset: 4416 (0x1140) Flags: USED Block Id: 480 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 Item 94 -- Length: 56 Offset: 5536 (0x15a0) Flags: USED Block Id: 208 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 ... snip ... - BTree Index Section: Flags: 0x () Blocks: Previous (167) Next (455) Level (1) *** End of Requested Range Encountered. Last Block Read: 271 *** *** * PostgreSQL File/Block Formatted Dump Utility - Version 8.1.1 * * File: 180571 * Options used: -i -R 635 * * Dump created on: Tue Apr 11 18:22:43 2006 *** Block 635 - Block Offset: 0x004f6000 Offsets: Lower 24 (0x0018) Block: Size 8192 Version3Upper8120 (0x1fb8) LSN: logid239 recoff 0xcabae788 Special 8176 (0x1ff0) Items:1 Free Space: 8096 Length (including item array): 28 -- Item 1 -- Length: 56 Offset: 8120 (0x1fb8) Flags: USED Block Id: 452 linp Index: 1 Size: 56 Has Nulls: 0 Has Varwidths: 16384 - BTree Index Section: Flags: 0x0001 (LEAF) Blocks: Previous (636) Next (629) Level (0) *** End of Requested Range Encountered. Last Block Read: 635 *** *** * PostgreSQL File/Block Formatted Dump Utility - Version 8.1.1 * * File: 180571 * Options used: -i -R 636 * * Dump created on: Tue Apr 11 18:22:50 2006 *** Block 636 - Block Offset: 0x004f8000 Offsets: Lower 24 (0x0018) Block: Size 8192 Version3Upper8120 (0x1fb8) LSN: logid245 recoff 0x9bfa3b60 Special 8176 (0x1ff0) Items:1 Free Space: 8096 Length (including item array): 28 -- Item 1 -- Length: 56 Offset: 8120 (0x1fb8) Flags: USED Block Id: 454 linp Index: 27 Size: 56 Has Nulls: 0 Has Varwidths: 16384 - BTree Index Section: Flags: 0x0001 (LEAF) Blocks: Previous (640) Next (635) Level (0) *** End of Requested Range Encou
Re: [BUGS] right sibling is not next child
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: duplicate key violates unique constraint "pg_statistic_relid_att_index" MaintCode is a tiny, static table. Does that indicate further corruption or is there a more benign explanation? Could these errors not be Postgres' fault? (e.g. hardware-related) Pete ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] right sibling is not next child
"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 back of my head somewhere. Is that repeatable? Does a REINDEX on pg_statistic make it go away? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
