Thread: pgsql: Don't forget to flush XLOG_PARAMETER_CHANGE record.
Don't forget to flush XLOG_PARAMETER_CHANGE record. Backpatch to 9.0 where XLOG_PARAMETER_CHANGE record was instroduced. Branch ------ REL9_0_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/0af5fd82e0ca4f61875f5e02aa868b4cea43ae40 Modified Files -------------- src/backend/access/transam/xlog.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
This commit message doesn't give any indication of what the consequences of this oversight are. I think that's generally a good thing to include. On Tue, Mar 25, 2014 at 10:38 AM, Fujii Masao <fujii@postgresql.org> wrote: > Don't forget to flush XLOG_PARAMETER_CHANGE record. > > Backpatch to 9.0 where XLOG_PARAMETER_CHANGE record was instroduced. > > Branch > ------ > REL9_0_STABLE > > Details > ------- > http://git.postgresql.org/pg/commitdiff/0af5fd82e0ca4f61875f5e02aa868b4cea43ae40 > > Modified Files > -------------- > src/backend/access/transam/xlog.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > > -- > Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-committers -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> This commit message doesn't give any indication of what the
> consequences of this oversight are. I think that's generally a good
> thing to include.
Yes, please. We (usually Bruce or I) make release notes based on the
commit logs. Please be sure your commit message includes enough info
to write a useful release note about the change.
regards, tom lane
On 25 March 2014 19:59, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> This commit message doesn't give any indication of what the >> consequences of this oversight are. I think that's generally a good >> thing to include. > > Yes, please. We (usually Bruce or I) make release notes based on the > commit logs. Please be sure your commit message includes enough info > to write a useful release note about the change. I don't think there are any consequences. All it seems to do is slow down recovery by an XLogFlush(), which admitedly isn't much, so I'm not asking to revert either. The WAL record concerned is written immediately before the shutdown checkpoint at the end of recovery, which then definitely flushes WAL. That is very definitely there before 9.3. If there isn't a shutdown checkpoint then we simply begin recovery at the last restartpoint, and then rewrite the parameter change, so even in 9.3 I don't see a problem. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Wed, Mar 26, 2014 at 4:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> This commit message doesn't give any indication of what the >> consequences of this oversight are. I think that's generally a good >> thing to include. > > Yes, please. We (usually Bruce or I) make release notes based on the > commit logs. Please be sure your commit message includes enough info > to write a useful release note about the change. Oh, I'm sorry. That's my fault. Will keep in mind that. Regards, -- Fujii Masao
On Wed, Mar 26, 2014 at 5:39 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On 25 March 2014 19:59, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> This commit message doesn't give any indication of what the >>> consequences of this oversight are. I think that's generally a good >>> thing to include. >> >> Yes, please. We (usually Bruce or I) make release notes based on the >> commit logs. Please be sure your commit message includes enough info >> to write a useful release note about the change. > > I don't think there are any consequences. All it seems to do is slow > down recovery by an XLogFlush(), which admitedly isn't much Yes. And basically the XLogFlush that the patch added is executed only when wal_level is changed. It's not quite so common code path, I think. Regards, -- Fujii Masao