On Sun, Nov 28, 2010 at 7:45 PM, Fujii Masao wrote:
> Thanks. I found the typo:
I only have one? :-)
Thanks, fixed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
On Sat, Nov 27, 2010 at 9:25 PM, Robert Haas wrote:
> On Thu, Nov 25, 2010 at 1:18 AM, KaiGai Kohei wrote:
>> The attached patch is revised version.
>>
>> - Logging part within auth_delay was removed. This module now focuses on
>> injection of a few seconds delay on authentication failed.
>> - D
On Sun, Nov 28, 2010 at 7:10 PM, Jeff Janes wrote:
> Oh, I wasn't complaining. I think that having max_connections be
> charged for the duration even if the socket is dropped is the only
> reasonable thing to do, and wanted to verify that it did happen.
> Otherwise the module wouldn't do a very g
On Sun, Nov 28, 2010 at 3:57 PM, Robert Haas wrote:
> On Sun, Nov 28, 2010 at 5:41 PM, Jeff Janes wrote:
>> On Sun, Nov 28, 2010 at 5:38 AM, Robert Haas wrote:
>>> On Sat, Nov 27, 2010 at 2:44 PM, Jeff Janes wrote:
>>
I haven' t thought of a way to test this, so I guess I'll just ask.
On Sun, Nov 28, 2010 at 5:41 PM, Jeff Janes wrote:
> On Sun, Nov 28, 2010 at 5:38 AM, Robert Haas wrote:
>> On Sat, Nov 27, 2010 at 2:44 PM, Jeff Janes wrote:
>
>>> I haven' t thought of a way to test this, so I guess I'll just ask.
>>> If the attacking client just waits a few milliseconds for a
On Sun, Nov 28, 2010 at 5:38 AM, Robert Haas wrote:
> On Sat, Nov 27, 2010 at 2:44 PM, Jeff Janes wrote:
>> I haven' t thought of a way to test this, so I guess I'll just ask.
>> If the attacking client just waits a few milliseconds for a response
>> and then drops the socket, opening a new one,
On Sat, Nov 27, 2010 at 2:44 PM, Jeff Janes wrote:
> On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost wrote:
>> * Jan Urbański (wulc...@wulczer.org) wrote:
>>> On 04/11/10 14:09, Robert Haas wrote:
>>> > Hmm, I wonder how useful this is given that restriction.
>>>
>>> As KaiGai mentined, it's more t
On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost wrote:
> * Jan Urbański (wulc...@wulczer.org) wrote:
>> On 04/11/10 14:09, Robert Haas wrote:
>> > Hmm, I wonder how useful this is given that restriction.
>>
>> As KaiGai mentined, it's more to make bruteforcing difficult (read: tmie
>> consuming), ri
On Thu, Nov 25, 2010 at 1:18 AM, KaiGai Kohei wrote:
> The attached patch is revised version.
>
> - Logging part within auth_delay was removed. This module now focuses on
> injection of a few seconds delay on authentication failed.
> - Documentation parts were added like any other contrib modules
On Thu, Nov 25, 2010 at 9:54 PM, KaiGai Kohei wrote:
> I'll revise my patch. How about _PG_fini()?
In modules like auto_explain and pg_stat_statements, we have some
token code in there to handle unload, but I don't believe there's any
way to invoke it, nor would it work if there were multiple use
(2010/11/26 11:35), Fujii Masao wrote:
On Thu, Nov 25, 2010 at 3:18 PM, KaiGai Kohei wrote:
The attached patch is revised version.
- Logging part within auth_delay was removed. This module now focuses on
injection of a few seconds delay on authentication failed.
- Documentation parts were ad
On Thu, Nov 25, 2010 at 3:18 PM, KaiGai Kohei wrote:
> The attached patch is revised version.
>
> - Logging part within auth_delay was removed. This module now focuses on
> injection of a few seconds delay on authentication failed.
> - Documentation parts were added like any other contrib modules
(2010/11/19 16:57), KaiGai Kohei wrote:
(2010/11/18 2:17), Robert Haas wrote:
On Wed, Nov 17, 2010 at 10:32 AM, Ross J. Reedstrom wrote:
On Tue, Nov 16, 2010 at 09:41:37PM -0500, Robert Haas wrote:
On Tue, Nov 16, 2010 at 8:15 PM, KaiGai Kohei wrote:
If we don't need a PoC module for each new
On Fri, Nov 19, 2010 at 04:57:03PM +0900, KaiGai Kohei wrote:
> (2010/11/18 2:17), Robert Haas wrote:
> >
> >If KaiGai updates the code per previous discussion, would you be
> >willing to take a crack at adding documentation?
> >
> >P.S. Your email client seems to be setting the Reply-To address to
(2010/11/18 2:17), Robert Haas wrote:
On Wed, Nov 17, 2010 at 10:32 AM, Ross J. Reedstrom wrote:
On Tue, Nov 16, 2010 at 09:41:37PM -0500, Robert Haas wrote:
On Tue, Nov 16, 2010 at 8:15 PM, KaiGai Kohei wrote:
If we don't need a PoC module for each new hooks, I'm not strongly
motivated to p
On Wed, Nov 17, 2010 at 10:32 AM, Ross J. Reedstrom wrote:
> On Tue, Nov 16, 2010 at 09:41:37PM -0500, Robert Haas wrote:
>> On Tue, Nov 16, 2010 at 8:15 PM, KaiGai Kohei wrote:
>> > If we don't need a PoC module for each new hooks, I'm not strongly
>> > motivated to push it into contrib tree.
>>
On Tue, Nov 16, 2010 at 09:41:37PM -0500, Robert Haas wrote:
> On Tue, Nov 16, 2010 at 8:15 PM, KaiGai Kohei wrote:
> > If we don't need a PoC module for each new hooks, I'm not strongly
> > motivated to push it into contrib tree.
> > How about your opinion?
>
> I'd say let it go, unless someone
On Tue, Nov 16, 2010 at 8:15 PM, KaiGai Kohei wrote:
> If we don't need a PoC module for each new hooks, I'm not strongly
> motivated to push it into contrib tree.
> How about your opinion?
I'd say let it go, unless someone else feels strongly about it.
> Sorry, I missed the manner of contrib mo
(2010/11/15 11:50), Robert Haas wrote:
On Thu, Nov 4, 2010 at 10:04 AM, Robert Haas wrote:
On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost wrote:
* Jan Urbański (wulc...@wulczer.org) wrote:
On 04/11/10 14:09, Robert Haas wrote:
Hmm, I wonder how useful this is given that restriction.
As Kai
On Thu, Nov 4, 2010 at 10:04 AM, Robert Haas wrote:
> On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost wrote:
>> * Jan Urbański (wulc...@wulczer.org) wrote:
>>> On 04/11/10 14:09, Robert Haas wrote:
>>> > Hmm, I wonder how useful this is given that restriction.
>>>
>>> As KaiGai mentined, it's more
On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost wrote:
> * Jan Urbański (wulc...@wulczer.org) wrote:
>> On 04/11/10 14:09, Robert Haas wrote:
>> > Hmm, I wonder how useful this is given that restriction.
>>
>> As KaiGai mentined, it's more to make bruteforcing difficult (read: tmie
>> consuming), ri
(2010/11/04 22:05), Itagaki Takahiro wrote:
2010/11/4 KaiGai Kohei:
The attached patch is a contrib module to inject a few seconds
delay on authentication failed. It is also a proof of the concept
using the new ClientAuthentication_hook.
This module provides a similar feature to pam_faildelay o
* Jan Urbański (wulc...@wulczer.org) wrote:
> On 04/11/10 14:09, Robert Haas wrote:
> > Hmm, I wonder how useful this is given that restriction.
>
> As KaiGai mentined, it's more to make bruteforcing difficult (read: tmie
> consuming), right?
Which it would still do, since the attacker would be b
On 04/11/10 14:09, Robert Haas wrote:
> On Thu, Nov 4, 2010 at 6:05 AM, Itagaki Takahiro
> wrote:
>> 2010/11/4 KaiGai Kohei :
>>> The attached patch is a contrib module to inject a few seconds
>>> delay on authentication failed. It is also a proof of the concept
>>> using the new ClientAuthenticat
On Thu, Nov 4, 2010 at 6:05 AM, Itagaki Takahiro
wrote:
> 2010/11/4 KaiGai Kohei :
>> The attached patch is a contrib module to inject a few seconds
>> delay on authentication failed. It is also a proof of the concept
>> using the new ClientAuthentication_hook.
>>
>> This module provides a similar
2010/11/4 KaiGai Kohei :
> The attached patch is a contrib module to inject a few seconds
> delay on authentication failed. It is also a proof of the concept
> using the new ClientAuthentication_hook.
>
> This module provides a similar feature to pam_faildelay on
> operating systems. Injection of a
The attached patch is a contrib module to inject a few seconds
delay on authentication failed. It is also a proof of the concept
using the new ClientAuthentication_hook.
This module provides a similar feature to pam_faildelay on
operating systems. Injection of a few seconds delay on
authentication
27 matches
Mail list logo
