Re: Altering column type causes unstable server and data loss.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Long <mlong(at)datalong(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Altering column type causes unstable server and data loss.
Date: 2004-10-08 19:00:20
Message-ID: 14937.1097262020@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Michael Long <mlong(at)datalong(dot)com> writes:
> If this is not the correct place report this type thing please let me
> know and I will post it to the correct location.

pgsql-bugs is much more appropriate, especially for problem reports
against a beta version.

> I was able to successfully alter a column of type date to
> varchar(20). However now when I perform selects on the table I will
> either get the results as expected, have the psql connection to the
> server broken, or have the server itself hang.

I tried to reproduce this without any success. Given the inconsistency
of the behavior, I'm wondering about hardware flakiness on your machine.
I could believe that ALTER TABLE has a bug causing it to produce a
corrupt output table, but if the table is corrupt then "select *" should
produce consistently wrong answers or a consistent crash. In any case,
I made a table matching your table schema, put a few rows in it, did the
ALTER, and was still able to SELECT * from it. So if there's a bug it
requires additional triggering conditions you haven't mentioned.

> The other interesting behavior is that prior to altering the table I
> could connect to the server from my Win2k box. After this point I get
> the message "FATAL: missing or erroneous pg_hba.conf file." This file
> not only exists but has not be modified by me during this time frame.

So what's in the file now?

regards, tom lane

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message roger 2004-10-08 19:22:22 Postmaster terminated without any error message
Previous Message Pallav Kalva 2004-10-08 18:24:05 Vacuumdb