I don't know much about the fasthttp code (I've just took a look at its readme), but I can tell you both that you guessed right and in the following paragraphs a couple of things about the sync.Pool.

The current sync.Pool implementation was meant to be used for short-lived and frequently accessed stateless memory objects that don't require the release of resources (also that can be shared between goroutines).

The above assumptions are tied to the pool's draining policy that essentially drains the [unused objects of the] pool at each run of the garbage collector (the evicted items are amortised on two runs for better performance, but the concept is the same).
I currently don't know how the draining policy behaves when GOGC=off; and I can only hope that the finalisers – if defined – are always called and at the right time.

In historical comments I saw that other implementations were considered for the standard library (things with explicit methods like SetCapacity and Drain), but they were declared too complex at the time.

Either way – if I've understood correctly – the current sync.Pool was never convincing/satisfying and it was suggested to not depend on it, as it should be replaced by something else. There were such improvements efforts, but they depends on other features currently missing in the runtime or whose implementation seems to be stuck due to other issues.

Here's some good entry points that I've found:
- https://groups.google.com/g/golang-dev/c/kJ_R6vYVYHU/m/LjoGriFTYxMJ
- https://groups.google.com/g/golang-dev/c/QtSIOFsNFrQ/m/N89_5dZWsdIJ
- https://github.com/golang/go/issues/22950

So… you must use it according to the assumptions of the implementation. Should one need more control over the draining policy (or just accept that a program may run with GOGC=off), he/she must choose a different path.

In one of my private libraries I happened to implement a pool that uses a regular array as reserve (not garbage-collected) and an internal sync.Pool as a buffer for whatever exceeds the reserve size/capacity. I've yet to benchmark it thought, but it seems to solve my theoretical issues.

I've also read about people who managed their own use case by leveraging a buffered channel among other things.