The following bug has been logged online:
Bug reference: 5471
Logged by: Christopher Hotchkiss
Email address: christopher.hotchk...@gmail.com
PostgreSQL version: 8.4
Operating system: Win32
Description:Postgres License Url is Misspelled
Details:
On the postgresql.or
On Tue, May 25, 2010 at 10:53 AM, Christopher Hotchkiss
wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5471
> Logged by: Christopher Hotchkiss
> Email address: christopher.hotchk...@gmail.com
> PostgreSQL version: 8.4
> Operating system: Win32
> Descri
Craig Ringer writes:
> Bug 5245 is not the same issue. They're talking about the server not
> sending the full certificate chain for the cert that identifies the
> server (server.crt). It's nothing to do with client certificates.
> Without the full chain, the client can't verify the server unle
On Tue, May 25, 2010 at 17:48, Tom Lane wrote:
> Craig Ringer writes:
>> Bug 5245 is not the same issue. They're talking about the server not
>> sending the full certificate chain for the cert that identifies the
>> server (server.crt). It's nothing to do with client certificates.
>> Without the
The following bug has been logged online:
Bug reference: 5472
Logged by: Vlad Romascanu
Email address: vromasc...@accurev.com
PostgreSQL version: 8.4.3
Operating system: Windows, Linux
Description:Postgres hard crash in ...WHERE IN (SELECT
* FROM (VALUES (),...) AS t
Magnus Hagander writes:
> On Tue, May 25, 2010 at 17:48, Tom Lane wrote:
>> Craig Ringer writes:
>>> Bug 5245 is not the same issue.
>>
>> BTW, does anyone know exactly how to fix that? I'm looking at a related
>> request internal to Red Hat right now.
> I have it on my TODO to figure it out,
On Tue, May 25, 2010 at 10:39, Vlad Romascanu wrote:
> The following reproducibly crashes Postgres 8.4.3 (segfault) inside
> int84eq() on both Windows and Linux, but works just fine in 8.3.4:
Hrm... Both work for me (8.4.3 and 8.4.4).
--
=> SELECT col1, col2 FROM t1 WHERE col1 IN ( SELECT * FRO
On Tue, May 25, 2010 at 11:26, Alex Hunsaker wrote:
> On Tue, May 25, 2010 at 10:39, Vlad Romascanu wrote:
>
>> The following reproducibly crashes Postgres 8.4.3 (segfault) inside
>> int84eq() on both Windows and Linux, but works just fine in 8.3.4:
>
> Hrm... Both work for me (8.4.3 and 8.4.4).
"Vlad Romascanu" writes:
> Description:Postgres hard crash in ...WHERE IN (SELECT
> * FROM (VALUES (),...) AS t(col))
Fixed, thanks for the report! Patch is here if you need it:
http://archives.postgresql.org/message-id/20100525174447.c0b00754...@cvs.postgresql.org
Alex Hunsaker writes:
> On Tue, May 25, 2010 at 10:39, Vlad Romascanu wrote:
>> The following reproducibly crashes Postgres 8.4.3 (segfault) inside
>> int84eq() on both Windows and Linux, but works just fine in 8.3.4:
> Hrm... Both work for me (8.4.3 and 8.4.4).
I think it wouldn't crash if you
Interesting. I forgot to mention both the Linux and Windows Postgres builds
I'm reproducing this on are 32-bit (!) builds, which is probably highly
relevant. I was able to also reproduce the crash with 8.4.4-1 in addition to
8.4.3 on Windows (in both cases using the official builds from the Do
Fair enough but that is the sole use of that spelling on the website.
Every other usage including the visible text uses "license".
Sent from my iPhone
On May 25, 2010, at 11:36 AM, Dave Page wrote:
On Tue, May 25, 2010 at 10:53 AM, Christopher Hotchkiss
wrote:
The following bug has been
On Tue, May 25, 2010 at 18:44, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, May 25, 2010 at 17:48, Tom Lane wrote:
>>> Craig Ringer writes:
Bug 5245 is not the same issue.
>>>
>>> BTW, does anyone know exactly how to fix that? I'm looking at a related
>>> request internal to Red H
The following bug has been logged online:
Bug reference: 5473
Logged by: carolina
Email address: caro.herrer...@hotmail.com
PostgreSQL version: postgresql 8.4
Operating system: windows xp
Description:problema para reinstalar postgresql
Details:
Hola..tengo el siquie
Magnus Hagander writes:
> On Tue, May 25, 2010 at 17:48, Tom Lane wrote:
>> Craig Ringer writes:
>>> Bug 5245 is not the same issue. They're talking about the server not
>>> sending the full certificate chain for the cert that identifies the
>>> server (server.crt). It's nothing to do with clien
On 25/05/10 23:48, Tom Lane wrote:
Craig Ringer writes:
Bug 5245 is not the same issue. They're talking about the server not
sending the full certificate chain for the cert that identifies the
server (server.crt). It's nothing to do with client certificates.
Without the full chain, the client c
Craig Ringer writes:
> I do *not* have the CA cert concatenated onto server.crt. I'll have to
> see if that works, because that's how it's usually done with OpenSSL.
Hmm. That case doesn't work for me; what does work is including the
intermediate cert in the server's root.crt.
On 26/05/10 07:37, Tom Lane wrote:
Craig Ringer writes:
I do *not* have the CA cert concatenated onto server.crt. I'll have to
see if that works, because that's how it's usually done with OpenSSL.
Hmm. That case doesn't work for me; what does work is including the
intermediate cert in the se
Craig Ringer writes:
> On 26/05/10 07:37, Tom Lane wrote:
>> Craig Ringer writes:
>>> I do *not* have the CA cert concatenated onto server.crt. I'll have to
>>> see if that works, because that's how it's usually done with OpenSSL.
>>
>> Hmm. That case doesn't work for me; what does work is incl
Craig Ringer writes:
> BTW, the little Java app I posted for client certifiate testing will let
> you get detailed tracing of a Pg SSL connection.
Where did you post that exactly? I'm sure not finding it in this thread.
regards, tom lane
--
Sent via pgsql-bugs mailing
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> What I meant to question is *which* file the intermediate CA certs
> go into. It doesn't seem tremendously sensible to me to put them into
> the server.crt file, since that's intended to define exactly one cert,
> namely the one identifying the server. On
I wrote:
> What I meant to question is *which* file the intermediate CA certs
> go into.
I did some more experimentation using "openssl s_client" to look at the
cert exchange (after lobotomizing the postmaster so that it'd start a
TLS exchange immediately upon connection, without our normal startu
On 26/05/10 09:35, Tom Lane wrote:
> I am now of the opinion that bug #5245 is in fact an exact dup of
> bug #5468. The previous reporter was jumping to conclusions about what
> his problem was: it was not that the server didn't send the full cert
> chain, but that Java couldn't do the right thin
On 26/05/10 09:59, Craig Ringer wrote:
> On 26/05/10 09:35, Tom Lane wrote:
>
>> I am now of the opinion that bug #5245 is in fact an exact dup of
>> bug #5468. The previous reporter was jumping to conclusions about what
>> his problem was: it was not that the server didn't send the full cert
>>
Craig Ringer writes:
> You are confusing these two unrelated phases of SSL negotiation.
No, I don't think so.
> For the complaint in #5245 to be addressed, the server must send the
> full certificate chain for the certificate the server is using to
> identify its self as pgserver.domain.com to t
On 26/05/10 10:16, Tom Lane wrote:
> Craig Ringer writes:
>> You are confusing these two unrelated phases of SSL negotiation.
>
> No, I don't think so.
http://www.cgisecurity.com/owasp/html/ch07s04.html
See in the second part, the new entry #5 "client request"
("CertificateRequest") ? That's th
All,
Sorry, I havn't really been following this thread.
* Craig Ringer (cr...@postnewspapers.com.au) wrote:
> #5245 is about *CLIENT* *VALIDATION* *OF* *THE* *SERVER*, where the
> *CLIENT* VALIDATES THE *SERVER* after the server sends a
> CertificateRequest.
>
> For #5468 to be addressed
On 26/05/10 10:25, Stephen Frost wrote:
>>> In any case I'm thinking that we need to document how to set up
>>> configurations with chains of CA certs.
>>
>> Yes, and patch the server to send the list of trusted CAs to the client
>> during client certificate negotiaton to fix #5468 .
>
> Agreed.
On 26/05/10 10:25, Stephen Frost wrote:
>>> In any case I'm thinking that we need to document how to set up
>>> configurations with chains of CA certs.
>>
>> Yes, and patch the server to send the list of trusted CAs to the client
>> during client certificate negotiaton to fix #5468 .
>
> Agreed.
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> What I meant to question is *which* file the intermediate CA certs
>> go into. It doesn't seem tremendously sensible to me to put them into
>> the server.crt file, since that's intended to define exactly one cert,
> root CA's are
2010/5/21 Nelson da Silva da Silva :
> Qualquer versao que instalo da erro conforme abaixo :
>
> An error ocurred executing the Microsoft VC++ runtime installer, poderiam me
> dar uma dica de solução ?
This is an English-language mailing list; we do have some mailing
lists in other languages - see
On Mon, May 24, 2010 at 9:16 AM, Daniele Varrazzo
wrote:
> regexp_matches() has been recently discussed
> (http://archives.postgresql.org/pgsql-bugs/2010-04/msg00026.php): it is a
> setof function and as such it can drop results.
>
> Unfortunately it is an useful function to newcomers who use SQL,
On 26/05/10 15:51, Robert Haas wrote:
I'm not sure that it's very productive to refer to the behavior of our
code as insane.
Not meaning to single you out Robert, but typically folk are honest with
their impression of the code without worrying about feather ruffling too
much e.g: searchi
On 26/05/10 11:01, Tom Lane wrote:
> In principle, you could have the server and clients using totally
> nonoverlapping sets of trusted CAs (nonoverlapping root.crt lists),
> as long as each can chain its identity up to a CA the other trusts.
> So it's all nice and symmetrical.
... and it's exactl
34 matches
Mail list logo
