| 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-02-28 22:56:43 |
| Message-ID: | 20180228225643.trwxqmovq4uflf4f@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Andres Freund wrote:
> Alvaro,
>
> On 2018-02-28 21:17:08 +0000, Alexandre Garcia wrote:
> > Oh yes sorry => `ERROR: cannot freeze committed xmax 43076385` on that
> > same table
>
> In light of
> Latest checkpoint's NextXID: 0/128653693
> I find this confusing.
Ooh.
If you SELECT FOR UPDATE a tuple in 9.2, bit 0x0040 gets set in
infomask, and nothing else. If you pg_upgrade and later try to freeze
such a tuple, it will fail with the error reported.
The correct test to use is HEAP_XMAX_IS_LOCKED_ONLY, which also tests
for the above condition.
I will verify this theory and push a patch shortly, if it proves
correct.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexandre Garcia | 2018-02-28 23:05:02 | Re: postgresql 9.6 - cannot freeze committed xmax |
| Previous Message | Bear Giles | 2018-02-28 22:42:31 | Re: audit table with permissions |