PGroonga (fast full text search module for PostgreSQL) 3.1.6 has been released

PGroonga 3.1.6 has been released! PGroonga makes PostgreSQL fast full text search for all languages.


  • Added new option pgroonga.enable_row_level_security.

    This option can configure enable/disable setting of PGroonga'RLS(Row level security) support. Default value is enable. Disabling PGroonga`s RLS support may help to increase performance. However, PGroonga RLS support should not be disabled where PostgreSQL's RLS feature is applied. Disabling PGroonga RLS support in that environment would increase security risk.

    Thus, make sure to check the PostgreSQL's RLS feature is not applied in advance when you are planning to disable PGroonga's RLS support by this option.

    If you are willing to use the setting in the specific session, these SQL can switch enable/disable as follow.

    • Disable RLS support

      SET pgroonga.enable_row_level_security = off
    • Enable RLS support

      SET pgroonga.enable_row_level_security = on

      If you are willing to use the setting in the persistence, these SQL can switch enable/disable as follow.

    • Disable RLS support

      pgroonga.enable_row_level_security = off
    • Enable RLS support

      pgroonga.enable_row_level_security = on
  • Added new type pgroonga_condition. Also added related new function pgroonga_condition() .

    pgroonga_full_text_search_condition type and pgroonga_full_text_search_condition_with_scorers type are now deprecation. pgroonga_condition type is now recommended to use instead of pgroonga_full_text_search_condition type and pgroonga_full_text_search_condition_with_scorers type.

    Queries used with pgroonga full text_search condition type and pgroonga_full_text_search_condition_with_scorers type would change as follow.


      column &@~ ('query', weights, 'scorers', index_name)::pgroonga_full_text_search_condition_with_scorers
      column &@~ ('query', weights, index_name)::pgroonga_full_text_search_condition

    (After changes):

      column &@~ pgroonga_conditon('query', weights, 'scorers', index_name => 'index_name')
      column &@~ pgroonga_conditon('query', weights, index_name => 'index_name')

    Note that 'index_name' requires designating argument name => 'value' style such as index_name => 'index_name'. Here is why 'index_name' is required to be designated as this way.

    Signature of pgroonga condition() is as follows. It is possible to leave out those arguments not required to be designated. Leaving out of the arguments would make unrecognizable where and what arguments are located. Therefore those arguments that has different location from the following signature are required to be designated by writing argument name => 'value' style.

      pgroonga_condition(query text,
                         weights int[],
                         scorers text[],
                         schema_name text,
                         index_name text,
                         column_name text)
  • [For Developers] Added new script to set up building environment. [GitHub#358][Patched by askdkc.]

    Here is how to use. It works in Debian/Ubuntu environment and doesn't work in those distributions delivered from Red Hat Enterprise Linux such as AlmaLinux.

      $ git clone
      $ cd pgroonga
      $ ./ #create an environment to build PGroonga.


  • Fixed the problem not used pgroonga_snippet_html() when update PGroonga 2.4.2 from 2.4.1[Reported by takadat]

  • Fixed the problem that PGroonga crashes when a first argument of pgroonga query expand() designate the tables not normal PostgreSQL.

    For example, PGroonga would crash if a first argument of pgroonga query expand() designate the foreign table as follow.

    CREATE SERVER remote_server
        FOREIGN DATA WRAPPER postgres_fdw
        OPTIONS (host 'localhost', port '5432', dbname 'remote_database');
    CREATE FOREIGN TABLE synonym_groups (
      synonyms text[]
    ) SERVER remote_server;
    SELECT pgroonga_query_expand('synonym_groups',
    server closed the connection unexpectedly
    	This probably means the server terminated abnormally
    	before or while processing the request.
    The connection to the server was lost. Attempting reset: Failed.
  • Fixed the problem that PostgreSQL occurs PANIC by using up stacks to record the errors when there are too many errors within PGroonga.

    This problem occurs when using PGroonga 2.3.3 and later.


  • askdkc
  • takadat

How to upgrade

If you're using PGroonga 2.0.0 or later, you can upgrade by steps in "Compatible case" in Upgrade document.

If you're using PGroonga 1.Y.Z, you can upgrade by steps in "Incompatible case" in Upgrade document.

Support service

If you need commercial support for PGroonga, contact us.


Try PGroonga when you want to perform fast full text search against all languages on PostgreSQL!