Re: 9.5.4: Segfault (signal 11) while running ALTER TABLE - Mailing list pgsql-hackers

From Devrim Gündüz
Subject Re: 9.5.4: Segfault (signal 11) while running ALTER TABLE
Date
Msg-id 1472632125.19416.4.camel@gunduz.org
Whole thread Raw
In response to Re: 9.5.4: Segfault (signal 11) while running ALTER TABLE  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Aggregate Push Down - Performing aggregation on foreign server
Next
From: Stas Kelvich
Date:
Subject: Re: Logical decoding restart problems