| From: | Joe Conway <mail(at)joeconway(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Adam Brightwell <adam(dot)brightwell(at)crunchydata(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: bootstrap pg_shseclabel in relcache initialization |
| Date: | 2015-11-11 19:04:38 |
| Message-ID: | 56439146.9080601@joeconway.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11/11/2015 11:31 AM, Tom Lane wrote:
> After sleeping on it, the best compromise I can think of is to add an
> "Assert(false)" after the WARNING report for the shared-catalogs case.
> This will make the failure un-missable in any development build, while
> not breaking production builds' ability to recover from corner cases
> we might not've foreseen.
That sounds like a good answer to me.
> Of course, if you run an assert-enabled build in production, you might
> possibly lose. But that's never been recommended practice.
Yeah, there are plenty of other ways you would lose on that proposition.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2015-11-11 19:05:25 | Re: [COMMITTERS] pgsql: Translation updates |
| Previous Message | Gavin Flower | 2015-11-11 18:57:28 | Re: can we add SKIP LOCKED to UPDATE? |