sapling/tests/test-hgsql-sync-interval.t
Jun Wu 9cf0c87149 hgsql: log rows read and write
Summary:
This gives us more information about how large the hgsql operation is.

As we're here, move `sqlwriteunlock` to an earlier place so the logging is outside
the sql lock. Also document `unbundle` a bit so it's clear `repo.transaction()` only
takes sql lock in `unbundle` context.

Reviewed By: phillco

Differential Revision: D10056307

fbshipit-source-id: 5d3361b4044e6fcf01e60409ef1ecb34da34ccac
2018-09-26 16:35:14 -07:00

130 lines
3.3 KiB
Perl

Test hgsql tries to sync before entering the critical section
$ . "$TESTDIR/hgsql/library.sh"
$ setconfig hgsql.verbose=1
$ newrepo state1
$ hg debugdrawdag << 'EOS'
> B
> |
> A
> EOS
$ newrepo state2
$ hg debugdrawdag << 'EOS'
> C
> |
> B
> |
> A
> EOS
$ newrepo state3
$ hg debugdrawdag << 'EOS'
> D
> |
> C
> |
> B
> |
> A
> EOS
$ newrepo state4
$ hg debugdrawdag << 'EOS'
> E
> |
> D
> |
> C
> |
> B
> |
> A
> EOS
$ cd $TESTTMP
$ initserver repo1 master
$ initserver repo2 master
$ initserver repo3 master
$ initserver repo4 master
Repo1: 2 commits. Sync them to the database.
$ cd $TESTTMP/repo1
$ hg pull -r tip $TESTTMP/state1
[hgsql] got lock after * seconds (read 1 rows) (glob)
pulling from $TESTTMP/state1
adding changesets
adding manifests
adding file changes
added 2 changesets with 2 changes to 2 files
new changesets 426bada5c675:112478962961
(run 'hg update' to get a working copy)
[hgsql] held lock for * seconds (read 5 rows; write 8 rows) (glob)
Repo2: Emulate client push. Hold the lock for long.
$ cd $TESTTMP/repo2
$ hg --config hooks.pretxnclose.dely='sleep 6' pull -r tip $TESTTMP/state2 &>out &
$ disown
Repo 3: Emulate client push to sql, after repo2.
$ sleep 2
$ cd $TESTTMP/repo3
$ hg --config hooks.pretxnclose.dely='sleep 6' pull -r tip $TESTTMP/state3 &>out &
$ disown
Emulate writing to another repo when the lock was held elsewhere.
Explaination:
- The first "getting 2 commits from database" is because repo4 is empty, and the database has A,B synced from repo1.
- The second "getting 1 commits from database" is because repo2 push completes.
- The third "getting 1 commits from database" is because repo3 push completes.
$ cd $TESTTMP/repo4
$ setconfig hgsql.syncinterval=0.1 hgsql.debugminsqllockwaittime=13
$ hg pull -r tip $TESTTMP/state4
[hgsql] getting 2 commits from database
[hgsql] getting 1 commits from database
[hgsql] getting 1 commits from database
[hgsql] got lock after * seconds (read * rows) (glob)
pulling from $TESTTMP/state4
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
new changesets 9bc730a19041
(run 'hg update' to get a working copy)
[hgsql] held lock for * seconds (read * rows; write 7 rows) (glob)
Make sure repo2 and repo3 log looks sane.
$ cat $TESTTMP/repo2/out
[hgsql] getting 2 commits from database
[hgsql] got lock after * seconds (read 1 rows) (glob)
pulling from $TESTTMP/state2
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
new changesets 26805aba1e60
(run 'hg update' to get a working copy)
[hgsql] held lock for * seconds (read 6 rows; write 7 rows) (glob)
$ cat $TESTTMP/repo3/out
[hgsql] getting 2 commits from database
[hgsql] got lock after * seconds (read 1 rows) (glob)
[hgsql] getting 1 commits from database
pulling from $TESTTMP/state3
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
new changesets f585351a92f8
(run 'hg update' to get a working copy)
[hgsql] held lock for * seconds (read 6 rows; write 7 rows) (glob)