docs(postgres): recommend ForSQL strategy

[greg0ire]

While trying to use a postgres containers and using ForLog(), we had a tests that worked locally, but failed on the CI, for some reason. Searching the web, one can stumble upon https://www.xavierbouclet.com/2022/08/08/TestContainer-Wait-DB-SQL.html If somebody went through the trouble of writing a whole blog post about this, chances are this issue is not uncommon.
Also, the SQL strategy was contributed after the log strategy, which might explain why it wasn't default recommendation.

[netlify]

✅ Deploy Preview for testcontainers-go ready!

Name	Link
🔨 Latest commit	0daaffc
🔍 Latest deploy log	https://app.netlify.com/sites/testcontainers-go/deploys/65cf3784b8279d000845bd2a
😎 Deploy Preview	https://deploy-preview-2208--testcontainers-go.netlify.app/modules/postgres
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[mdelapenya]

Thanks for this PR! I'm interested in how you discovered it: is it that you copied the example from pkg.go.dev?

[greg0ire]

No, there is a dedicated documentation page for that strategy (I would link it if I wasn't on my phone).

EDIT: I'm back home: https://golang.testcontainers.org/features/wait/sql/

[eddumelendez]

Hi, one missing thing about the shared blogpost is related to how the postgres container is started:

1. Container start
2. Postgres service start
3. Postgres service stop
4. Postgres service start

After that, the container and service is ready to use. The blogpost uses the default strategy, which is wait for an open port but this could be available in step 2 causing flaky tests. SQL wait strategy could cause the same. The PostgreSQLContainer implementation relies in the wait strategy instead due to an empty container logs twice the database system is ready to accept connections but a data volume is mounted then it is logged once. But, that's a different issue.

[greg0ire]

@eddumelendez it's unclear to me what makes you say that the postgres container is started in 4 steps rather than just 2. Would you care to elaborate?

[eddumelendez]

@greg0ire start a postgres container and see the logs to check what I mention

[greg0ire]

Ok, I've tried it, so let me explain this a bit more to everyone else:

1. The container starts
2. It detects if the database already exists or not
3. Based on that, it either creates the database or skips initialization
4. It starts

In case there is no database, there seems indeed to be a start and stop of the server: https://github.com/docker-library/postgres/blob/1424abf76f421d6f7bf933d9e42bbbed866fae3a/16/bookworm/docker-ensure-initdb.sh#L46C2-L51

That start is "socket only", and "does not listen on external TCP/IP". Maybe we could somehow find a way to leverage that?

[JordanP]

True that if the DATA_DIR is empty, PG will start "2 times". But that's why the WithOccurrence(2) line is here. So I am not sure this PR is a big improvement .... Is there a way to reproduce (ideally "consistently") what you observed ?

[greg0ire]

I didn't experience it first hand, @joseboretto did. Let's close this so as not to waste more maintainer time on this, and open an issue if we come up with a reproducer instead.

[mdelapenya]

Thanks @greg0ire for coming back to the issue and close it 🙇 🙏