gzip surprisingly emits a lot of zeroes when compression ratio is high.
It triggered branch where FIO_PAGE_ZERO is emitted in agent but not handled
in fio_sned_file_gz properly.
Fix it.
Looks like "seek after file end and write" doesn't work
correctly in Windows. We have to grow file before.
Met occasionally on GitHub actions run. Could not reproduce
locally.
pg_multixact contains files which looks like db files,
but they are not.
get_backup_filelist should not pass to set_forkname files
not in db folder nor `global` folder.
- properly chain only main fork and cfs related forks
- properly chain datafile with its cfm even sort order places other
segments between
- don't raise error for system tables which has no companion cfm.
+ fix couple of tests
Error message is translated according to current locale. So we can't
compare it as a string. But `abortedRecPtr` exists exactly for this case,
so we can rely on it.
to make two backups in one second we have to fail them.
Therefore we have to fetch backup_id from log in exception's message.
Retry for 20 seconds to have a chance to start in one second.
If we couldn't, lets skip the test.
zlib decompression could mark error either as "data error" or
"buffer error". One of check did consider it, other didn't.
Make them same.
And use `assertRaises` for good (requires python 3.2 at least)
Pg15 now reports if it didn't met expected contrecord. Absence of this
message was long standing bug in previous postgres versions.
This situation could happen if WAL segment was rewritten after restart.
It causes "tests.validate.ValidateTest.test_validate_wal_unreal_values"
to hang but (looks like) for other reason: test tries to read "in future".
Probably we should stop reading logs here. But since we always did
continue here, lets continue as well.
Looks like os.walk may yield dirs unsorted.
This way "check if directory already here as part of larger directory"
man mistakenly skip short 'base/1' as "part of" 'base/12699'
Got in some tests:
```
Traceback (most recent call last):
File "pg_probackup/tests/replica.py", line 625, in test_replica_stop_lsn_null_offset
gdb_checkpointer = self.gdb_attach(bgwriter_pid)
File "pg_probackup/tests/helpers/ptrack_helpers.py", line 1984, in gdb_attach
return GDBobj([str(pid)], self, attach=True)
File "pg_probackup/tests/helpers/ptrack_helpers.py", line 2054, in __init__
line = self.get_line()
File "pg_probackup/tests/helpers/ptrack_helpers.py", line 2065, in get_line
line = self.proc.stdout.readline()
File "/usr/lib/python3.10/codecs.py", line 322, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd0 in position 189: invalid continuation byte
```
Fixed with `errors='replace'`
and BugTest.test_minrecpoint_on_replica as well
Tests were broken with introduction of "startness" handling in
9924ab014 [PBCKP-304] extended testgres.PosgresNode to ...
since tests uses os.kill directly.
Here we assume backup_id == start_time.
It is really so at the moment, but could change in future.
Well, it almost always same. Sometime backup_id is set
while start_time is not set yet (backup creation). And
we had to fix places where start_time were changed without
change of backup_id.
C99 introduced compound literals (`(char[14]){0}` - literal of array).
Compound literals have same lifetime as block local variable, ie till
the end of block. There for it is save to initiate several of them in
same block and assume they are all live.
This way we may rewrite base36enc into macros which uses compound
literal instead of static variable to extend its result lifetime.
Fork detection were broken before set_forkname extraction, and its bug
were copied into.
Lets reimplement it to be like `parse_filename_for_nonetemp_relation` in
PostgreSQL code.
- store cfm files truncated to non-zero head with coarse granularity
(64-4096 bytes)
- and calculate crc for truncated file
- during restoration calculate crc for cfm as if it was truncated
With autovacuum enabled tests are unstable. Especially they are unstable
if postgresql is running under valgrind and therefore is severely
inhibited (and vacuum has time to be triggered).
Yura Sokolov
