Bug 239559 - [NEW PORT] databases/pg_probackup: tool for PostgreSQL backups
Summary: [NEW PORT] databases/pg_probackup: tool for PostgreSQL backups
Status: Closed Feedback Timeout
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Matthew Seaman
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-31 14:12 UTC by Michael Zhilin
Modified: 2021-05-22 20:54 UTC (History)
2 users (show)

See Also:


Attachments
SVN patch (3.24 KB, patch)
2019-07-31 14:12 UTC, Michael Zhilin
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Zhilin freebsd_committer freebsd_triage 2019-07-31 14:12:34 UTC
Created attachment 206178 [details]
SVN patch

Hi,

Here is port of pg_probackup, yet another PostgreSQL backup tool which provides incremental backups. It's quite good alternative to pg barman. 

It works fine at least for me. 

Thanks!
Comment 1 Matthew Seaman freebsd_committer freebsd_triage 2019-08-01 06:25:08 UTC
(1) I'm getting a build failure:
```
src/utils/thread.o src/utils/remote.o src/utils/file.o src/archive.o src/backup.o src/catalog.o src/checkdb.o src/configure.o src/data.o src/delete.o src/dir.o src/fetch.o src/help.o src/init.o src/merge.o src/parsexlog.o src/pg_probackup.o src/restore.o src/show.o src/util.o src/validate.o src/pg_crc.o src/datapagemap.o src/receivelog.o src/streamutil.o src/xlogreader.o src/walmethods.o -L/usr/local/lib -lpgcommon -lpgport -L/usr/local/lib -lpq -D_THREAD_SAFE  -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -L/usr/local/lib  -L/usr/local/lib -lpthread -L/usr/local/lib  -fstack-protector-strong   -L/usr/local/lib -Wl,--as-needed -Wl,-R'/usr/local/lib'   -lpgcommon -lpgport -lintl -lssl -lcrypto -lz -lreadline -lcrypt -lm  -o pg_probackup
/usr/bin/ld: error: unable to find library -lpgcommon
/usr/bin/ld: error: unable to find library -lpgcommon
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[1]: *** [/usr/local/lib/postgresql/pgxs/src/makefiles/pgxs.mk:430: pg_probackup] Error 1
gmake[1]: Leaving directory '/wrkdirs/usr/ports/databases/pg_probackup/work/pg_probackup-2.1.5'
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

```

libpgcommon.a is installed by postgresql11-server-11.4_1, so you'll need to add:

WANT_PGSQL=     lib server

Ideally, you'ld only need postgresql-server installed as a build dependency, but it seems Mk/Uses/pgsql.mk doesn't have any provision to do that.

(2) pg_probackup states that it is compatible with postgresql 9.5, 9.6, 10, 11 
and it would be good to support all of those, rather than limiting to just 11.
The tricky part there seems to be extracting the DISTVERSION for the appropriate postgresql-server port.  It would also mean eliminating your use of the PG_VERSION variable -- something that portlint flags as an error.

There is a fairly obscure mechanism in the ports where you can depend on the checked-out WRKDIR of a different port.  I need to dig a bit to remind myself exactly how that works and if it would be suitable for this use case.
Comment 2 Michael Zhilin freebsd_committer freebsd_triage 2019-08-01 08:45:44 UTC
Thank you, Matthew!

(1) Oh, my fault. I'll testport it better via poudriere.
(2) I wonder if flavors can solve such kind of issue, i.e. there will be one port and several packages targeted to different versions of PG. I never tried flavors, so I'm newbie to them. Is it worth to flavor-ize this port? 

Best regards.
Comment 3 Matthew Seaman freebsd_committer freebsd_triage 2019-08-02 06:11:33 UTC
(In reply to Michael Zhilin from comment #2)

Yes, ideally flavours are the preferred current approach to dealing with multiple variants of a port's dependencies.  However, in the case of postgresql we don't currently have any setup in the ports to support different postgresql flavours.  Adding postgresql flavouring would be a rather large project...

Instead there are two options:

  1) Slave ports to support different versions of postgresql

  2) Just having one port, but making it adapt to the version of postgresql set 
     in DEFAULT_VERSIONS

In general you'ld get (2) pretty much automatically from the 'USES+= pgsql' mechanism, except in this case you need access to the source code of postgresqlXX-server in order to build the software.

Hmmm... about the cleanest and simplest way I can see to handle this is to have an OPTIONS setting allowing the user to choose which upstream postgresql version to use.  You're still going to have to manually update the exact postgresql version whenever postgresql updates, or else the port will break.
Comment 4 Michael Zhilin freebsd_committer freebsd_triage 2019-08-09 10:36:11 UTC
Walter Schwarzenfeld, 

Is there any naming convention for port tickets? 

Thanks!
Comment 5 Walter Schwarzenfeld freebsd_triage 2019-08-09 10:38:37 UTC
(In reply to Michael Zhilin from comment #4)
New port should appear on the begin of the line.