give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "The new implementation of Database.sync introduced on DM-24355 is subject to deadlocks, as first reported [here|https://lsstc.slack.com/archives/C2JPT1KB7/p1603061206230500].    This is actually a problem with any code that uses the {{lock}} argument to {{Database.transaction}}, because that acquires a SHARED lock (in PostgreSQL) that can be owned by multiple readers, and when both readers then try to upgrade to a more exclusive lock for writing, we get a deadlock.    A partial, simple, possibly-good-enough-for-now fix is to do at a table level what we already do at a full-database level in SQLite - make explicit transaction locking EXCLUSIVE, and thus force any other processes waiting for a lock to block.  It looks like (according to the [PostgreSQL|https://www.postgresql.org/docs/current/explicit-locking.html] docs) this does not prevent concurrent reads from the same table.  This is only a partial fix because I think the exclusive lock probably needs to be acquired at the outermost transaction context in order to force blocking instead of deadlocks.  That's in daf_butler's control in the Datastore case that's causing problems now, but it's in obs_base or skymap code in other concrete {{Database.sync}} usage contexts, and since {{Registry.transaction}} is a public API we can't control usage from spreading to other external code a swell.  I think the only way to express that in terms of interfaces is to go back to the original idea of this ticket, which is to make {{Database.sync}} itself into a context manager that cannot be nested within other transactions, but which starts its own transaction context in which other operations can be nested.    Anyhow, given that the intended usage of {{Database.sync}} is primarily on small, infrequently modified tables (like those that track {{instruments}} and {{Datastore}} s), I don't think that locking is likely to be a problem, except perhaps for our usage of {{sync}} on {{exposure}} in raw ingest (but even there, let's just keep an eye on that and deal with it if it becomes a problem).  Longer-term, I there's an alternate approach to all of this that uses SERIALIZABLE transaction isolation and retries instead of explicit locking, and that may scale better to more concurrency as well as be more database-agnostic.  But that's a lot harder to map to a usable Python interface, because those retries need to include all database calls in the same transaction context, not just those invoked by {{Database.sync}}, and that means we need to remember those calls in the Python layer rather than forward them on to SQLAlchemy immediately.  DM-26302 will probably require interface changes that would be similar to the kinds of interface changes this would require (i.e. having {{Database.transaction}} return a connection-holding object that would be used to make database calls, instead of those happening on the {{Database}} itself).    I am leaning towards just using this ticket for the simple/partial fix, and deferring future API-change work to other tickets, because aside from the Datastore creation race problem (which the simple fix should address), any other problems should be both extremely rare and work-around-able via manual retries.  I'll open other tickets for future work when I close this one, if necessary."
Answer: 364.0