Re: Small TRUNCATE glitch - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Small TRUNCATE glitch
Date
Msg-id 5488052A.7090104@vmware.com
Whole thread Raw
In response to Re: Small TRUNCATE glitch  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Small TRUNCATE glitch  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On 12/10/2014 03:04 AM, Alvaro Herrera wrote:
> Alex Shulgin wrote:
>
>> The 2PC part requires extending bool flag to fit the trunc flag, is this
>> approach sane?  Given that 2PC transaction should survive server
>> restart, it's reasonable to expect it to also survive the upgrade, so I
>> see no clean way of adding another bool field to the
>> TwoPhasePgStatRecord struct (unless some would like to add checks on
>> record length, etc.).
>
> I don't think we need to have 2PC files survive a pg_upgrade.  It seems
> perfectly okay to remove them from the new cluster at some appropriate
> time, *if* they are copied from the old cluster at all (I don't think
> they should be.)

I think pg_upgrade should check if there are any prepared transactions 
pending, and refuse to upgrade if there are. It could be made to work, 
but it's really not worth the trouble. If there are any pending prepared 
transactions in the system when you run pg_upgrade, it's more likely to 
be a mistake or oversight in the first place, than on purpose.

- Heikki



pgsql-hackers by date:

Previous
From: "Amit Langote"
Date:
Subject: Re: On partitioning
Next
From: Michael Paquier
Date:
Subject: Re: Compression of full-page-writes