bart(a)icm.edu.pl wrote:
> --=_c864110a076fc513331e0370bcb9adbe
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain; charset=UTF-8;
> format=flowed
>
>
> I put patch here because the ftp server is full.
> DB
Kurt, the source file in the patch contains this header:
@@ -0,0 +1,467 @@
+/* rewatt.c - Overlay to rewrite some attribute */
+/* Redistribution and use in source and binary forms, with or without
+ * modification, are permitted only as authorized by the OpenLDAP
+ * Public License.
+ *
+ * A copy of this license is available in the file LICENSE in the
+ * top-level directory of the distribution or, alternatively, at
+ * <http://www.OpenLDAP.org/license.html>.
+ */
+/* ACKNOWLEDGEMENTS:
+ * This work was originally developed by the Dominik Bartkiewicz
bart(a)icm.edu.pl for
+ * inclusion in OpenLDAP Software.
+ */
I presume we still need a formal IPR notice in the ITS?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
At Sat, 27 Jul 2013 16:59:07 GMT,
mamfelt(a)gmail.com wrote:
> 1) also did .35 version, same message
> 2) these, except for filesize, are the defaults for at least the last 10
> years:
> time(seconds) unlimited
> file(blocks) unlimited
> data(kbytes) 131072
> stack(kbytes) 32768
> memory(kbytes) 32768
> coredump(blocks) 2097151
> nofiles(descriptors) 2000
Please do `export LDR_CNTRL=MAXDATA=0x20000000` and retry test060.
> Now, it is perhaps possible that the data/memory/ and/or stack size is too
> small. I shall check on the test system to see if the defaults are the same
> as above, or if all have been reset.
> I'll even look for a coredump to see if it says anything more about what
> has happened.
--
-- Name: SATOH Fumiyasu @ OSS Technology Corp. (fumiyas @ osstech co jp)
-- Business Home: http://www.OSSTech.co.jp/
-- GitHub Home: https://GitHub.com/fumiyas/
-- PGP Fingerprint: BBE1 A1C9 525A 292E 6729 CDEC ADC2 9DCA 5E1C CBCA
Michael Felt wrote:
> The log file did not show any errors.
If there's no server side errors then I suppose it's a problem in mtread.
Check the testrun/mtread.out file.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
-------- Original Message --------
Subject: Re: (ITS#7644) inverted MDB_SET_RANGE desired
Date: Sat, 27 Jul 2013 14:26:51 -0700
From: Howard Chu <hyc(a)symas.com>
To: Michiel Visser <vissermc(a)gmail.com>
Michiel Visser wrote:
> Dear Mr Chu,
>
> Answering your question: in case the found key is equal, you could specify:
> the key parameter *must* stay the untouched (same mv_data pointer), thus no
> extra memory block will be allocated that is basically a duplicate. Maybe it
> is already implemented this way? Important is that this should be documented
> (such that it is frozen). This would make it possible to have my desired
> functionality (and more) without sacrificing any performance (doing another
> unnecessary key comparison).
>
> By the way: the documentation does not tell whether the input key memory
> (mv_data) will stay untouched, in case the output key is different (but its
> size the same or smaller), or that always new memory is allocated for this
> purpose.
1) the library *never* allocates memory to return a value to you. I thought
that was already stated clearly. That's one of the fundamental design
principles of LMDB. You should know this already if you've read the docs.
2) The mdb_cursor_get() doc states explicitly that the object's address is
returned *except* in the case of MDB_SET.
I'm not sure it would be wise to change this at this point in time, people
have been using LMDB for going on 2 years already.
> Thank you for your time, and I want to make clear I really like mdb, and its
> interface :)
>
> Michiel Visser
>
>
> 2013/7/24 Howard Chu <hyc(a)symas.com <mailto:hyc@symas.com>>
>
> vissermc(a)gmail.com <mailto:vissermc@gmail.com> wrote:
>
> Full_Name: Michiel Visser
> Version: 2.4.35
> OS: Linux
> URL: ftp://ftp.openldap.org/__incoming/ <ftp://ftp.openldap.org/incoming/>
> Submission from: (NULL) (88.159.211.22)
>
>
> Feature request:
> MDB_SET_RANGE is an important option for me (I'm implementing a
> generic triple
> store on top of MDB). But I also desire some additions:
> 1) let's call it MDB_SET_RANGE_INV: find key equal of smaller. In
> theory I could
> also apply an inverted compare function, but this makes it
> counter-intuitive
> ('bigger' actually implying 'smaller'). And I understand I can also use
> SET_RANGE, followed by a cursor-previous-traversal, but it would
> require extra
> logic to check whether the key is already equal, which brings me to my
> second
> point:
>
>
> Extra logic will be required anyway, whether inside liblmdb or in your
> application. In this case I don't see value in making the library bigger
> to handle this.
>
> 2) a way to see whether the returned key is equal (to the supplied
> key), to
> avoid another call to get/cursor_get, or avoid a manual key compare.
>
>
> The mdb_cursor_get() function signature is what it is, there's nowhere to
> return any other parameters. How would you propose to indicate this to the
> caller?
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/__project/
> <http://www.openldap.org/project/>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
mamfelt(a)gmail.com wrote:
> --089e0160a454490f9304e28133c7
> Content-Type: text/plain; charset=ISO-8859-1
>
> p.s. what is the quick way to run this test directly, rather than 1-59
> before running test 60?
<openldap>/tests/run test060
> I did not find a core dump.
Read the tail end of testrun/slapd.1.log and look for any error messages.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/