Fix typo in PostgreSQL 10.0 release note.
Patch by Yugo Nagata.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/e800656d9a9b40b2f55afabe76354ab6d93353b3
Modified Files
--
doc/src/sgml/release-10.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
> 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
Tatsuo Ishii 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
> 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
Tatsuo Ishii 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 o
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.42562793978
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.42562793978
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.42562793978
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.42562793978
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.42562793978
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.42562793978
Robert Haas writes:
> Fix problems related to RangeTblEntry members enrname and enrtuples.
> Commit 18ce3a4ab22d2984f8540ab480979c851dae5338 failed to update
> the comments in parsenodes.h for the new members, and made only
> incomplete updates to src/backend/nodes
This really should have involve
Fix problems related to RangeTblEntry members enrname and enrtuples.
Commit 18ce3a4ab22d2984f8540ab480979c851dae5338 failed to update
the comments in parsenodes.h for the new members, and made only
incomplete updates to src/backend/nodes
Thomas Munro, per a report from Noah Misch.
Discussion: ht
Don't force-assign transaction id when exporting a snapshot.
Previously we required every exported transaction to have an xid
assigned. That was used to check that the exporting transaction is
still running, which in turn is needed to guarantee that that
necessary rows haven't been removed in betw
Use DEFACLOBJ_ macros in error message instead of hardcoding
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/b6966d4627c0297ad42fe2592c66ac2f76e9962e
Modified Files
--
src/backend/catalog/objectaddress.c | 9 +++--
src/test/regress/expected/o
Add missing serial comma
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/4e88fe8f8f148a45feacb50c2eaed9ca9ddea8bb
Modified Files
--
src/bin/pg_basebackup/pg_basebackup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Sent via pgsql-committers
doc: Whitespace fixes in man pages
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/f0cfff9da2c577a19dd6a15ffc7b404693b700bc
Modified Files
--
doc/src/sgml/ref/alter_aggregate.sgml | 3 +--
doc/src/sgml/ref/alter_publication.sgml | 3 +--
doc/src/
Teach predtest.c about CHECK clauses to fix partitioning bugs.
In a CHECK clause, a null result means true, whereas in a WHERE clause
it means false. predtest.c provided different functions depending on
which set of semantics applied to the predicate being proved, but had
no option to control wha
Improve release note text about set-returning-function changes.
Paul Ramsey griped about this awhile ago, but I'd been holding fire
on changing it until we settled what to do about the CASE/COALESCE
issue.
Discussion:
https://postgr.es/m/CACowWR0AMyUt5fwtvuDqWyYNdp-hQJj9XqSxJR6YM9sKWov=_...@mail
Avoid bogus TwoPhaseState locking sequences
The optimized code in 728bd991c3c4 contains a few invalid locking
sequences. To wit, the original code would try to acquire an lwlock
that it already holds. Avoid this by moving lock acquisitions to
higher-level code, and install appropriate assertions
Put documentation of options and commands in more alphabetical order
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/0d9bdbcaae00dac89a82c25e66e4a859130e2fe8
Modified Files
--
doc/src/sgml/ref/initdb.sgml | 4 +-
doc/src/sgml/ref/pg_dump.sgml | 28 +++
Fix no-longer-valid shortcuts in expression_returns_set().
expression_returns_set() used to short-circuit its recursion upon
seeing certain node types, such as DistinctExpr, that it knew the
executor did not support set-valued arguments for. That was never
inherent, though, just a reflection of l
Fix violations of CatalogTupleInsert/Update/Delete abstraction.
In commits 2f5c9d9c9 and ab0289651 we invented an abstraction layer
to insulate catalog manipulations from direct heap update calls.
But evidently some patches that hadn't landed in-tree at that point
didn't get the memo completely.
Teach PL/pgSQL about partitioned tables.
Table partitioning, introduced in commit f0e44751d7, added a new
relkind - RELKIND_PARTITIONED_TABLE. Update a couple of places in
PL/pgSQL to handle it. Specifically plpgsql_parse_cwordtype() and
build_row_from_class() needed updating in order to make tabl
Teach RemoveRoleFromObjectPolicy() about partitioned tables.
Table partitioning, introduced in commit f0e44751d7, added a new
relkind - RELKIND_PARTITIONED_TABLE. Update
RemoveRoleFromObjectPolicy() to handle it, otherwise DROP OWNED BY
will fail if the role has any RLS policies referring to parti
25 matches
Mail list logo