On Wed, Feb 3, 2010 at 11:09 AM, Tom Lane wrote:
>
> Renegotiation after X amount of data is the recommended method AFAIK,
> because it limits the volume of data available to cryptanalysis.
> What makes you think that elapsed time is relevant at all?
>
> regards, tom lane
Y
On Wed, Feb 3, 2010 at 10:21 AM, Tom Lane wrote:
>
> Bad idea: once set, it'll never get unset, thus leaving installations
> with a weakened security posture even after they've installed fixed
> versions of openssl.
>
> regards, tom lane
One might argue that the current met
You can try the symlink game if you want, but it'll be on your own head
whether it works or not. (For the record, I am hoping to do exactly
that in future releases for Red Hat ... but in that context I know what
the system's timezone code is. I'm less sure that I know what Apple
is using.)
Tha
It appears that we didn't do enough research in regards to the recent
DST switch. We poorly assumed that having our machine's timezone files
up to date would be sufficient not knowing that our version of
postgres relied on its own timezone files.
The question is... can we symlink the share/postgr
