Обсуждение: [COMMITTERS] pgsql: Fix document bug regarding read only transactions.
Fix document bug regarding read only transactions. It was explained that read only transactions (not in standby) allow to update sequences. This had been wrong since the commit: 05d8a561ff85db1545f5768fe8d8dc9d99ad2ef7 Discussion: https://www.postgresql.org/message-id/20170614.110826.425627939780392324.t-ishii%40sraoss.co.jp Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/6108348c09df33773bed6e0ac762fe47bdcbb9e6 Modified Files -------------- doc/src/sgml/high-availability.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Tatsuo Ishii <ishii@postgresql.org> writes:
> Fix document bug regarding read only transactions.
> It was explained that read only transactions (not in standby) allow to
> update sequences. This had been wrong since the commit:
> 05d8a561ff85db1545f5768fe8d8dc9d99ad2ef7
This new text is not any more accurate than the old, it's just wrong
in the other direction. The actual behavior is still what's stated
in the commit message for that commit: read-only transactions on the
master are allowed to do nextval() on temp sequences but not permanent
ones.
regression=# create temp sequence s1;
CREATE SEQUENCE
regression=# create sequence s2;
CREATE SEQUENCE
regression=# begin transaction read only;
BEGIN
regression=# select nextval('s1');
nextval
---------
1
(1 row)
regression=# select nextval('s2');
ERROR: cannot execute nextval() in a read-only transaction
I think the correct fix would have been to change "update sequences"
to "update temporary sequences", not to remove it.
regards, tom lane
> I think the correct fix would have been to change "update sequences" > to "update temporary sequences", not to remove it. Not sure. The paragraph tries to explain the difference between read only transactions and standby. --------------------------------------------------------------- In normal operation, “read-only” transactions are allowed to update sequences and to use LISTEN, UNLISTEN, and NOTIFY, so Hot Standby sessions operate under slightly tighter restrictions than ordinary read-only sessions. It is possible that some of these restrictions might be loosened in a future release. --------------------------------------------------------------- Regarding sequences, the paragraph supposes the use case on standby in that a normal sequence was created on primary then it gets updated on standby (that was used be possible). For temporary sequences, this scenario is totally meaningless since temporary sequences are not replicated, nor cannot be created on standby either. So I think referring to temporary sequences here is pointless. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
Tatsuo Ishii <ishii@sraoss.co.jp> writes:
>> I think the correct fix would have been to change "update sequences"
>> to "update temporary sequences", not to remove it.
> Not sure. The paragraph tries to explain the difference between read
> only transactions and standby.
Right, but what I think it is comparing is a read-only transaction
on the master and a transaction on the standby. The former can do
nextval() on temp sequences, the latter can't.
regards, tom lane
> Right, but what I think it is comparing is a read-only transaction > on the master and a transaction on the standby. The former can do > nextval() on temp sequences, the latter can't. But we cannot create temp sequences on stanbys in the first place. Still do you think there's value to refer to nextval() on temp sequences here? Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
Tatsuo Ishii <ishii@sraoss.co.jp> writes:
>> Right, but what I think it is comparing is a read-only transaction
>> on the master and a transaction on the standby. The former can do
>> nextval() on temp sequences, the latter can't.
> But we cannot create temp sequences on stanbys in the first place.
> Still do you think there's value to refer to nextval() on temp
> sequences here?
You're right that the statement is irrelevant in the context of what
a standby can or can't do, but what I'm worried about is that someone
will read it and believe that it represents the whole truth about
what read-only master transactions can do. The previous wording was
also irrelevant to the context of a standby, and yet this whole thread
exists because somebody complained that it's an inaccurate description
of the restrictions on such a master transaction. Well, it's still
inaccurate.
regards, tom lane
> You're right that the statement is irrelevant in the context of what > a standby can or can't do, but what I'm worried about is that someone > will read it and believe that it represents the whole truth about > what read-only master transactions can do. The previous wording was > also irrelevant to the context of a standby, and yet this whole thread > exists because somebody complained that it's an inaccurate description > of the restrictions on such a master transaction. Well, it's still > inaccurate. Then I think we should add more commands including ANALYZE, VACUUM and strong LOCKS here. There's no specific reason to pick up only nextval(), LISTEN and NOTIFY. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp