Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WAL segment system-id does not match archive system-id #445

Closed
javierwilson opened this issue Nov 16, 2017 · 13 comments
Closed

WAL segment system-id does not match archive system-id #445

javierwilson opened this issue Nov 16, 2017 · 13 comments
Assignees
Milestone

Comments

@javierwilson
Copy link

javierwilson commented Nov 16, 2017

  1. pgBackRest version: 1.25 - 32bit

  2. PostgreSQL version: 9.4 - 32bit

  3. Operating system/version - if you have more than one server (for example, a database server, a backup host server, one or more standbys), please specify each: Ubuntu 14.03 - 32bit

  4. Did you install pgBackRest from source or from a package? apt-get

  5. Describe the issue:
    I have the same issue as ERROR [044]: : WAL segment system-id does not match archive system-id  #432
    also running on a 32bit system, the WAL system-id doesn't match the archiive system-id, or so claims pgbackrest.
    I did an hexdump of the WAL file and I can see the system-id is correct, only pgbackrest is usin the wrong offset, the issue gets fixed if I set PG_WAL_SYSTEM_ID_OFFSET_GTE_93 = 16, instead of 20. I wonder is this is something that affects only 32bit systems. See https://github.com/pgbackrest/pgbackrest/blob/master/lib/pgBackRest/Archive/Common.pm#L35

@javierwilson
Copy link
Author

Quoting https://wiki.postgresql.org/images/a/af/FOSDEM-2015-New-WAL-format.pdf
the XLogRecord in 9.4 and below uses 32 bytes in total (but 28 on 32-bit systems), 4 bytes less, so it makes sense to lower this to 16 if arch is 32bit. Other messages on postgresql mailing list confirm this.

@dwsteele dwsteele self-assigned this Nov 16, 2017
@dwsteele dwsteele added this to the 1.26 milestone Nov 16, 2017
@dwsteele
Copy link
Member

Hi Javier,

You are correct about the alignment being different on 32-bit architectures.

We have tests (https://anonscm.debian.org/cgit/pkg-postgresql/pgbackrest.git/tree/debian/tests/suite) which should run on all architectures. The tests are pretty basic but should have caught this.

Any idea why the tests did not catch this, @disco-stu?

@disco-stu
Copy link
Contributor

The only test we run automatically on i386 (and all other architectures) is "make test" of the libc module. However, that test passes [1].

Unfortunately ci.debian.net (which automatically runs the full suite) doesn't run on architectures others than amd64 [2]. I would like to have autopkg-tests on all architectures, but that's future stuff.

[1] https://buildd.debian.org/status/fetch.php?pkg=pgbackrest&arch=i386&ver=1.25-1&stamp=1509026334&raw=0
[2] https://ci.debian.net/packages/p/pgbackrest/

@dwsteele
Copy link
Member

Thank you for the clarification, Adrian! Let me know if there's anything I can do to move the autopkg-tests stuff along. I'm working on getting the bulk of the test suite running without Docker. Currently, only the S3 tests won't run that way.

@javierwilson - did everything work once you made the offset change?

@javierwilson
Copy link
Author

Yes it did... pgbackrest working happily. I basically did an hexdump of several WAL files to confirm the system-id

@dwsteele
Copy link
Member

Thanks - I will make that change for 1.26, then. Can you run:

perl -V:ivsize

And send me the result? It should be ivsize='4'.

@javierwilson
Copy link
Author

$ uname -a
Linux example 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:12 UTC 2014 i686 i686 i686 GNU/Linux

$ perl -V:ivsize
ivsize='8';

shrug

@dwsteele
Copy link
Member

How about:

perl -V:ptrsize

@javierwilson
Copy link
Author

$ perl -V:ptrsize
ptrsize='4';

that is actually different from other 64bit servers

@dwsteele
Copy link
Member

OK - we'll go with that. This next version is the last in the 1.X line (except for bug fixes). Version 2.x will require the C library and then I can push all this logic down into C and pull structures straight from the Postgres source.

Thanks for testing those out for me!

@javierwilson
Copy link
Author

cool, thank you for all your work!

@dwsteele
Copy link
Member

Fixed at 550d4fb.

@lock
Copy link

lock bot commented Jul 23, 2019

This thread has been automatically locked. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Jul 23, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants