Re: missing documentation for streaming in-progress transactions

From: "Euler Taveira" <euler(at)eulerto(dot)com>
To: "Ajin Cherian" <itsajin(at)gmail(dot)com>, "Peter Smith" <smithpb2250(at)gmail(dot)com>
Cc: "Amit Kapila" <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "Dilip Kumar" <dilipbalaut(at)gmail(dot)com>
Subject: Re: missing documentation for streaming in-progress transactions
Date: 2021-04-09 00:23:02
Message-ID: d01e595a-a465-495b-b166-a60125abcd5c@www.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 8, 2021, at 4:25 AM, Ajin Cherian wrote:
> Updated.

- Protocol version. Currently only version <literal>1</literal> is
- supported.
- </para>
+ Protocol version. Currently versions <literal>1</literal> and
+ <literal>2</literal> are supported. The version <literal>2</literal>
+ is supported only for server versions 14 and above, and is used to allow
+ streaming of large in-progress transactions.
+ </para>

s/server versions/server version/

I suggest that the last part of the sentence might be "and it allows streaming
of large in-progress transactions"

+ Since: 2
+</para>
+<para>

I didn't like this style because it is not descriptive enough. It is also not a
style adopted by Postgres. I suggest to add something like "This field was
introduced in version 2" or "This field is available since version 2" after the
field description.

+ Xid of the sub-transaction (will be same as xid of the transaction for top-level
+ transactions).
+</para>

Although, sub-transaction is also used in the documentation, I suggest to use
subtransaction. Maybe change the other sub-transaction occurrences too.

--
Euler Taveira
EDB https://www.enterprisedb.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message kuroda.hayato@fujitsu.com 2021-04-09 00:23:07 RE: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Previous Message Michael Paquier 2021-04-09 00:21:52 Re: Simplify backend terminate and wait logic in postgres_fdw test