Re: Is anybody actually using XLR_BKP_REMOVABLE?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Is anybody actually using XLR_BKP_REMOVABLE?
Date: 2011-12-12 15:42:59
Message-ID: 19108.1323704579@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Mon, Dec 12, 2011 at 3:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Furthermore, what the XLR_BKP_REMOVABLE bit actually reports is just
>> whether a backup operation is in progress, and I think we have now (or
>> easily could) add reporting records to the WAL stream that tell when a
>> backup starts or stops. So external compression would still be possible
>> if it kept a bit more state around.
>>
>> So: is there actually any such compression program out there?
>> Would anybody really cry if this flag went away?

> Yes, WAL records could be invented to mark the boundaries, so yes,
> IMHO it is OK to make that flag go away.

It occurs to me also that we could just move the flag from
per-WAL-record info bytes to per-page or even per-segment WAL headers.
Because we now force a segment switch when starting a backup, the
flag would be seen turned-on soon enough to prevent problems.
Finding out that it's off again after the end of a backup might be
a little delayed, but the only cost is failure to compress a few
compressible records.

I'm not volunteering to do the above, unless someone steps forward
to say that there's active use of this flag, but either one of these
solutions seems more tenable than using up an info-byte bit.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Albe Laurenz 2011-12-12 15:49:18 Re: review: CHECK FUNCTION statement
Previous Message Simon Riggs 2011-12-12 15:36:49 Re: Is anybody actually using XLR_BKP_REMOVABLE?