| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Adrien Nayrat <adrien(dot)nayrat(at)dalibo(dot)com> |
| Cc: | Petr Jelinek <petr(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Christoph Berg <myon(at)debian(dot)org>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com> |
| Subject: | Re: LSN as a recovery target |
| Date: | 2016-08-22 13:08:05 |
| Message-ID: | 1a211c8d-4d4f-e6fe-6556-a1454a3ce59c@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 8/22/16 8:28 AM, Michael Paquier wrote:
> Thinking a bit wider than that, we may want to know such context for
> normal GUC parameters as well, and that's not the case now. Perhaps
> there is actually a reason why that's not done for GUCs, but it seems
> that it would be useful there as well.
GUC parsing generally needs, or used to need, to work under more
constrained circumstances, e.g., no full memory management. That's not
a reason not to try this, but there might be non-obvious problems.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2016-08-22 13:09:59 | Re: Re: [sqlsmith] FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line: 10200) |
| Previous Message | Dmitry Ivanov | 2016-08-22 13:01:01 | Re: Typo in comment to function LockHasWaitersRelation() [master branch] |