00:00 < ossifrage> Does upgrading the txindex database have the same io/time cost as just rebuilding the index? It seems to be grinding away rather slowly

00:07 < phantomcircuit> ossifrage, it should be substantially cheaper

00:09 < ossifrage> phantomcircuit, thanks, I remember the initial txindex build being painful thanks to depressingly slow spinning rust

00:09 < phantomcircuit> rebuilding would have to go rescan the entire chain again

00:09 < phantomcircuit> the upgrade is, iirc just reading the existing database and writting a new one

00:10 < ossifrage> 10% took ~21minutes

00:10 < phantomcircuit> but i guess it might be rebuilding anyways?

00:10 < phantomcircuit> no idea

00:12 < ossifrage> One of the iothreads has already written 28GB (way more then any thread has read)

00:13 < sipa> that's expected for leveldb

00:17 < phantomcircuit> sipa, is it reading the previous database and writting out, or reindexing?

00:17 < sipa> converting the previous db

01:23 < fanquake> wumpus nice speedup in #13151

01:23 < gribble> https://github.com/bitcoin/bitcoin/issues/13151 | net: Serve blocks directly from disk when possible by laanwj · Pull Request #13151 · bitcoin/bitcoin · GitHub

01:23 < fanquake> I'll try and recreate your results using bitcoincore-indexd

02:49 < ossifrage> Ouch, after a really long time running the txindex upgrade, I ran out of disk :-(

03:44 < bitcoin-git> [bitcoin] ken2812221 opened pull request #13171: [WIP] Change gitian-descriptors to use bionic instead (master...gitian) https://github.com/bitcoin/bitcoin/pull/13171

04:30 < bitcoin-git> [bitcoin] OldMiR opened pull request #13172: Remove double MSG_DONTWAIT (master...master) https://github.com/bitcoin/bitcoin/pull/13172

08:20 < jonasschnelli> 2018-05-05T08:07:56Z Upgrading txindex database... [0%]

08:20 < jonasschnelli> 2018-05-05T08:15:04Z Upgrading txindex database... [10%]

08:21 < jonasschnelli> If we haven't, we probably should mention that in the release notes (that the upgrade is pretty slow)

13:10 < bitcoin-git> [bitcoin] jnewbery closed pull request #10554: ZMQ: add publishers for wallet transactions. (master...zmq_wallet_tx) https://github.com/bitcoin/bitcoin/pull/10554

14:21 < pierre_rochard> I’ve added high priority for review to https://bitcoinacks.com/ it’s a little intrusive having them pinned at the top but, well, that’s the point!

14:23 < pierre_rochard> luke-jr: the filters are unintuitive so I’ve added an Open PRs button at the top as a shortcut, since that’s a popular set of filters. I looked into the horizontal scroll and the framework I’m using does too much magick for me to change its behavior

14:34 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f82e1c948212...66cc47be982a

14:34 < bitcoin-git> bitcoin/master cbba1d2 practicalswift: Add compile time checking for all ::mempool.cs runtime locking assertions

14:35 < bitcoin-git> bitcoin/master 66cc47b MarcoFalke: Merge #13080: mempool: Add compile time checking for ::mempool.cs runtime locking assertions...

14:35 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #13080: mempool: Add compile time checking for ::mempool.cs runtime locking assertions (master...mempool.cs) https://github.com/bitcoin/bitcoin/pull/13080

15:06 < fanquake> pierre_rochard nice

15:07 < fanquake> pierre_rochard Looks like you are showing a lot more of the body text now? I think there might be a bit too much showing, as it ends up with quite tall rows.

15:09 < fanquake> i.e https://0bin.net/paste/OQbnisqm6+JxruVd#usS48X+UEn5ZIOBZUrbtTWfodm4avG9vrwDTInmvIWX

15:12 < pierre_rochard> fanquake: agree, I’m spoiled with a 4k monitor, I’m going to remove body from the list view for now because I don’t think a shorter preview would be useful, the full body will still be visible with the details modal (the eye button on the left)

17:52 < BlueMatt> sdaftuar: wait, huh? I'm missing context here

17:53 < BlueMatt> sdaftuar: generally, you should be able to register before any callbacks fire

17:53 < BlueMatt> and if you're registered before a calllback is generated, you're guaranteed to get it

18:56 < jamesob> is there any reason that LogPrintf et al live on as macros vs. being functions on BCLog::Logger?

18:58 < sipa> jamesob: yes, avoiding serialization overhead of its arguments when debug category is disabled

18:59 < jamesob> sipa: thanks, good to know