Postgresql BDR problem compiling pluging

postgresqlpostgresql-bdr

I'm trying to build deb packages for postgresql BDR plugin, but I'm getting the following error:

gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -I/usr/include/mit-krb5 -fPIC -pie -DLINUX_OOM_SCORE_ADJ=0 -fno-omit-frame-pointer -fpic -I/usr/include/postgresql -I. -I./ -I/usr/include/postgresql/9.4/server -I/usr/include/postgresql/internal -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I/usr/include/libxml2  -I/usr/include/tcl8.6  -c -o pg_resetxlog.o pg_resetxlog.c
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -I/usr/include/mit-krb5 -fPIC -pie -DLINUX_OOM_SCORE_ADJ=0 -fno-omit-frame-pointer -fpic pg_resetxlog.o -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -L/usr/lib/mit-krb5 -L/usr/lib/x86_64-linux-gnu/mit-krb5  -Wl,--as-needed  -L/usr/lib/x86_64-linux-gnu -lpgcommon -lpgport -L/usr/lib/x86_64-linux-gnu -lpq -lpgcommon -lpgport -lselinux -lxslt -lxml2 -lpam -lssl -lcrypto -lgssapi_krb5 -lz -ledit -lrt -lcrypt -ldl -lm  -o bdr_resetxlog
pg_resetxlog.o: In function `memcpy':
/usr/include/x86_64-linux-gnu/bits/string3.h:51: undefined reference to `pg_crc32_table'
pg_resetxlog.o: In function `RewriteControlFile':
/var/lib/postgresql/src/bdr-plugin/pg_resetxlog.c:955: undefined reference to `pg_crc32_table'
pg_resetxlog.o: In function `PrintControlValues':
/var/lib/postgresql/src/bdr-plugin/pg_resetxlog.c:749: undefined reference to `pg_crc32_table'
collect2: error: ld returned 1 exit status
make: *** [bdr_resetxlog] Error 1

To build this deb package I'm using the following commands:

cd ~/src/
git clone -b bdr-plugin/next git://git.postgresql.org/git/2ndquadrant_bdr.git bdr-plugin
git clone -b debian/bdr https://github.com/2ndQuadrant/bdr-packaging bdr-packaging
cp -rfv bdr-packaging/debian bdr-plugin/debian
cd bdr-plugin
dpkg-buildpackage -b -rfakeroot -us -uc

About the dependencies, all the postgresql-BDR server are installed, and all postgresql looks ok:

# dpkg -l | grep postgresq | grep dev
ii  postgresql-bdr-server-dev-9.4       9.4.5-2trusty                    amd64        development files for PostgreSQL-BDR 9.4 server-side programming
ii  postgresql-server-dev-9.1           9.1.21-1.pgdg14.04+1             amd64        development files for PostgreSQL 9.1 server-side programming
ii  postgresql-server-dev-9.2           9.2.16-1.pgdg14.04+1             amd64        development files for PostgreSQL 9.2 server-side programming
ii  postgresql-server-dev-9.3           9.3.12-1.pgdg14.04+1             amd64        development files for PostgreSQL 9.3 server-side programming
ii  postgresql-server-dev-9.5           9.5.2-1.pgdg14.04+1              amd64        development files for PostgreSQL 9.5 server-side programming
ii  postgresql-server-dev-all           173.pgdg14.04+1                  all          extension build tool for multiple PostgreSQL versions

Any idea why I'm getting this error?

Regards

Best Answer

The cause of the issue is that Debian/Ubuntu upgraded postgresql-server-dev-all to require postgresql-server-dev-9.5 which in turns requires libpq-dev 9.5.

There were changes in libpq 9.5 that broke the patched versions of pg_resetxlog and pg_dump bundled in BDR.

BDR 1.0 adds compatibility changes to address this, but there's no real way around the issue that when Debian or Ubuntu or PGDG update libpq, it can break previously working packages.

Related Solutions

PostgreSQL BDR – 2ndQuadrant BDR Installation Issues on Ubuntu

I am not too sure about this, but it seems that BDR is build into postgresql, since I added a shared_preload_library like this: shared_preload_libraries = 'bdr', it seems to be working the same as BDR or maybe better.

Postgresql – Ensuring Postgresql BDR replication

My understanding, reading between the lines, is that BDR replicates row by row, starting after the COMMIT.

Right - but it replicates transactions with the same transaction boundaries as on the original node. So they only become visible at commit time on the downstream.

e.g.

BEGIN;
INSERT INTO x (a) VALUES (1), (2), (3);
INSERT INTO x (a) VALUES (4);
COMMIT;
BEGIN;
INSERT INTO x (a) VALUES (42);
COMMIT;

replicates as

BEGIN;
INSERT INTO x (a) VALUES (1);
INSERT INTO x (a) VALUES (2);
INSERT INTO x (a) VALUES (3);
INSERT INTO x (a) VALUES (4);
COMMIT;
BEGIN;
INSERT INTO x (a) VALUES (42);
COMMIT;

Note, however, that conflict resolution is row-by-row. So if your downstream already had a row with a = 4, and a was the PRIMARY KEY, that INSERT would get ignored but the rest would proceed normally, and the whole xact would commit as an insert of 1, 2, and 4.

But I need to know the pg_lsn of my last transaction.

Unfortunately, PostgreSQL does not report commit LSNs. I've tried to get optional support for reporting them at commit time, but without success so far. Doing it "right" requires extending the wire protocol, and a few people objected to the backward-compatible way of doing so that I proposed.

The best you can do right now is wait until replay has passed your commit, by doing:

BEGIN;
... do stuff ...;
COMMIT;
SELECT pg_current_xlog_insert_location();

and waiting until replication passes that point. But since this may contain other unimportant work after your commit by the time you call it, and the walsender doesn't rush to replicate unimportant bookkeeping to peers, sometimes it can take a while to pass that LSN. Not usually a problem in production, but can cause stalls in tests and small scale setups.

There's not really an alternative right now though. You can perform a dummy xact after the real one you're interested in to make sure you replicate immediately, at the cost of burning xids, but it must be a real write xact otherwise it'll be silently discarded.

Best Answer

Related Solutions

PostgreSQL BDR – 2ndQuadrant BDR Installation Issues on Ubuntu

Postgresql – Ensuring Postgresql BDR replication

Related Question