On Mon, Dec 12, 2011 at 3:42 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@2ndquadrant.com> writes: >> On Mon, Dec 12, 2011 at 3:17 PM, Tom Lane <t...@sss.pgh.pa.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.
I'll volunteer. Assume you can reuse the flag and I will patch afterwards. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
