[pfx] Re: [heads up] lmdb 1.0
Christian Pfeiffer via Postfix-users <[email protected]> Sun, 05 Jul 2026 16:49:46 +0200
| Newsgroups | gmane.mail.postfix.user |
|---|---|
| Message-ID | <[email protected]> |
--===============2105932630499934721== Content-Type: multipart/alternative; boundary="----=_=-_OpenGroupware_org_NGMime-4284-1783262986.158135-4------" ------=_=-_OpenGroupware_org_NGMime-4284-1783262986.158135-4------ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Length: 2578 I had already posted on here a couple of days ago on the matter but it = got missed or so. Anyway, the problem is a singular change to mdb=5Fdro= p(), commit d0fcfd3d02321d04b56a23e6c86c80309f4ecef5 in mdb. It was mad= e to fix bug ITS#8174 in LMDB. The consequence is that now you cannot r= euse a transaction handle that was used to drop MAIN=5FDBI. Postfix doe= s this in slmdb=5Fprepare(), dropping ALL databases, including MAIN=5FD= BI. This handle then causes MXN=5FBAD=5FTXN on its next usage, breaking= newaliases and co. The transaction handle would need to be aborted and= then the transaction reopened. The patch I made for Arch downstream pa= tch that has been in this thread already does precisely that. It only c= hanges slmdb=5Fprepare() and works. I've been running Postfix 3.11.4 wi= th that patch for a few days now without issue. However, there's still = one more glitch or so with it that I haven't debugged yet. That's why I= had asked for comments in my mail a few days ago. On Sunday, July 05, 2026 15:58 CEST, Edmund Lodewijks via Postfix-users= <[email protected]> wrote: =C2=A0 On 2026/07/05 13:19, Wietse Venema via Postfix-users wrote: > Michael Grimm via Postfix-users: >> Well, I will stick with lmdb 0.9.35 for the time being or migrate >> to other database formats, instead. >=C2=A0 > Way to go if you have that option. I can see two ways to patch for this in Postfix: 1) Instead of dropping the table, walk a cursor and delete each record=C2= =A0 in place. This is much more expensive than the current method, but I=C2= =A0 think it the cost will still be negligible. The most expensive=C2=A0 transaction is when you run postmap/ postalias. The nice thing about this is that it seems to me to be the least=C2=A0 invasive patch, with as little change as possible. Most of the current=C2= =A0 structure stays the same. Importantly, atomicity is retained in the sam= e=C2=A0 way that it currently exists. This is also compatible with lmdb 0.9.x. An example patch is attached (not sure if the mailing list allows=C2=A0 attachments). 2) Alternatively, create a new table in a temp file + rename. There=C2=A0 would be more code involved for this, and a temp file (if you want to d= o=C2=A0 this securely, and not with a predictable name) introduces all kinds of= =C2=A0 file permissions things to take care off across multiple OS's. This,=C2= =A0 too, is compatible with lmdb 0.9.x. I hope this is useful. Kind regards, Edmund --=C2=A0 Edmund Lodewijks <[email protected]> TZ: UTC+2 / GMT+2 =C2=A0 ------=_=-_OpenGroupware_org_NGMime-4284-1783262986.158135-4------ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Length: 2967 <html><p>I had already posted on here a couple of days ago on the matte= r but it got missed or so. Anyway, the problem is a singular change to = mdb=5Fdrop(), commit d0fcfd3d02321d04b56a23e6c86c80309f4ecef5 in mdb. I= t was made to fix bug ITS#8174 in LMDB. The consequence is that now you= cannot reuse a transaction handle that was used to drop MAIN=5FDBI. Po= stfix does this in slmdb=5Fprepare(), dropping ALL databases, including= MAIN=5FDBI. This handle then causes MXN=5FBAD=5FTXN on its next usage,= breaking newaliases and co. The transaction handle would need to be ab= orted and then the transaction reopened. The patch I made for Arch down= stream patch that has been in this thread already does precisely that. = It only changes slmdb=5Fprepare() and works. I've been running Postfix = 3.11.4 with that patch for a few days now without issue. However, there= 's still one more glitch or so with it that I haven't debugged yet. Tha= t's why I had asked for comments in my mail a few days ago.</p><div cla= ss=3D"raw-html-embed"> </div><p><br><br>On Sunday, July 05, 2026 15:58 CEST, Edmund Lodewijks = via Postfix-users <[email protected]> wrote:<br><br> = ;</p><blockquote type=3D"cite" cite=3D"c0f530fb-730f-4079-bba9-7c92a095= [email protected]"><p>On 2026/07/05 13:19, Wietse Venema via Postfix-= users wrote:<br>> Michael Grimm via Postfix-users:<br>>> Well,= I will stick with lmdb 0.9.35 for the time being or migrate<br>>>= ; to other database formats, instead.<br>> <br>> Way to go i= f you have that option.<br><br>I can see two ways to patch for this in = Postfix:<br><br>1) Instead of dropping the table, walk a cursor and del= ete each record <br>in place. This is much more expensive than the= current method, but I <br>think it the cost will still be negligi= ble. The most expensive <br>transaction is when you run postmap/ p= ostalias.<br><br>The nice thing about this is that it seems to me to be= the least <br>invasive patch, with as little change as possible. = Most of the current <br>structure stays the same. Importantly, ato= micity is retained in the same <br>way that it currently exists. T= his is also compatible with lmdb 0.9.x.<br><br>An example patch is atta= ched (not sure if the mailing list allows <br>attachments).<br><br= >2) Alternatively, create a new table in a temp file + rename. There&nb= sp;<br>would be more code involved for this, and a temp file (if you wa= nt to do <br>this securely, and not with a predictable name) intro= duces all kinds of <br>file permissions things to take care off ac= ross multiple OS's. This, <br>too, is compatible with lmdb 0.9.x.<= br><br>I hope this is useful.<br><br>Kind regards,<br>Edmund<br><br><br= >-- <br>Edmund Lodewijks <[email protected]><br>TZ: UTC+= 2 / GMT+2</p></blockquote><p><br><br><br> </p></html> ------=_=-_OpenGroupware_org_NGMime-4284-1783262986.158135-4-------- --===============2105932630499934721== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Postfix-users mailing list -- [email protected] To unsubscribe send an email to [email protected] --===============2105932630499934721==--