- Original Message -
> I mostly agree, but it's possible you got hit by a fixed bug.
I'm lucky ;)
someone know how I can correct the catalog and drop the old/renamed table?
Or probably is simpler:
- pg_dump database
- DROP database
- CREATE DATABASE
- psql database < dump
Or do I need t
On Tue, Mar 6, 2012 at 6:34 PM, Matteo Sgalaberni wrote:
> - Original Message -
>> On 6.3.2012 21:24, Matteo Sgalaberni wrote:
>> > Hi people!
>> >
>> > I have a pg 8.3. Today I issued in a database that comand:
>>
>> Which minor version? The last one in this branch is 8.3.18 and if
>> you
- Original Message -
> On 6.3.2012 21:24, Matteo Sgalaberni wrote:
> > Hi people!
> >
> > I have a pg 8.3. Today I issued in a database that comand:
>
> Which minor version? The last one in this branch is 8.3.18 and if
> you're
> running an old one, there might be an important bugfix ...
On 6.3.2012 21:24, Matteo Sgalaberni wrote:
> Hi people!
>
> I have a pg 8.3. Today I issued in a database that comand:
Which minor version? The last one in this branch is 8.3.18 and if you're
running an old one, there might be an important bugfix ...
> =# ALTER TABLE cliente ADD COLUMN pwd_expi
Hi people!
I have a pg 8.3. Today I issued in a database that comand:
=# ALTER TABLE cliente ADD COLUMN pwd_expired boolean DEFAULT FALSE;
WARNING: unexpected attrdef record found for attr 22 of rel cliente
WARNING: unexpected attrdef record found for attr 22 of rel cliente
WARNING: unexpected
"Bryan White" <[EMAIL PROTECTED]> writes:
>> Shut down the postmaster and then copy the entire db (including pg_log
>> file) and it should work. The catch is to make sure pg_log is in sync
>> with your table files.
> I would rather not leave my database down long enough to copy the entire db
> (
> Shut down the postmaster and then copy the entire db (including pg_log
> file) and it should work. The catch is to make sure pg_log is in sync
> with your table files.
I would rather not leave my database down long enough to copy the entire db
(3.5GB). I have control over when changes are app
"Bryan White" <[EMAIL PROTECTED]> writes:
> I am wiling to spend some time to track this down. However I would prefer
> to not keep crashing my live database. I would like to copy the raw data
> files to a backup maching. Are there any catches in doing this.
Shut down the postmaster and then c
> Hmm. Assuming that it is a corrupted-data issue, the only likely
> failure spot that I see in CopyTo() is the heap_getattr macro.
> A plausible theory is that the length word of a variable-length field
> (eg, text column) has gotten corrupted, so that when the code tries to
> access the next fi
"Bryan White" <[EMAIL PROTECTED]> writes:
>> I concur that this probably indicates corrupted data in the file. We
>> may or may not be able to guess how it got corrupted, but a stack trace
>> seems like the place to start.
> Here is the backtrace:
> #0 0x808b0e1 in CopyTo ()
Hmm. Assuming tha
> Status 139 indicates a SEGV trap on most Unixen. There should be a core
> dump left by the crashed backend --- can you get a backtrace from it
> with gdb?
>
> I concur that this probably indicates corrupted data in the file. We
> may or may not be able to guess how it got corrupted, but a sta
"Bryan White" <[EMAIL PROTECTED]> writes:
> As a result of this event, in the log file I see:
> ---
> Server process (pid 21764) exited with status 139 at Mon Jul 31 14:51:44
Status 139 indicates a SEGV trap on most Unixen. There should be a core
dump left by the crashed backend ---
12 matches
Mail list logo
