By closing the file descriptors after creating the lock file we are not
limiting the size of the transaction by the number of available file
descriptors.
Signed-off-by: Stefan Beller <sbel...@google.com>
---
refs.c | 14 +++++++++++++-
t/t1400-update-ref.sh | 4 ++--
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/refs.c b/refs.c
index 0161667..014ef59 100644
--- a/refs.c
+++ b/refs.c
@@ -3068,7 +3068,17 @@ static ssize_t write_in_full_to_lockfile(struct
lock_file *lock,
const void *buf,
size_t count)
{
- return write_in_full(lock->fd, buf, count);
+ if (lock->fd == -1) {
+ int ret;
+ if (reopen_lock_file(lock) < 0)
+ return -1;
+ ret = write_in_full(lock->fd, buf, count);
+ if (close_lock_file(lock) < 0)
+ return -1;
+ return ret;
+ } else {
+ return write_in_full(lock->fd, buf, count);
+ }
}
/*
@@ -3797,6 +3807,8 @@ int ref_transaction_commit(struct ref_transaction
*transaction,
update->refname);
goto cleanup;
}
+ /* Do not keep all lock files open at the same time. */
+ close_lock_file(update->lock->lk);
}
/* Perform updates first so live commits remain referenced */
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index ea98b9b..751b6dc 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -1071,7 +1071,7 @@ run_with_limited_open_files () {
test_lazy_prereq ULIMIT 'run_with_limited_open_files true'
-test_expect_failure ULIMIT 'large transaction creating branches does not burst
open file limit' '
+test_expect_success ULIMIT 'large transaction creating branches does not burst
open file limit' '
(
for i in $(seq 33)
do
@@ -1082,7 +1082,7 @@ test_expect_failure ULIMIT 'large transaction creating
branches does not burst o
)
'
-test_expect_failure ULIMIT 'large transaction deleting branches does not burst
open file limit' '
+test_expect_success ULIMIT 'large transaction deleting branches does not burst
open file limit' '
(
for i in $(seq 33)
do
--
2.2.1.62.g3f15098
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
