[MacPorts] #70556: "base" seemingly locking up for sometimes very long

[MacPorts]

#70556: "base" seemingly locking up for sometimes very long
--------------------------+--------------------
  Reporter:  RJVB         |      Owner:  (none)
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+--------------------

Comment (by RJVB):

 FWIW, I just tweaked the code a bit so that `registry::set_needs_vacuum`
 also forces an actual vacuum step, and `reg_vacuum` traces what it's doing
 and how much free space there was to begin with.

 The test install where I did this has a registry that's only 4MB (real MBs
 ;)) large, but the bit of my script above

 {{{
 puts "Closing registry and ${maybe}performing vacuum ..."
 flush stdout
 set t0 [clock clicks -millisec]
 mportshutdown
 puts "All done ([expr {([clock clicks -millisec]-$t0)}] ms)"
 }}}

 reports an execution time of about 240ms when actually doing the VACUUM
 (with 0 bytes free space) compared to only 2ms when the operation is
 skipped.

 Is it conceivable that the registry ends up in a state where a single
 vacuum operation will never get all free space, or worse, where it's not
 possible to recuperate all free space? Supposing an sqlite DB file can be
 compared to a filesystem such situations can probably arise when the free
 space is fragmented enough.

 Another thought: is there an architecture-related limit here, iow, could
 this have something to do with being on a 32bit machine?

-- 
Ticket URL: <https://trac.macports.org/ticket/70556#comment:11>
MacPorts <https://www.macports.org/>
Ports system for macOS