Tuomo Soini:
> On Mon, 10 Jan 2011 17:41:05 +0100
>
> "Stefan" wrote:
> > On Thursday, 6th Januar 2011, 21:02:17 Victor Duchovni wrote:
> > > No warning is necessary. With a large database the cleanup thread
> > > may run longer than the scheduled interval between threads. This is
> > > fine.
>
Tuomo Soini:
> On Mon, 10 Jan 2011 17:41:05 +0100
> "Stefan" wrote:
>
> > On Thursday, 6th Januar 2011, 21:02:17 Victor Duchovni wrote:
> > > No warning is necessary. With a large database the cleanup thread
> > > may run longer than the scheduled interval between threads. This is
> > > fine.
> >
On Mon, 10 Jan 2011 17:41:05 +0100
"Stefan" wrote:
> On Thursday, 6th Januar 2011, 21:02:17 Victor Duchovni wrote:
> > No warning is necessary. With a large database the cleanup thread
> > may run longer than the scheduled interval between threads. This is
> > fine.
>
> OK, I attached the final(
On Thursday, 6th Januar 2011, 21:02:17 Victor Duchovni wrote:
> On Thu, Jan 06, 2011 at 04:56:48PM +0100, Stefan Jakobs wrote:
> > > In this case, it is not as critical to set such a flag, but it is
> > > important to allow the existing scan to continue to completion, and
> > > ignore or (just note
On Thu, Jan 06, 2011 at 04:56:48PM +0100, Stefan Jakobs wrote:
> > In this case, it is not as critical to set such a flag, but it is important
> > to allow the existing scan to continue to completion, and ignore or
> > (just note) new requests until it does. Once a scan completes, new
> > scans ca
On Thursday 06 January 2011 01:45:00 Victor Duchovni wrote:
> On Wed, Jan 05, 2011 at 06:56:31PM -0500, Wietse Venema wrote:
> > Each verify or postscreen or tlsmgr process will at set times
> > scan the database for old entries.
> >
> > If it so happens that this scan doesn't finish before the n
On Wed, Jan 05, 2011 at 06:56:31PM -0500, Wietse Venema wrote:
> Each verify or postscreen or tlsmgr process will at set times
> scan the database for old entries.
>
> If it so happens that this scan doesn't finish before the new one
> starts, then it would really be a W*T*F* moment if the code d
Stefan Jakobs:
> On Tuesday, 14th of December 2010, 20:09:26 Wietse Venema wrote:
>
> > > Yes, I have tested that and it worked without problems. If you
> > > are interested then I will send you the logs of that test.
> >
> > Yes, it would help when I want to run some tests (the results should
>
On Tuesday, 14th of December 2010, 20:09:26 Wietse Venema wrote:
> > Yes, I have tested that and it worked without problems. If you
> > are interested then I will send you the logs of that test.
>
> Yes, it would help when I want to run some tests (the results should
> be similar).
I send you th
Stefan Jakobs:
>
> On Tuesday 14 December 2010 14:43:23 Wietse Venema wrote:
> > Stefan:
> > > A drawback is that this
> > > solution is not as configurable/flexible as the other one. And it's still
> > > the case that the first two values of a fetched tuple must be the
> > > address and its corre
On Tuesday 14 December 2010 14:43:23 Wietse Venema wrote:
> Stefan:
> > A drawback is that this
> > solution is not as configurable/flexible as the other one. And it's still
> > the case that the first two values of a fetched tuple must be the
> > address and its corresponing cache timings (data).
Stefan:
> A drawback is that this
> solution is not as configurable/flexible as the other one. And it's still the
> case that the first two values of a fetched tuple must be the address and its
> corresponing cache timings (data). But I guess that is acceptable.
Do you really mean that the impl
On Tuesday, 7th of december 2010, 21:57:00 Wietse Venema wrote:
> Wietse Venema:
> > Thanks for the patch.
> >
> > Stefan Jakobs:
> > > I'am not aware of any dead-lock issues. The sequence pseudo-thread
> > > will query the database only once with the first key. For every
> > > next key the sequen
Wietse Venema:
> Thanks for the patch.
>
> Stefan Jakobs:
> > I'am not aware of any dead-lock issues. The sequence pseudo-thread
> > will query the database only once with the first key. For every
> > next key the sequence pseudo-thread is working with the results
> > in the memory. With a very la
Thanks for the patch.
Stefan Jakobs:
> I'am not aware of any dead-lock issues. The sequence pseudo-thread
> will query the database only once with the first key. For every
> next key the sequence pseudo-thread is working with the results
> in the memory. With a very large database the size of the
On Friday 15 October 2010 16:53:40 Victor Duchovni wrote:
> On Fri, Oct 15, 2010 at 03:05:33PM +0200, Stefan wrote:
> > in the appendix you will find a patch against Postfix 2.7.1 which adds
> > write support to Postfix' MySQL client.
> >
> > If someone like to test it, then he will find Postfix R
On Fri, Oct 15, 2010 at 03:05:33PM +0200, Stefan wrote:
> in the appendix you will find a patch against Postfix 2.7.1 which adds write
> support to Postfix' MySQL client.
>
> If someone like to test it, then he will find Postfix RPMs with MySQL write
> support for recent versions of *SUSE linux
Hi list,
in the appendix you will find a patch against Postfix 2.7.1 which adds write
support to Postfix' MySQL client.
If someone like to test it, then he will find Postfix RPMs with MySQL write
support for recent versions of *SUSE linux here:
http://download.opensuse.org/repositories/home:/ru
Stefan Jakobs:
> > Does the database support a first/next operation?
>
> The operation which comes close to that, is to select the whole table and
> then
> fetch the keys row by row. Yes, I think that is a first/next operation (with
> a
> bad performance).
>
> What would be the answer if ther
On Friday 01 October 2010 18:58:26 Wietse Venema wrote:
> Stefan:
> > Hi list,
> >
> > I'm in the process of adding write support to postfix's mysql client (you
> > will find a patch against postfix-2.7.1 in the appendix). But I have two
> > problems: 1) the dict_cache_clean_event writes
> > _LAS
Wietse Venema:
> Stefan:
> > Hi list,
> >
> > I'm in the process of adding write support to postfix's mysql client (you
> > will
> > find a patch against postfix-2.7.1 in the appendix). But I have two
> > problems:
> > 1) the dict_cache_clean_event writes _LAST_CACHE_CLEANUP_COMPLETED_ to the
Stefan:
> Hi list,
>
> I'm in the process of adding write support to postfix's mysql client (you
> will
> find a patch against postfix-2.7.1 in the appendix). But I have two problems:
> 1) the dict_cache_clean_event writes _LAST_CACHE_CLEANUP_COMPLETED_ to the
> database. Is this the intended b
Hi list,
I'm in the process of adding write support to postfix's mysql client (you will
find a patch against postfix-2.7.1 in the appendix). But I have two problems:
1) the dict_cache_clean_event writes _LAST_CACHE_CLEANUP_COMPLETED_ to the
database. Is this the intended behaviour?
2) If I'm gu
Stefan Jakobs:
> Hello list,
>
> I refer to my question of august 2008
> (http://archives.neohapsis.com/archives/postfix/2008-08/0747.html, and see
> below).
>
> What are the necessary steps to add update support to the mysql client
> (Postfix 2.5.6 or newer)?
I think this involves writing, te
24 matches
Mail list logo
