Hello,
I checked it again, when I set
ALTER DATABASE "MyDatabase" SET default_text_search_config TO 'german';
and I try to connect through psql, I get following:
psql: Fehler: Verbindung zum Server auf »192.168.153.26«, Port 5432 fehlgeschlagen: Server beendete die Verbindung unerwartet
Das heißt wahrscheinlich, dass der Server abnormal beendete
bevor oder während die Anweisung bearbeitet wurde.
In english it would be similar like following:
>psql postgresql://user1:admin@192.168.153.26:5432/MyDatabase
psql: Error: Connection to server at "192.168.153.26", port 5432 failed: The server unexpectedly closed the connection This likely means that the server terminated abnormally before or while processing the request.
In pgAdmin I am loosing the connection to the database and when I click on the server node in the treeview I am loosing the complete connection to the server.
Strangely my alter statement has to be like following to prevent the explained error:
ALTER DATABASE "MyDatabase" SET default_text_search_config TO 'pg_catalog.german';
Prefixed with the "pg_catalog." literal.
Well, thats my 2 cents to this topic. I had no issues till version 17 :-)
So my question is: Whats the error? The missing prefix before version 17, but the PostgreSQL was tolerant OR the new version bcz something changed to be more stricttly????
best regards murat
Erik Wienhold <ewie@ewie.name> writes:
>> I can reproduce a segfault on my Arch machine with 17.0, but only by
>> also connecting to that database afterwards:
>>
>> postgres=# create database regress;
>> postgres=# alter database regress set default_text_search_config to 'german';
>> postgres=# \c regress
>> connection to server at "localhost" (::1), port 15432 failed: server closed the connection unexpectedly
>> This probably means the server terminated abnormally
>> before or while processing the request.
Yeah, I see that too (with any value of default_text_search_config).
The problem is that InitPostgres does
/* Process pg_db_role_setting options */
process_settings(MyDatabaseId, GetSessionUserId());
before it calls InitializeSearchPath(), and recomputeNamespacePath
isn't ready for that. Evidently broken in f26c2368d.
I suppose we could just move the InitializeSearchPath call up
a bit (the comments in postinit.c are misleading about what it
actually does), but I wonder whether the cache-is-valid assumptions
in namespace.c ought to be rethought. It seems unduly fragile
as-is.
regards, tom lane
