Re: refactoring basebackup.c
Dmitry Dolgov <9erthalion6@gmail.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Document BaseBackupSync and BaseBackupWrite wait events.
- 749320cdc3fd 15.3 landed
- 4b1ad19a4e22 16.0 landed
-
Support long distance matching for zstd compression
- 2820adf7755d 16.0 landed
-
Fix possible NULL-pointer-deference in backup_compression.c.
- 8e053dc6dfbe 15.0 landed
-
Allow parallel zstd compression when taking a base backup.
- 51c0d186d99a 15.0 landed
-
Make PostgreSQL::Test::Cluster::run_log() return a useful value.
- ad4f2c47de44 15.0 landed
-
Fix a few goofs in new backup compression code.
- 61762426e6ed 15.0 landed
-
Replace BASE_BACKUP COMPRESSION_LEVEL option with COMPRESSION_DETAIL.
- ffd53659c46a 15.0 landed
-
Add 'basebackup_to_shell' contrib module.
- c6306db24bd9 15.0 landed
-
Allow extensions to add new backup targets.
- e4ba69f3f4a1 15.0 landed
-
Change HAVE_LIBLZ4 and HAVE_LIBZSTD tests to USE_LZ4 and USE_ZSTD.
- 75eae090876f 15.0 landed
-
pg_basebackup: Clean up some bogus file extension tests.
- d6f1cdeb9a9e 15.0 landed
-
pg_basebackup: Avoid unclean failure with server-compression and -D -.
- b2de45f9200d 15.0 landed
-
Fix LZ4 tests for remaining buffer space.
- 1d4be6be65ab 15.0 landed
-
Add support for zstd base backup compression.
- 7cf085f077df 15.0 landed
-
pg_basebackup: Allow client-side LZ4 (de)compression.
- 751b8d23b788 15.0 landed
-
Add suport for server-side LZ4 base backup compression.
- dab298471ff2 15.0 landed
-
Add min() and max() aggregates for xid8.
- 400fc6b6487d 15.0 cited
-
Remove superfluous variable.
- 82331ed4dd60 15.0 landed
-
pg_basebackup: Cleaner handling when compression is multiply specified.
- 51891d5a9560 15.0 landed
-
Allow server-side compression to be used with -Fp.
- d45099425eb1 15.0 landed
-
pg_basebackup: Fix a couple of recently-introduced bugs.
- dabf63bc9a5b 15.0 landed
-
Tidy up a few cosmetic issues related to pg_basebackup.
- e1f860f13459 15.0 landed
-
Server-side gzip compression.
- 0ad8032910d5 15.0 landed
-
Unbreak pg_basebackup/t/010_pg_basebackup.pl on msys
- 4f0bcc735038 15.0 cited
-
Suppress variable-set-but-not-used warning from clang 13.
- dc43fc9b3aa3 15.0 cited
-
Extend the options of pg_basebackup to control compression
- 5c649fe15336 15.0 cited
-
Support base backup targets.
- 3500ccc39b0d 15.0 landed
-
Modify pg_basebackup to use a new COPY subprotocol for base backups.
- cc333f32336f 15.0 landed
-
Document that tar archives are now properly terminated.
- 81fca310b38e 15.0 landed
-
Fix thinko in bbsink_throttle_manifest_contents.
- 1b098da20093 15.0 landed
-
Have the server properly terminate tar archives.
- 5a1007a5088c 15.0 landed
-
Minimal fix for unterminated tar archive problem.
- 57b5a9646d97 15.0 landed
-
Introduce 'bbstreamer' abstraction to modularize pg_basebackup.
- 23a1c6578c87 15.0 landed
-
Introduce 'bbsink' abstraction to modularize base backup code.
- bef47ff85df1 15.0 landed
-
Refactor basebackup.c's _tarWriteDir() function.
- 967a17fe2fa7 15.0 landed
-
Flexible options for CREATE_REPLICATION_SLOT.
- 0266e98c6b86 15.0 landed
-
Flexible options for BASE_BACKUP.
- 0ba281cb4bf9 15.0 landed
> On Fri, Nov 05, 2021 at 11:50:01AM -0400, Robert Haas wrote:
> On Tue, Nov 2, 2021 at 10:32 AM Robert Haas <robertmhaas@gmail.com> wrote:
> > Meanwhile, I think it's probably OK for me to go ahead and commit
> > 0001-0003 from my patches at this point, since it seems we have pretty
> > good evidence that the abstraction basically works, and there doesn't
> > seem to be any value in holding off and maybe having to do a bunch
> > more rebasing.
>
> I went ahead and committed 0001 and 0002, but got nervous about
> proceeding with 0003.
Hi,
I'm observing a strange issue which I can only relate to bef47ff85d
where bbsink abstraction was introduced. The problem is about failing
assertion when doing:
DETAIL: Failed process was running: BASE_BACKUP ( LABEL 'pg_basebackup base backup', PROGRESS, WAIT 0, MAX_RATE 102400, MANIFEST 'yes')
Walsender tries to send a backup manifest, but crashes on the trottling sink:
#2 0x0000560857b551af in ExceptionalCondition (conditionName=0x560857d15d27 "sink->bbs_next != NULL", errorType=0x560857d15c23 "FailedAssertion", fileName=0x560857d15d15 "basebackup_sink.c", lineNumber=91) at assert.c:69
#3 0x0000560857918a94 in bbsink_forward_manifest_contents (sink=0x5608593f73f8, len=32768) at basebackup_sink.c:91
#4 0x0000560857918d68 in bbsink_throttle_manifest_contents (sink=0x5608593f7450, len=32768) at basebackup_throttle.c:125
#5 0x00005608579186d0 in bbsink_manifest_contents (sink=0x5608593f7450, len=32768) at ../../../src/include/replication/basebackup_sink.h:240
#6 0x0000560857918b1b in bbsink_forward_manifest_contents (sink=0x5608593f74e8, len=32768) at basebackup_sink.c:94
#7 0x0000560857911edc in bbsink_manifest_contents (sink=0x5608593f74e8, len=32768) at ../../../src/include/replication/basebackup_sink.h:240
#8 0x00005608579129f6 in SendBackupManifest (manifest=0x7ffdaea9d120, sink=0x5608593f74e8) at backup_manifest.c:373
Looking at the similar bbsink_throttle_archive_contents it's not clear
why comments for both functions (archive and manifest throttling) say
"pass archive contents to next sink", but only bbsink_throttle_manifest_contents
does pass bbs_next into the bbsink_forward_manifest_contents. Is it
supposed to be like that? Passing the same sink object instead the next
one into bbsink_forward_manifest_contents seems to solve the problem in
this case.