Re: easy way of copying regex_t

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>
Cc: pgsql-hackers(at)postgresql(dot)org, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Subject: Re: easy way of copying regex_t
Date: 2016-01-24 21:41:30
Message-ID: 21779.1453671690@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru> writes:
> With this message I want to send some patch to your repository with
> draft of a code, which allows shared_ispell to copy regex_t.

Allowing ispell.c to know that much about regex internals strikes me as
completely unacceptable from a modularity or maintainability standpoint.
If we want to do that, the appropriate thing would be to add a function
to backend/regex/ that copies a regex_t.

However, I'm rather suspicious of the safety of copying a regex_t into
shared memory in the first place. It contains function pointers, which
we have not historically assumed would be portable between different
backend processes. And the regex library is old enough to have never
heard of thread safety, so I'm not really sure that it considers the
regex_t structures to be read-only at execution time.

> shared_ispell loads dictionaries into a shared memory. The main benefits
> are:
> - saving of memory. Every dictionary is loaded only once. Dictionaries
> are not loaded for each backend. In current version of PostgreSQL
> dictionaires are loaded for each backend where it was requested.
> - saving of time. The first load of a dictionary takes much time. With
> this patch dictionaries will be loaded only once.

Where does the shared memory space come from? It would not take too
many dictionaries to use up whatever slop is available.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dickson S. Guedes 2016-01-24 22:54:44 Re: Why format() adds double quote?
Previous Message David Rowley 2016-01-24 21:25:30 Re: Removing Functionally Dependent GROUP BY Columns