Re: 9.5.4: Segfault (signal 11) while running ALTER TABLE

Hi Tom,

On Tue, 2016-08-30 at 08:18 -0400, Tom Lane wrote:
> The above isn't ever likely to work for any large value of "work",
> because the function would be confused about what the table rowtype
> is.  I thought we had adequate defenses in there to throw an error
> if you try to access a table that's in the middle of being altered,
> but apparently this case isn't covered.
>
> Why didn't they just do
>         ALTER TABLE foo1 ALTER COLUMN id TYPE INTEGER USING newid;
> ?  The intermediate function sure seems like the hard way.

Just got a reply from them. They had some historical reasons for this, but
apparently it was not needed, so they'll change their procedures based on your
suggestion.

However, they also reported that they did not have this problem in their
staging environment. I assume that staging has less resources than the prod
machine. What could cause this problem that has more maintenance_work_mem and
shared_buffers than staging one?

Thanks!

Regards,
-- 
Devrim GÜNDÜZ
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR