| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Alexandre Garcia <alexandre(at)vmfarms(dot)com>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: postgresql 9.6 - cannot freeze committed xmax |
| Date: | 2018-03-01 21:32:08 |
| Message-ID: | 20180301213208.y7e4aflsklro4kpr@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
I pushed my proposed fix all the way back to 9.3.
As I said earlier, I couldn't detect a bug of the sort you describe:
a) as I argued in my previous email, no tuple earlier than the
relfreezexid should survive, because 9.2 did remove those when
freezing the table.
b) One thing we could do but do not, is detect the case where there is
an Xmax that is newer than the cutoff_xid but comes from before the
pg_upgrade. We don't freeze it in that case. But we do return it as
totally_frozen=false, so it'll be frozen later anyway -- nothing bad
happens. I don't think this is worth tinkering with.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-03-01 21:42:50 | Re: postgresql 9.6 - cannot freeze committed xmax |
| Previous Message | Alvaro Herrera | 2018-03-01 17:40:10 | Re: postgresql 9.6 - cannot freeze committed xmax |