Re: BUG #15636: PostgreSQL 11.1 pg_basebackup backup to a CIFSdestination throws fsync error at end of backup

Поиск
Список
Период
Сортировка
От John Klann
Тема Re: BUG #15636: PostgreSQL 11.1 pg_basebackup backup to a CIFSdestination throws fsync error at end of backup
Дата
Msg-id CAHyX5+X60D0jtf4dgyt11mH=7XvuW1UOLstY9sBLgukyf8Oo4g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #15636: PostgreSQL 11.1 pg_basebackup backup to a CIFSdestination throws fsync error at end of backup  (John Klann <jk7255@gmail.com>)
Ответы Re: BUG #15636: PostgreSQL 11.1 pg_basebackup backup to a CIFSdestination throws fsync error at end of backup
Список pgsql-bugs
Дерево обсуждения
Hi Thomas,

I was able to test the patch without issue and it appears to have worked see below. Let me know if there is further testing I can do or logging you would like.

existing bin:
[postgres@server]$ /usr/pgsql-11/bin/pg_basebackup -D /cifs/backups/99testNoPatch -U backupuser -Ft -Z 1 -X fetch -p 5433                 
pg_basebackup: could not fsync file "/cifs/backups/99testNoPatch": Invalid argument
patched bin:
[postgres@server]$ /home/postgres/patchinstall/bin/pg_basebackup -D /cifs/backups/99testWithPatch -U backupuser -Ft -Z 1 -X fetch -p 5433 
[postgres@server]$ 

I also restored the from the patched backup no issues:
2019-02-15 10:29:12.426 EST, LOG, "ending log output to stderr",,"Future log output will go to log destination ""csvlog""."
2019-02-15 10:29:12.431 EST, LOG, "database system was interrupted; last known up at 2019-02-15 10:18:00 EST"
2019-02-15 10:29:12.605 EST, LOG, "starting point-in-time recovery to 2019-02-15 10:29:09-05"
2019-02-15 10:29:12.796 EST, LOG, "restored log file ""000000010000000000000008"" from archive"
2019-02-15 10:29:12.845 EST, LOG, "redo starts at 0/8000028"
2019-02-15 10:29:12.848 EST, LOG, "consistent recovery state reached at 0/80000F8"
2019-02-15 10:29:12.849 EST, LOG, "database system is ready to accept read only connections"
2019-02-15 10:29:13.013 EST, LOG, "restored log file ""000000010000000000000009"" from archive"
2019-02-15 10:29:13.039 EST, LOG, "redo done at 0/9000140"
2019-02-15 10:29:13.135 EST, LOG, "restored log file ""000000010000000000000009"" from archive"
2019-02-15 10:29:13.188 EST, LOG, "selected new timeline ID: 3"
2019-02-15 10:29:13.228 EST, LOG, "archive recovery complete"
2019-02-15 10:29:13.363 EST, LOG, "database system is ready to accept connections"

Thanks,

John


On Fri, Feb 15, 2019 at 12:53 AM John Klann <jk7255@gmail.com> wrote:
Great thank you I will let you know how is goes.

John

On Thu, Feb 14, 2019, 23:47 Thomas Munro <thomas.munro@enterprisedb.com wrote:
On Fri, Feb 15, 2019 at 5:27 PM John Klann <jk7255@gmail.com> wrote:
> Happy to test it, I will need the instructions if you can. It's for Rhel 7.5 Maipo latest. (Linux 3.10.0-862.14.4.el7.x86_64 #1 SMP Fri Sep 21 09:07:21 UTC 2018
> x86_64 x86_64 x86_64 GNU/Linux)

Thanks!  Use yum to install gcc, make, bison, yacc, git,
readline-devel, zlib-devel.  (Hope I'm not forgetting anything
here...)

Pull down the sources:

$ git clone https://github.com/postgres/postgres.git

Go into the source directory:

$ cd postgres

Let's say we want to test with the 11 branch (so you can test against
an existing 11.x development environment database you might have
installed the usual way with packages, as opposed to the master branch
where we are developing 12).  Switch to that branch:

$ git checkout REL_11_STABLE

Create a new branch for this experiment:

$ git checkout -b tolerate-einval

Apply the patch (adjust path to wherever you put the patch):

$ git am 0001-Tolerate-EINVAL-when-calling-fsync-on-a-directory.patch

Configure, build, install (the prefix is where it will install the
resulting binaries, adjust to taste, -j is how many CPUs you have if
you want to build fast):

$ mkdir $HOME/install
$ ./configure --prefix=$HOME/install

$ make -s -j4 && make -s install

Optionally, run a self-test to see if everything is sane:

$ make -s check

Now you should have binaries like $HOME/install/bin/pg_basebackup and
you can test if they work on CIFS.

--
Thomas Munro
http://www.enterprisedb.com

В списке pgsql-bugs по дате отправления: