| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: WAL Rate Limiting |
| Date: | 2014-01-16 16:48:49 |
| Message-ID: | CA+U5nMJngKCA403bjCbRD+=d6dbbfpT25cBODhNd2TE-ZUe+yA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 16 January 2014 17:29, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> Please let me know if I missed something (rather than debating what is
>> or is not a "maintenance" command).
>
> If we're going to do this for DML - which I am far from convinced of -
> we also should do it for SELECT, since that can generate significant
> amounts of WAL with checksums turned on.
> Otherwise stuff like INSERT ... SELECT, UPDATE FROM et al. will behave
> very confusingly since suddenly thez will not only block the WAL
> generated by the INSERT but also the SELECT.
Good point, but rather happily I can say "thought of that" and refer
you to the other patch which limits SELECT's ability to dirty pages,
and thus, with checksums enabled will limit the generation of WAL.
(And no, they aren't the same thing).
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-01-16 16:49:38 | Re: WAL Rate Limiting |
| Previous Message | Stephen Frost | 2014-01-16 16:42:19 | Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it |