Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Dilip Kumar <dilipbalaut@gmail.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Tighten the concurrent abort check during decoding.
- 2ce353fc1902 14.0 landed
-
Improve hash_create()'s API for some added robustness.
- b3817f5f7746 14.0 landed
-
Use HASH_BLOBS for xidhash.
- a1b8aa1e4eec 14.0 landed
-
Fix initialization of RelationSyncEntry for streaming transactions.
- 69bd60672af6 14.0 landed
-
Remove unused function declaration in logicalproto.h.
- ddd5f6d2609b 14.0 landed
-
Add additional tests to test streaming of in-progress transactions.
- 58b5ae9d62bd 14.0 landed
-
Fix inline marking introduced in commit 464824323e.
- ac15b499f7f9 14.0 landed
-
Add support for streaming to built-in logical replication.
- 464824323e57 14.0 landed
-
Fix the SharedFileSetUnregister API.
- 4ab77697f67a 14.0 landed
-
Fix comment in procarray.c
- 77c7267c37f7 14.0 cited
-
Suppress compiler warning in non-cassert builds.
- e942af7b8261 14.0 cited
-
Extend the BufFile interface.
- 808e13b282ef 14.0 landed
-
Mark a few logical decoding related variables with PGDLLIMPORT.
- b48cac3b10a0 14.0 landed
-
Implement streaming mode in ReorderBuffer.
- 7259736a6e5b 14.0 landed
-
Extend the logical decoding output plugin API with stream methods.
- 45fdc9738b36 14.0 landed
-
WAL Log invalidations at command end with wal_level=logical.
- c55040ccd017 14.0 landed
-
Immediately WAL-log subtransaction and top-level XID association.
- 0bead9af484c 14.0 landed
-
Allow logical replication to transfer data in binary format.
- 9de77b545313 14.0 cited
-
Only superuser can set sslcert/sslkey in postgres_fdw user mappings
- cebf9d6e6ee1 13.0 cited
-
Track statistics for spilling of changes from ReorderBuffer.
- 9290ad198b15 13.0 landed
-
Add logical_decoding_work_mem to limit ReorderBuffer memory usage.
- cec2edfa7859 13.0 landed
-
logical decoding: process ASSIGNMENT during snapshot build
- bac2fae05c77 13.0 cited
-
Emit invalidations to standby for transactions without xid.
- c6ff84b06a68 9.6.0 cited
On Tue, Apr 14, 2020 at 9:14 PM Erik Rijkers <er@xs4all.nl> wrote: > > On 2020-04-14 12:10, Dilip Kumar wrote: > > > v14-0001-Immediately-WAL-log-assignments.patch + > > v14-0002-Issue-individual-invalidations-with.patch + > > v14-0003-Extend-the-output-plugin-API-with-stream-methods.patch+ > > v14-0004-Gracefully-handle-concurrent-aborts-of-uncommitt.patch+ > > v14-0005-Implement-streaming-mode-in-ReorderBuffer.patch + > > v14-0006-Add-support-for-streaming-to-built-in-replicatio.patch+ > > v14-0007-Track-statistics-for-streaming.patch + > > v14-0008-Enable-streaming-for-all-subscription-TAP-tests.patch + > > v14-0009-Add-TAP-test-for-streaming-vs.-DDL.patch + > > v14-0010-Bugfix-handling-of-incomplete-toast-tuple.patch > > applied on top of 8128b0c (a few hours ago) > > Hi, > > I haven't followed this thread and maybe this instabilty is > known/expected; just thought I'd let you know. > > When doing running a pgbench run over logical replication (cascading > down two replicas), I get this segmentation fault. Thanks for the testing. Is it possible to share the call stack? > > 2020-04-14 17:27:28.135 CEST [8118] DETAIL: Streaming transactions > committing after 0/5FA2A38, reading WAL from 0/5FA2A00. > 2020-04-14 17:27:28.135 CEST [8118] LOG: logical decoding found > consistent point at 0/5FA2A00 > 2020-04-14 17:27:28.135 CEST [8118] DETAIL: There are no running > transactions. > 2020-04-14 17:27:28.138 CEST [8006] LOG: server process (PID 8118) was > terminated by signal 11: Segmentation fault > 2020-04-14 17:27:28.138 CEST [8006] DETAIL: Failed process was running: > COMMIT > 2020-04-14 17:27:28.138 CEST [8006] LOG: terminating any other active > server processes > 2020-04-14 17:27:28.138 CEST [8163] WARNING: terminating connection > because of crash of another server process > 2020-04-14 17:27:28.138 CEST [8163] DETAIL: The postmaster has > commanded this server process to roll back the current transaction and > exit, because another server process exited abnormally and possibly > corrupted shared memory. > 2020-04-14 17:27:28.138 CEST [8163] HINT: In a moment you should be > able to reconnect to the database and repeat your command. > > > This error happens somewhat buried away in my test-stuff; I can dig it > out and make it into a repeatable test if you need it. (debian > stretch/gcc 9.3.0) Yeah, that will be great. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com