On Thu, Nov 21, 2019 at 10:03:27PM +0900, Fujii Masao wrote:
> Thanks for pointing out that! Since the format of XLOG_DBASE_DROP WAL
> record was changed, XLOG_PAGE_MAGIC must be bumped. Will do that.
Yep, thanks for fixing.
--
Michael
signature.asc
Description: PGP signature
Remove traces of version-0 calling convention in src/tutorial/
Support has been removed as of 5ded4bd, but code related to the tutorial
still used it. Functions using version-1 are already present for some
time in the tutorial, and the documentation mentions them, so just
replace the old version
Add .gitignore to src/tutorial/
A set of SQL files are generated for the tutorial when compiling the
code, so let's avoid any risk to have them added in the tree in the
future.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/8959a5e0fa2926b0f99e055e63fb4d81e1dcb3a0
Fix bogus tuple-slot management in logical replication UPDATE handling.
slot_modify_cstrings seriously abused the TupleTableSlot API by relying
on a slot's underlying data to stay valid across ExecClearTuple. Since
this abuse was also quite undocumented, it's little surprise that the
case got bro
Fix bogus tuple-slot management in logical replication UPDATE handling.
slot_modify_cstrings seriously abused the TupleTableSlot API by relying
on a slot's underlying data to stay valid across ExecClearTuple. Since
this abuse was also quite undocumented, it's little surprise that the
case got bro
Fix bogus tuple-slot management in logical replication UPDATE handling.
slot_modify_cstrings seriously abused the TupleTableSlot API by relying
on a slot's underlying data to stay valid across ExecClearTuple. Since
this abuse was also quite undocumented, it's little surprise that the
case got bro
Fix bogus tuple-slot management in logical replication UPDATE handling.
slot_modify_cstrings seriously abused the TupleTableSlot API by relying
on a slot's underlying data to stay valid across ExecClearTuple. Since
this abuse was also quite undocumented, it's little surprise that the
case got bro
Add test coverage for "unchanged toast column" replication code path.
It seems pretty unacceptable to have no regression test coverage
for this aspect of the logical replication protocol, especially
given the bugs we've found in related code.
Discussion: https://postgr.es/m/16129-a0c0f48e71741...
Add test coverage for "unchanged toast column" replication code path.
It seems pretty unacceptable to have no regression test coverage
for this aspect of the logical replication protocol, especially
given the bugs we've found in related code.
Discussion: https://postgr.es/m/16129-a0c0f48e71741...
Add test coverage for "unchanged toast column" replication code path.
It seems pretty unacceptable to have no regression test coverage
for this aspect of the logical replication protocol, especially
given the bugs we've found in related code.
Discussion: https://postgr.es/m/16129-a0c0f48e71741...
Add test coverage for "unchanged toast column" replication code path.
It seems pretty unacceptable to have no regression test coverage
for this aspect of the logical replication protocol, especially
given the bugs we've found in related code.
Discussion: https://postgr.es/m/16129-a0c0f48e71741...
Avoid taking a new snapshot for an immutable simple expression in plpgsql.
We already used this optimization if the plpgsql function is read-only.
But it seems okay to do it even in a read-write function, if the
expression contains only immutable functions/operators. There would
only be a change
Make psql redisplay the query buffer after \e.
Up to now, whatever you'd edited was put back into the query buffer
but not redisplayed, which is less than user-friendly. But we can
improve that just by printing the text along with a prompt, if we
enforce that the editing result ends with a newlin
13 matches
Mail list logo
