Added note to the FAQ about SET search_path and pg_dump

[jamgregory]

We ran into the following issue today: https://gitlab.com/gitlab-org/gitlab-ce/issues/49089

I've added a note to the FAQ about issues around SET search_path so others are aware of it.

[jamgregory]

Hi @petere 👋

Would it be possible to get this merged please?

[petere]

I'm not sure under which circumstances you think this is applicable. By default, PgBouncer is configured to run DISCARD ALL after releasing a server, so there should be no stale session-level settings left behind.

[jamgregory]

This doesn't appear to be the case unfortunately - when we were using PgBouncer with a Rails application. running an affected version of pg_dump caused PgBouncer to lose its search path settings, and the Rails application wouldn't work until PgBouncer was restarted. It may well be an issue with Rails specifically, but I thought it'd be useful to add as a caveat in case others experience the same issue.

[petere]

If we are going to analyze this, you'll need to provide a reproducible test case.

[bduggan]

Hi folks, I can confirm that this behavior does exist; I've seen it with pg_dump version 10.6. Merging this PR would be great, unless there is a recommended configuration setting that would avoid it?

[markokr]

I am pretty sure you are talking about using pg_dump with pgbouncer running with pool_mode=transaction.

It is already documented that only subset of PostgreSQL features will work in such mode.

It would be mistake to document search_path as somehow being special case in respect to that.

[bduggan]

Hi @markokr -- thanks for the response! Yes, you are correct, this is in pool_mode=transaction.

I am not suggest documenting this as a special_case, but rather calling out the fact that what is normally a very benign operation -- using pg_dump -- can in fact be extremely disruptive.

Perhaps the wording can be adjusted to say that this only applies in pool_mode=transaction.