Joshua Tolley writes:
> On Sun, May 23, 2010 at 2:11 PM, Jehan-Guillaume (ioguix) de Rorthais
> wrote:
>> Here is how to reproduce the bug:
>> postgres=# SELECT rolname FROM pg_catalog.pg_roles AS r, pg_auth_members AS m
>> WHERE r.oid=m.roleid
>> AND member IN (
>> SELECT oid FROM pg_catalog.pg_
On Sun, May 23, 2010 at 2:11 PM, Jehan-Guillaume (ioguix) de Rorthais
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
> A user reported us the following bug under phpPgAdmin with 9.0beta1, but it
> seems it comes from backend.
>
> Here is how to reproduce the bug:
>
> ==
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
A user reported us the following bug under phpPgAdmin with 9.0beta1, but it
seems it comes from backend.
Here is how to reproduce the bug:
>
postgres=# SELECT version();
version
-
-
On 24/05/10 00:58, Tom Lane wrote:
Craig Ringer writes:
+ SSL_CTX_set_client_CA_list( SSL_context,
SSL_load_client_CA_file(ROOT_CERT_FILE) );
Hmm, what about failures? If we're loading the root cert file a second
time, it's possible that the user just changed it and the load n
Tom Molesworth writes:
> I don't know anything about psql internals, but at a guess the sequence
> is this:
> * 'begin' is sent to server
> * Connection is dropped
> * Connection is reset, but 'begin' is not resent
> * Next statement (the update) is sent to the server, executes immediately
> * Ro
Craig Ringer writes:
> + SSL_CTX_set_client_CA_list( SSL_context,
> SSL_load_client_CA_file(ROOT_CERT_FILE) );
Hmm, what about failures? If we're loading the root cert file a second
time, it's possible that the user just changed it and the load now fails
for some reason.
