| From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Alex Shulgin <ash(at)commandprompt(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Small TRUNCATE glitch |
| Date: | 2014-12-10 08:32:42 |
| Message-ID: | 5488052A.7090104@vmware.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2014-12-10 08:36:20 | Re: Compression of full-page-writes |
| Previous Message | Amit Langote | 2014-12-10 07:03:00 | Re: On partitioning |