Re: Is anybody actually using XLR_BKP_REMOVABLE?
От | Simon Riggs |
---|---|
Тема | Re: Is anybody actually using XLR_BKP_REMOVABLE? |
Дата | |
Msg-id | CA+U5nM+_0AWVO0a_wirh1T86tNvN8bei-rrvdO1egYFiiunv5w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Is anybody actually using XLR_BKP_REMOVABLE? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Is anybody actually using XLR_BKP_REMOVABLE?
|
Список | pgsql-hackers |
On Mon, Dec 12, 2011 at 3:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: >> On Mon, Dec 12, 2011 at 3:17 PM, Tom Lane <tgl@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
В списке pgsql-hackers по дате отправления: