Re: [DOCS] FrozenTransactionId

2016-09-06 Thread Egor Rogov 

Sorry, my last email went without the attachment.

On 06.09.2016 01:09, Egor Rogov wrote:
Tom Lane <[hidden email] 
> 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 




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

diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 2713883..7d1ee4e 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -406,26 +406,23 @@
 

 The reason that periodic vacuuming solves the problem is that
-VACUUM will mark rows as frozen, indicating that
+VACUUM will mark rows as frozen (by setting appropriate hint bits), indicating that
 they were inserted by a transaction which committed sufficiently far in
 the past that the effects of the inserting transaction is certain to be
 visible, from an MVCC perspective, to all current and future transactions.
-PostgreSQL reserves a special XID,
-FrozenTransactionId, which does not follow the normal XID
-comparison rules and is always considered older
-than every normal XID. Normal XIDs are
+Usually XIDs are
 compared using modulo-232 arithmetic. This means
-that for every normal XID, there are two billion XIDs that are
+that for every XID, there are two billion XIDs that are
 older and two billion that are newer; another
-way to say it is that the normal XID space is circular with no
+way to say it is that the XID space is circular with no
 endpoint. Therefore, once a row version has been created with a particular
-normal XID, the row version will appear to be in the past for
-the next two billion transactions, no matter which normal XID we are
-talking about. If the row version still exists after more than two billion
+XID, the row version will appear to be in the past for
+the next two billion transactions.
+If the row version still exists after more than two billion
 transactions, it will suddenly appear to be in the future. To
-prevent this, frozen row versions are treated as if the inserting XID were
-FrozenTransactionId, so that they will appear to be
-in the past to all normal transactions regardless of wraparound
+prevent this, usual visibility rules are not applied to frozen row versions.
+Instead they are considered to be
+in the past to all transactions regardless of wraparound
 issues, and so such row versions will be valid until deleted, no matter
 how long that is.


-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] FrozenTransactionId

2016-09-06 Thread Tom Lane 
Egor Rogov  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


-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

[DOCS] Foreign Table docs are way to brief.

2016-09-06 Thread mark0978 
The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/9.1/static/sql-dropforeigntable.html
Description:

I see DROP FOREIGN TABLE and wonder if it actually deletes data like DROP
TABLE would do.

What does it mean to CREATE FOREIGN TABLE?  Is it just a mapping onto
external data, or am I creating a table in the other database.

Too few words given over to helping me understand what FOREIGN brings to the
table in all these commands.

-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] FrozenTransactionId

2016-09-06 Thread Egor Rogov 

On 06.09.2016 15:41, Tom Lane wrote:

Egor Rogov  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






--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] FrozenTransactionId

2016-09-06 Thread Tom Lane 
Egor Rogov  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


-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] FrozenTransactionId

2016-09-06 Thread 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


-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] FrozenTransactionId

2016-09-06 Thread Egor Rogov 

On 06.09.2016 23:41, Tom Lane wrote:

Egor Rogov  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



--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] Foreign Table docs are way to brief.

2016-09-06 Thread Michael Paquier 
On Mon, Sep 5, 2016 at 11:22 AM,   wrote:
> Too few words given over to helping me understand what FOREIGN brings to the
> table in all these commands.

Patches for improvements are welcome if you think that's worth it. Now
there is this bit in the documentation that explains the concept of
foreign objects, so it is not like there is nothing on the matter:
https://www.postgresql.org/docs/9.6/static/ddl-foreign-data.html
-- 
Michael


-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs