| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
It now returns #f or a list, rather than the empty list or a nested list.
|
| |
|
|
| |
As it excludes the channel instances and system tests.
|
| | |
|
| |
|
|
| |
To be targets, rather than systems.
|
| | |
|
| |
|
|
| |
This might help at least handle errors when inserting data in to PostgreSQL.
|
| |
|
|
|
| |
I saw an error suggesting that something came back that wasn't a number, and
this should give a more informative error.
|
| |
|
|
|
|
| |
This might give more insight to the [1] errors occuring for some builds.
1: error: couldn't find data for locale in ()
|
| |
|
|
| |
As I think par-map& is probably no faster.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
To allow using the Guix Data Service when commits aren't authenticated.
|
| |
|
|
|
|
|
|
|
|
| |
Previously, if an exception occurred during the processing of any but the last
letpar& expression, the replies for the other expressions would never be
fetched, resulting in that thread in the pool just waiting for a receiver for
the message.
To avoid this, make sure to read all the replies before raising any
exceptions.
|
| |
|
|
|
| |
Previously the render-unknown-revision procedure would error, as it wasn't
meant for this purpose.
|
| |
|
|
|
|
| |
Previously the package_derivations table wasn't considered, which would mean
derivations would still be referenced. This commit fixes that, along with also
deleting unreferenced entries in some linter related tables.
|
| | |
|
| |
|
|
| |
It was pretty wrong...
|
| | |
|
| |
|
|
|
|
| |
Some revisions have got disassociated from branches, probably because they
were associated with multiple branches in the first place. This should allow
deleting them.
|
| |
|
|
| |
As these were causing errors because they were nested in letpar&.
|
| |
|
|
|
|
|
|
|
|
|
| |
Channels don't represent some channel on which messages travel, at least not a
very long one because it can't accommodate any messages. They simply represent
a direct exchange of the message between a sender and receiver. Because of
this, put-message blocks the fiber, and if all the threads on the other end
are waiting for replies to be received, then you have a deadlock.
To avoid this situation, spawn new fibers to send the messages. I think this
works at least, although I'm unsure how sensible it is.
|
| |
|
|
| |
Later is better than never...
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, a connection was passed through the code handling the
request. When queries were performed, this could block the thread though,
potentially leaving the server unable to serve other requests.
Instead, this now runs queries in a pool of threads. This should remove the
possibility of blocking the threads used by the web server, and in doing so,
some of the queries have been parallelised.
I''m still not sure about the naming and syntax, but I think the functionality
is a sort of step forward.
|
| |
|
|
|
|
|
| |
In to a generic thing more like (ice-9 futures). Including copying some bits
from the (ice-9 threads) module and adapting them to work with this fibers
approach, rather than futures. The advantage being that using fibers channels
doesn't block the threads being used by fibers, whereas futures would.
|
| |
|
|
|
|
|
| |
This was good in that it avoided having to deal with long running connections,
but it probably takes some time to open the connection, and these changes are
a step towards offloading the PostgreSQL queries to other threads, so they
don't block the threads for fibers.
|
| | |
|
| |
|
|
| |
So this can be reused.
|
| |
|
|
| |
This will also delete unreferenced derivation_source_file_nars.
|
| |
|
|
| |
As this speeds up deleting derivation_source_files.
|
| | |
|
| |
|
|
|
|
| |
I've not used these in many places, to try and avoid hiding deleting data, but
in this case, this will allow more easily deleting the derivation source file
nars, by just deleting the derivation_source_files table entry.
|
| | |
|
| |
|
|
|
| |
This change removes a sequential scan from the query plan, making it much
faster.
|
| |
|
|
|
|
| |
Looking at data for the the patches deployment of the Guix Data Service, these
tables look like they might benefit from vacuuming/analyzing more often, so
adjust the configuration so this will hopefully happen.
|
| |
|
|
| |
As apparently they can be NULL.
|
| |
|
|
| |
Hopefully this'll help track database things better.
|
| |
|
|
| |
At least for data deletion, 4 seems unnecessary.
|
| |
|
|
| |
In an attempt to make this faster.
|
| |
|
|
| |
As this is harder to do when deleting derivations in parallel.
|
| |
|
|
| |
Not much different from before, but this will allow parallelising things.
|
| |
|
|
| |
To allow for some concurrency.
|
| |
|
|
| |
As this is covered by the big query selecting the derivation ids.
|
| |
|
|
| |
As this probably won't help with performance.
|
| |
|
|
|
|
| |
Stop querying for the file-name, as it's unused. Rather than fetching all ids,
then looking at each to see if it can be deleted, do some imperfect but not
too slow checks in the initial query.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|