Some Rooms Require Over 20GB Storage

Nobody has claimed this yet.

**Describe the bug**
On the "Fetching state from DB for room" step, storage space is continuously consumed until space is empty, errors, then frees the space. Might be related to #6 (maybe even a duplicate?), but I'm talking about storage space, not memory. I only have 14GB storage right now, but two of my rooms with only 110141 and 167096 state groups can't seem to have this tool successfully run, because I run out of storage.

**To Reproduce**
Honestly not sure how you'd reproduce it. I can't see anyone else with the issue, it happens when I run it on `!zTAqnOWiFuKTlnGOhq:matrix.thedisco.zone` and `!tmgqjKkMXUbqUHECPV:matrix.thedisco.zone`, I don't know what those rooms are.

**Expected behavior**
Same as when I run on any other room, consumes a bit of storage, then finishes normally.

**VPS:**
- OS: Debian 10
- DB: Postgres 11.9

I have ~14GB storage free, and 3GB RAM available while running this tool.

**Additional context**

Command run: `./synapse-compress-state -t -o state-compressor.sql -p "host=localhost user= password= dbname=" -r "!zTAqnOWiFuKTlnGOhq:matrix.thedisco.zone"`

Error received:
```
thread 'main' panicked at 'called `Result::unwrap()`on an`Err` value: Error { kind: Db, cause: Some(DbError { severity: "ERROR", parsed_severity: Some(Error), code: SqlState("53100"), message: "could not write to file \"base/pgsql_tmp/pgsql_tmp810.0.sharedfileset/i2924of8192.p0.0\": No space left on device", detail: None, hint: None, position: None, where_: None, schema: None, table: None, column: None, datatype: None, constraint: None, file: Some("buffile.c"), line: Some(526), routine: Some("BufFileDumpBuffer") }) }', src/libcore/result.rs:1188:5
```

It seems to be a postgresql error. So if this is an upstream issue I guess this can be closed. However it would be nice to understand why this happens on these rooms and not others. I'm currently running it on larger rooms, and I'm not even noticing storage being consumed, but that room wants to use over 14GB.

I'm still running this on several rooms, I'll update if I notice anything else related.

Start with the synapse-compress-state command and the PostgreSQL 11.9 setup, using the two reported room IDs and the logged pgsql_tmp error as the reproduction target. Compare state-fetch behavior for affected and unaffected rooms, then determine whether the tool can complete without exhausting temporary storage or whether this is an upstream PostgreSQL limitation.

Written by the indexing model from the issue text.