From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SIGSEGV in BRIN autosummarize |
Date: | 2017-10-17 13:34:24 |
Message-ID: | 5648.1508247264@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> On Tue, Oct 17, 2017 at 12:59:16PM +0200, Alvaro Herrera wrote:
>> Anyway, can give this patch a try?
> I've only compiled postgres once before and this is a production environment
> (althought nothing so important that the crashes are a serious concern either).
> Is it reasonable to wget the postgres tarball, apply the patch, and run the
> compiled postgres binary from the source tree, without running make install or
> similar ? Otherwise, would it be good enough to copy the postgres binary to
> /usr/pgsql-10/bin (and reinstall the binary package later) ?
The trick in this sort of situation is to make sure you build binaries
that match your existing install in every way except having the added
patch, and maybe getting installed into a different directory.
So: where did you get the existing binaries? If it's from some vendor
packaging system, what you should do is fetch the package source, add
the patch to the probably-nonempty set of patches the vendor is applying,
and rebuild your own custom package version. If you haven't done that
before, it's a good skill to acquire ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Eric Radman | 2017-10-17 13:40:10 | Re: [PATCH] Add recovery_min_apply_delay_reconnect recovery option |
Previous Message | Prabhat Sahu | 2017-10-17 13:18:53 | Query got Killed with CTE. |