From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | digoal(at)126(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #13645: pg_basebackup backup hash index & unlogged table |
Date: | 2015-10-05 03:00:37 |
Message-ID: | CAB7nPqSNiC56q+T=MUtifK5PL90mHtM9YfPdgb-bGqveE74JPg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Oct 5, 2015 at 10:37 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Mon, Sep 28, 2015 at 06:15:24AM +0000, digoal(at)126(dot)com wrote:
>> Hash index and unlogged table don't generate XLOG record, when we use
>> pg_basebackup's backup datafile & xlog archive recovery database, unlogged
>> table datafile will purged, and hash index also has unconsistent data page.
>> Why pg_basebackup not filter the hash index datafile & unlogged table
>> datafile, these file waste net band and backup file's capcity.
>
> We will issue a warning in 9.5 when hash indexes are created. I am not
> sure why we don't filter out hash indexed and unlogged tables.
basebackup.c does not have much logic yet to see if the file it is
working on is a relation file (this already exists in
filemap(dot)c(at)isRelDataFile in pg_rewind), and a WAL sender is not
connected to a particular database, which would be needed for pg_class
lookups, so it seems to me that this would be a complicated
infrastructure for a niche use case. Note to mention that perhaps, in
a perhaps-distant day, hash indexes will have WAL support.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2015-10-05 08:10:28 | Re: BUG #13662: Base Directory Slashes are FORWARD |
Previous Message | Bruce Momjian | 2015-10-05 01:37:41 | Re: BUG #13645: pg_basebackup backup hash index & unlogged table |