> Richard Broersma Jr <[EMAIL PROTECTED]> writes:
> >> Are you interested in dumping out the page of pg_index that
> >> contains this record, using pg_filedump?
>
> > I've attached the results.log to the email.
>
> Well, there's our smoking gun:
> 1bfc: 74746e6f 1c00 ttno
Richard Broersma Jr <[EMAIL PROTECTED]> writes:
>> Are you interested in dumping out the page of pg_index that
>> contains this record, using pg_filedump?
> I've attached the results.log to the email.
Well, there's our smoking gun:
Item 11 -- Length: 398 Offset: 6844 (0x1abc) Flags: USED
> >> Are you interested in dumping out the page of pg_index that
> >> contains this record, using pg_filedump?
>
> > Sure, only how do I use pg_filedump?
>
> Find out the ctid of the busted pg_index record; the first part of it is
> the page number. Then
>
> pg_filedump -i -f -R page_numb
Richard Broersma Jr <[EMAIL PROTECTED]> writes:
>> Are you interested in dumping out the page of pg_index that
>> contains this record, using pg_filedump?
> Sure, only how do I use pg_filedump?
Find out the ctid of the busted pg_index record; the first part of it is
the page number. Then
> Are you interested in dumping out the page of pg_index that
> contains this record, using pg_filedump?
Sure, only how do I use pg_filedump?
> In any case, my advice for recovering from the problem once you get
> tired of investigating is to drop and recreate this index. (If you're
> not sure
Richard Broersma Jr <[EMAIL PROTECTED]> writes:
> -[ RECORD 2 ]--+--
> indexrelid | 604251
> indrelid | 16737
> indnatts | 1
> indisunique| f
> indisprimary | f
> indisclustered | f
> indkey | 0
> indclass | 2039
> indexprs | ({FUNCE
> >> So what do you get from 'select * from pg_index where indrelid = 16737' ?
> >> If that crashes, which individual columns can you select from the row?
>
> > I found the exact row and column that causes the server to crash.
> > http://archives.postgresql.org/pgsql-general/2006-10/msg01320.php
>
Richard Broersma Jr <[EMAIL PROTECTED]> writes:
>> So what do you get from 'select * from pg_index where indrelid = 16737' ?
>> If that crashes, which individual columns can you select from the row?
> I found the exact row and column that causes the server to crash.
> http://archives.postgresql.or
> > mydb=# select pg_get_indexdef(indexrelid) from pg_index where indrelid =
> > '16737';
> > server closed the connection unexpectedly
>
> So what do you get from 'select * from pg_index where indrelid = 16737' ?
> If that crashes, which individual columns can you select from the row?
I found t
Richard Broersma Jr <[EMAIL PROTECTED]> writes:
> mydb=# select pg_get_indexdef(indexrelid) from pg_index where indrelid =
> '16737';
> server closed the connection unexpectedly
So what do you get from 'select * from pg_index where indrelid = 16737' ?
If that crashes, which individual columns can
> > > but before you do that, I'd urge
> > > you to try to get as much info as you can about the nature of the
> > > catalog corruption. If there's a bug here, as opposed to random
> > > cosmic-ray damage, we can't fix it without more info.
>
> I eliminated the non-offending index with this query
> >Worst-case, you can probably fix things by dropping and
> > recreating the constraint or index ...log_min_messages = info but before
> > you do that, I'd
> urge
> > you to try to get as much info as you can about the nature of the
> > catalog corruption. If there's a bug here, as opposed to r
> What this looks like is that there's a mangled expression string in
> the catalog entry for either a check constraint or an expression index.
> The backend is dying while trying to decompile the expression for
> pg_dump.
you were write, I appears that my problem is with one of four functional
d
Richard Broersma Jr <[EMAIL PROTECTED]> writes:
> You'll have to forgive me. I've never used gdb before, I am not sure I
> am executing gdb with the correct syntax. However, I was able to
> produce a core file. Here is the syntax that I used that produced the
> most output - althought it doesn't
> No, you just need to make sure the postmaster is started under
> "ulimit -c unlimited", not "ulimit -c 0" which is the default
> under many Linuxen. Adding this to the start script is the
> easiest way usually.
>
> If you can't get anything but numbers from gdb's stack trace
> then you have a "
Richard Broersma Jr <[EMAIL PROTECTED]> writes:
> I did not find any coredump files. Will I need to rebuild postgres to
> produce coredumps?
No, you just need to make sure the postmaster is started under
"ulimit -c unlimited", not "ulimit -c 0" which is the default
under many Linuxen. Adding th
> > 10-25 18:51:43 PDT% LOG: server process (PID 12899) was
> > terminated by signal 11
>
> Stack trace from coredump, please? And exactly which PG version is
> this?
The version is 8.1.4 on:
Linux version 2.6.17-gentoo-r7 ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo
4.1.1)) #8 Sun Oc
Richard Broersma Jr <[EMAIL PROTECTED]> writes:
> 10-25 18:51:43 PDT% LOG: server process (PID 12899) was
> terminated by signal 11
Stack trace from coredump, please? And exactly which PG version is
this?
regards, tom lane
---(end of broad
I am trying to perform a complete dump of my database. However, I am getting
an error when
pg_dumpall reaches one particular database. I reformatted the text so that it
wouldn't get
chopped to pieces after it is sent.
Here is the output from pg_dumpall:
[EMAIL PROTECTED] $ pg_dumpall > test.d
I am trying to preform a complete dump of my database. However, I am getting
an error when
pg_dumpall reachs one particular database. I reformated the text so that it
wouldn't get chopped
to pieces after it is sent.
Here is the output from pg_dumpall:
[EMAIL PROTECTED] $ pg_dumpall > test.dum
20 matches
Mail list logo
