Re: FrozenTransactionId

Hi,
Since 9.4 FrozenTransactionId is no longer used to freeze row versions.
The change was done by commit 37484ad:

> Instead of changing the tuple xmin to FrozenTransactionId, the
combination
> of HEAP_XMIN_COMMITTED and HEAP_XMIN_INVALID, which were
previously never
> set together, is now defined as HEAP_XMIN_FROZEN.

But we still have FrozenTransactionId mentioned in section 23.1.5.
Please consider the attached patch to fix it.

Thanks,
Egor Rogov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Hi,
This documentation bug is still in place for upcoming 9.6. Aren't anyone
interested in fixing it?

Regards,
Egor Rogov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

--
View this message in context: http://postgresql.nabble.com/FrozenTransactionId-tp5907478p5919545.html
Sent from the PostgreSQL - docs mailing list archive at Nabble.com.

Egor Rogov <e(dot)rogov(at)postgrespro(dot)ru> writes:
> This documentation bug is still in place for upcoming 9.6. Aren't anyone
> interested in fixing it?

It'd be more likely to get pushed if you'd submitted it in an easily
reviewable form, ie without reflowing the entire (rather long) paragraph.
As-is, it's much too hard to see what you changed or didn't change.

regards, tom lane

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> It'd be more likely to get pushed if you'd submitted it in an easily
> reviewable form, ie without reflowing the entire (rather long) paragraph.
> As-is, it's much too hard to see what you changed or didn't change.
Please find another patch attached. I hope it is a bit easier to review now.

Regards,
Egor Rogov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

maintenance-2.patch (2K) <http://postgresql.nabble.com/attachment/5919578/0/maintenance-2.patch>

--
View this message in context: http://postgresql.nabble.com/FrozenTransactionId-tp5907478p5919578.html
Sent from the PostgreSQL - docs mailing list archive at Nabble.com.

Sorry, my last email went without the attachment.

On 06.09.2016 01:09, Egor Rogov wrote:
> Tom Lane <[hidden email]
> </user/SendEmail.jtp?type=node&node=5919578&i=0>> writes:
> > It'd be more likely to get pushed if you'd submitted it in an easily
> > reviewable form, ie without reflowing the entire (rather long)
> paragraph.
> > As-is, it's much too hard to see what you changed or didn't change.
> Please find another patch attached. I hope it is a bit easier to
> review now.
>
> *maintenance-2.patch* (2K) Download Attachment
> <http://postgresql.nabble.com/attachment/5919578/0/maintenance-2.patch>
>
Regards,
Egor Rogov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Egor Rogov <e(dot)rogov(at)postgrespro(dot)ru> writes:
>> Please find another patch attached. I hope it is a bit easier to
>> review now.

Hmm. I do not actually see anything wrong with the existing text:
it does not say that FrozenTransactionId is what appears on disk,
it says that frozen tuples are treated as if their xmin were
FrozenTransactionId. That's an accurate description of the current
implementation. I'm not sure that removing all mention of special
XIDs is a good thing, especially since they will still exist on-disk
in pg_upgrade'd installations.

It does seem like this paragraph could do with some copy-editing,
but I doubt that removing information is the way to go about that.
What I'd change:
1. Grammar fix: s/effects ... is/effects ... are/
2. Remove the useless phrase ", from an MVCC perspective,"
3. Reorder the sentences just after that, so that we have
"Normal XIDs are compared ... suddenly appear to be in the future.
To prevent this, PostgreSQL reserves a special XID, FrozenTransactionId,
... considered older than every normal XID.
Frozen row versions are treated as if ..."

It might also be worth mentioning explicitly that FrozenTransactionId
can appear on-disk in old installations. And I'd be slightly tempted
to put in an explanation of BootstrapTransactionId, because users
will see that as well if they look into any system catalogs.

Comments?

regards, tom lane

On 06.09.2016 15:41, Tom Lane wrote:
> Egor Rogov <e(dot)rogov(at)postgrespro(dot)ru> writes:
>>> Please find another patch attached. I hope it is a bit easier to
>>> review now.
> Hmm. I do not actually see anything wrong with the existing text:
> it does not say that FrozenTransactionId is what appears on disk,
> it says that frozen tuples are treated as if their xmin were
> FrozenTransactionId. That's an accurate description of the current
> implementation. I'm not sure that removing all mention of special
> XIDs is a good thing, especially since they will still exist on-disk
> in pg_upgrade'd installations.

Okay, I see my mistake now: this old FrozenTransactionId mechanics is
still valid to support upgraded installations.
Anyway, while the description is technically accurate, it is misleading.
Right, it does not say that FrozenTransactionId is what appears on disk,
but what is? There is no such information anywhere in the doc. Since 9.4
frozen transactions have their normal XIDs preserved, so how a user can
tell normal transaction from frozen one? This is what needs to be
explained, I believe.

>
> It does seem like this paragraph could do with some copy-editing,
> but I doubt that removing information is the way to go about that.
> What I'd change:
> 1. Grammar fix: s/effects ... is/effects ... are/
> 2. Remove the useless phrase ", from an MVCC perspective,"
> 3. Reorder the sentences just after that, so that we have
> "Normal XIDs are compared ... suddenly appear to be in the future.
> To prevent this, PostgreSQL reserves a special XID, FrozenTransactionId,
> ... considered older than every normal XID.
> Frozen row versions are treated as if ..."
>
> It might also be worth mentioning explicitly that FrozenTransactionId
> can appear on-disk in old installations. And I'd be slightly tempted
> to put in an explanation of BootstrapTransactionId, because users
> will see that as well if they look into any system catalogs.
>
> Comments?
>
> regards, tom lane
>
>

Egor Rogov <e(dot)rogov(at)postgrespro(dot)ru> writes:
> Right, it does not say that FrozenTransactionId is what appears on disk,
> but what is? There is no such information anywhere in the doc. Since 9.4
> frozen transactions have their normal XIDs preserved, so how a user can
> tell normal transaction from frozen one? This is what needs to be
> explained, I believe.

I'm afraid the answer is "you can't tell". The infomask bits in tuple
headers aren't exposed via SQL. If you're really desperate,
contrib/pageinspect would help, but I don't propose mentioning that here.

In general, I'm not really sure why users would care very much at
a tuple-by-tuple level. Aggregate statistics would be interesting,
which raises the question why contrib/pgstattuple doesn't provide
frozen-tuples counts.

regards, tom lane

I pushed some edits based on this discussion at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=975768f8eae2581b89ceafe8b16a77ff375207fe

regards, tom lane

On 06.09.2016 23:41, Tom Lane wrote:
> Egor Rogov <e(dot)rogov(at)postgrespro(dot)ru> writes:
>> Right, it does not say that FrozenTransactionId is what appears on disk,
>> but what is? There is no such information anywhere in the doc. Since 9.4
>> frozen transactions have their normal XIDs preserved, so how a user can
>> tell normal transaction from frozen one? This is what needs to be
>> explained, I believe.
> I'm afraid the answer is "you can't tell". The infomask bits in tuple
> headers aren't exposed via SQL. If you're really desperate,
> contrib/pageinspect would help, but I don't propose mentioning that here.
>
> In general, I'm not really sure why users would care very much at
> a tuple-by-tuple level.

"Normal" users shouldn't care of course, but DBAs sometimes have to. The
old description could be easily misunderstood and one might expect to
see FrozenTransactionId in xmin field (I know several people who wasted
hours trying to figure out what's wrong with vacuum freeze). Now the
description is much cleaner, thanks!

> Aggregate statistics would be interesting,
> which raises the question why contrib/pgstattuple doesn't provide
> frozen-tuples counts.
>
> regards, tom lane
>
>
Regards,
Egor Rogov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company