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
signature.asc
Description: This is a digitally signed message part