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
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? |