Tom Lane wrote: > Greg Smith <gsmith@xxxxxxxxxxxxx> writes: > > That pushes the problem of writing a little chunk of code that reads only > > the right amount of data and doesn't bother compressing the rest onto the > > person writing the archive command. Seems to me that leads back towards > > wanting to bundle a contrib module with a good implementation of that with > > the software. The whole tail clearing bit is in the same situation > > pg_standby was circa 8.2: the software is available, and it works, but it > > seems kind of sketchy to those not familiar with the source of the code. > > Bundling it into the software as a contrib module just makes that problem > > go away for end-users. > > The real reason not to put that functionality into core (or even > contrib) is that it's a stopgap kluge. What the people who want this > functionality *really* want is continuous (streaming) log-shipping, not > WAL-segment-at-a-time shipping. Putting functionality like that into > core is infinitely more interesting than putting band-aids on a > segmented approach. Well, I realize we want streaming archive logs, but there are still going to be people who are archiving for point-in-time recovery, and I assume a good number of them are going to compress their WAL files to save space, because they have to store a lot of them. Wouldn't zeroing out the trailing byte of WAL still help those people? -- Bruce Momjian <bruce@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
