pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedRe: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows.
12+ messages / 3 participants
[nested] [flat]
* Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows.
@ 2009-04-02 08:50 Magnus Hagander <magnus@hagander.net>
2009-04-08 10:36 ` Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
0 siblings, 1 reply; 12+ messages in thread
From: Magnus Hagander @ 2009-04-02 08:50 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgreSQL.org
Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Tom Lane wrote:
>>> What makes more sense to me is to add a table to encnames.c that
>>> provides the gettext name of every encoding that we support.
>
>> Do you mean a separate table there, or should we add a new column to one
>> of the existing tables?
>
> Whichever seems to make more sense is fine with me. I just don't want
> add-an-encoding maintenance requirements spread across N different
> source files.
I was about to start looking at this when that other thread
(http://archives.postgresql.org//pgsql-hackers/2009-03/msg01270.php)
started about related issues on other platforms. Seems we should have a
"coordinated fix" for this, so I'm going to want and see what come sout
of that one. Unless I'm misunderstanding thigns and they're not related?
//Magnus
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows.
2009-04-02 08:50 Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Magnus Hagander <magnus@hagander.net>
@ 2009-04-08 10:36 ` Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
2009-04-20 09:37 ` Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Magnus Hagander <magnus@hagander.net>
0 siblings, 1 reply; 12+ messages in thread
From: Heikki Linnakangas @ 2009-04-08 10:36 UTC (permalink / raw)
To: Magnus Hagander <magnus@hagander.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers@postgreSQL.org
Magnus Hagander wrote:
> Tom Lane wrote:
>> Magnus Hagander <magnus@hagander.net> writes:
>>> Tom Lane wrote:
>>>> What makes more sense to me is to add a table to encnames.c that
>>>> provides the gettext name of every encoding that we support.
>>> Do you mean a separate table there, or should we add a new column to one
>>> of the existing tables?
>> Whichever seems to make more sense is fine with me. I just don't want
>> add-an-encoding maintenance requirements spread across N different
>> source files.
>
> I was about to start looking at this when that other thread
> (http://archives.postgresql.org//pgsql-hackers/2009-03/msg01270.php)
> started about related issues on other platforms. Seems we should have a
> "coordinated fix" for this, so I'm going to want and see what come sout
> of that one. Unless I'm misunderstanding thigns and they're not related?
I've committed a fairly trivial patch per Peter's suggestion to fix the
other thread's issue. I left the table as is, so whatever refactorings
were planned can now be applied.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows.
2009-04-02 08:50 Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Magnus Hagander <magnus@hagander.net>
2009-04-08 10:36 ` Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
@ 2009-04-20 09:37 ` Magnus Hagander <magnus@hagander.net>
2009-04-20 14:38 ` Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 12+ messages in thread
From: Magnus Hagander @ 2009-04-20 09:37 UTC (permalink / raw)
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers@postgreSQL.org
Heikki Linnakangas wrote:
> Magnus Hagander wrote:
>> Tom Lane wrote:
>>> Magnus Hagander <magnus@hagander.net> writes:
>>>> Tom Lane wrote:
>>>>> What makes more sense to me is to add a table to encnames.c that
>>>>> provides the gettext name of every encoding that we support.
>>>> Do you mean a separate table there, or should we add a new column to
>>>> one
>>>> of the existing tables?
>>> Whichever seems to make more sense is fine with me. I just don't want
>>> add-an-encoding maintenance requirements spread across N different
>>> source files.
>>
>> I was about to start looking at this when that other thread
>> (http://archives.postgresql.org//pgsql-hackers/2009-03/msg01270.php)
>> started about related issues on other platforms. Seems we should have a
>> "coordinated fix" for this, so I'm going to want and see what come sout
>> of that one. Unless I'm misunderstanding thigns and they're not related?
>
> I've committed a fairly trivial patch per Peter's suggestion to fix the
> other thread's issue. I left the table as is, so whatever refactorings
> were planned can now be applied.
Here's a patch that moves the table over to encnames.c, and renames it
to look like the others.
I don't know what it should be doing if it can't find a match, so I
haven't changed that behavior.
Comments?
//Magnus
Attachments:
enctable.patch (text/x-diff, 3.7K) download
*** a/src/backend/utils/mb/encnames.c
--- b/src/backend/utils/mb/encnames.c
***************
*** 431,436 **** pg_enc2name pg_enc2name_tbl[] =
--- 431,478 ----
};
/* ----------
+ * These are encoding names for gettext.
+ * ----------
+ */
+ pg_enc2gettext pg_enc2gettext_tbl[] =
+ {
+ {PG_UTF8, "UTF-8"},
+ {PG_LATIN1, "LATIN1"},
+ {PG_LATIN2, "LATIN2"},
+ {PG_LATIN3, "LATIN3"},
+ {PG_LATIN4, "LATIN4"},
+ {PG_ISO_8859_5, "ISO-8859-5"},
+ {PG_ISO_8859_6, "ISO_8859-6"},
+ {PG_ISO_8859_7, "ISO-8859-7"},
+ {PG_ISO_8859_8, "ISO-8859-8"},
+ {PG_LATIN5, "LATIN5"},
+ {PG_LATIN6, "LATIN6"},
+ {PG_LATIN7, "LATIN7"},
+ {PG_LATIN8, "LATIN8"},
+ {PG_LATIN9, "LATIN-9"},
+ {PG_LATIN10, "LATIN10"},
+ {PG_KOI8R, "KOI8-R"},
+ {PG_KOI8U, "KOI8-U"},
+ {PG_WIN1250, "CP1250"},
+ {PG_WIN1251, "CP1251"},
+ {PG_WIN1252, "CP1252"},
+ {PG_WIN1253, "CP1253"},
+ {PG_WIN1254, "CP1254"},
+ {PG_WIN1255, "CP1255"},
+ {PG_WIN1256, "CP1256"},
+ {PG_WIN1257, "CP1257"},
+ {PG_WIN1258, "CP1258"},
+ {PG_WIN866, "CP866"},
+ {PG_WIN874, "CP874"},
+ {PG_EUC_CN, "EUC-CN"},
+ {PG_EUC_JP, "EUC-JP"},
+ {PG_EUC_KR, "EUC-KR"},
+ {PG_EUC_TW, "EUC-TW"},
+ {PG_EUC_JIS_2004, "EUC-JP"}
+ };
+
+
+ /* ----------
* Encoding checks, for error returns -1 else encoding id
* ----------
*/
*** a/src/backend/utils/mb/mbutils.c
--- b/src/backend/utils/mb/mbutils.c
***************
*** 890,936 **** cliplen(const char *str, int len, int limit)
return l;
}
- #if defined(ENABLE_NLS)
- static const struct codeset_map {
- int encoding;
- const char *codeset;
- } codeset_map_array[] = {
- {PG_UTF8, "UTF-8"},
- {PG_LATIN1, "LATIN1"},
- {PG_LATIN2, "LATIN2"},
- {PG_LATIN3, "LATIN3"},
- {PG_LATIN4, "LATIN4"},
- {PG_ISO_8859_5, "ISO-8859-5"},
- {PG_ISO_8859_6, "ISO_8859-6"},
- {PG_ISO_8859_7, "ISO-8859-7"},
- {PG_ISO_8859_8, "ISO-8859-8"},
- {PG_LATIN5, "LATIN5"},
- {PG_LATIN6, "LATIN6"},
- {PG_LATIN7, "LATIN7"},
- {PG_LATIN8, "LATIN8"},
- {PG_LATIN9, "LATIN-9"},
- {PG_LATIN10, "LATIN10"},
- {PG_KOI8R, "KOI8-R"},
- {PG_KOI8U, "KOI8-U"},
- {PG_WIN1250, "CP1250"},
- {PG_WIN1251, "CP1251"},
- {PG_WIN1252, "CP1252"},
- {PG_WIN1253, "CP1253"},
- {PG_WIN1254, "CP1254"},
- {PG_WIN1255, "CP1255"},
- {PG_WIN1256, "CP1256"},
- {PG_WIN1257, "CP1257"},
- {PG_WIN1258, "CP1258"},
- {PG_WIN866, "CP866"},
- {PG_WIN874, "CP874"},
- {PG_EUC_CN, "EUC-CN"},
- {PG_EUC_JP, "EUC-JP"},
- {PG_EUC_KR, "EUC-KR"},
- {PG_EUC_TW, "EUC-TW"},
- {PG_EUC_JIS_2004, "EUC-JP"}
- };
- #endif /* ENABLE_NLS */
-
void
SetDatabaseEncoding(int encoding)
{
--- 890,895 ----
***************
*** 969,980 **** pg_bind_textdomain_codeset(const char *domainname)
return;
#endif
! for (i = 0; i < lengthof(codeset_map_array); i++)
{
! if (codeset_map_array[i].encoding == encoding)
{
if (bind_textdomain_codeset(domainname,
! codeset_map_array[i].codeset) == NULL)
elog(LOG, "bind_textdomain_codeset failed");
break;
}
--- 928,939 ----
return;
#endif
! for (i = 0; pg_enc2gettext_tbl[i].name != NULL; i++)
{
! if (pg_enc2gettext_tbl[i].encoding == encoding)
{
if (bind_textdomain_codeset(domainname,
! pg_enc2gettext_tbl[i].name) == NULL)
elog(LOG, "bind_textdomain_codeset failed");
break;
}
*** a/src/include/mb/pg_wchar.h
--- b/src/include/mb/pg_wchar.h
***************
*** 262,267 **** typedef struct pg_enc2name
--- 262,278 ----
extern pg_enc2name pg_enc2name_tbl[];
/*
+ * Encoding names for gettext
+ */
+ typedef struct pg_enc2gettext
+ {
+ pg_enc encoding;
+ const char *name;
+ } pg_enc2gettext;
+
+ extern pg_enc2gettext pg_enc2gettext_tbl[];
+
+ /*
* pg_wchar stuff
*/
typedef int (*mb2wchar_with_len_converter) (const unsigned char *from,
* Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows.
2009-04-02 08:50 Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Magnus Hagander <magnus@hagander.net>
2009-04-08 10:36 ` Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
2009-04-20 09:37 ` Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Magnus Hagander <magnus@hagander.net>
@ 2009-04-20 14:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-04-20 14:50 ` Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
2009-04-24 08:44 ` Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Magnus Hagander <magnus@hagander.net>
0 siblings, 2 replies; 12+ messages in thread
From: Tom Lane @ 2009-04-20 14:38 UTC (permalink / raw)
To: Magnus Hagander <magnus@hagander.net>; +Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; pgsql-hackers@postgresql.org
Magnus Hagander <magnus@hagander.net> writes:
> Tom Lane wrote:
>>> What makes more sense to me is to add a table to encnames.c that
>>> provides the gettext name of every encoding that we support.
> Here's a patch that moves the table over to encnames.c, and renames it
> to look like the others.
I think you forgot to include the NULL terminating entry that the
loop seems to be expecting. Also, why isn't the array "const"?
> I don't know what it should be doing if it can't find a match, so I
> haven't changed that behavior.
As things stand, it should throw error, except in the case of SQL_ASCII;
there is no excuse for any other database encoding to not be in the
table. However, what seems more worrisome to me is the prospect already
discussed that the codeset name we have in the table is not actually
recognized by gettext/iconv. Did we have a solution for that?
Anyway, this fixes my immediate concern about where the info is located,
so you may as well apply it with the array-terminator fix.
regards, tom lane
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows.
2009-04-02 08:50 Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Magnus Hagander <magnus@hagander.net>
2009-04-08 10:36 ` Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
2009-04-20 09:37 ` Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Magnus Hagander <magnus@hagander.net>
2009-04-20 14:38 ` Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-04-20 14:50 ` Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
1 sibling, 0 replies; 12+ messages in thread
From: Heikki Linnakangas @ 2009-04-20 14:50 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Magnus Hagander <magnus@hagander.net>; pgsql-hackers@postgresql.org
Tom Lane wrote:
> However, what seems more worrisome to me is the prospect already
> discussed that the codeset name we have in the table is not actually
> recognized by gettext/iconv. Did we have a solution for that?
You get English.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows.
2009-04-02 08:50 Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Magnus Hagander <magnus@hagander.net>
2009-04-08 10:36 ` Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
2009-04-20 09:37 ` Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Magnus Hagander <magnus@hagander.net>
2009-04-20 14:38 ` Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-04-24 08:44 ` Magnus Hagander <magnus@hagander.net>
1 sibling, 0 replies; 12+ messages in thread
From: Magnus Hagander @ 2009-04-24 08:44 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; pgsql-hackers@postgresql.org
Tom Lane wrote:
>> I don't know what it should be doing if it can't find a match, so I
>> haven't changed that behavior.
>
> As things stand, it should throw error, except in the case of SQL_ASCII;
> there is no excuse for any other database encoding to not be in the
> table. However, what seems more worrisome to me is the prospect already
> discussed that the codeset name we have in the table is not actually
> recognized by gettext/iconv. Did we have a solution for that?
>
> Anyway, this fixes my immediate concern about where the info is located,
> so you may as well apply it with the array-terminator fix.
Done.
//Magnus
^ permalink raw reply [nested|flat] 12+ messages in thread
* pgsql: Clean up Windows-specific mutex code in libpq and ecpglib.
@ 2024-02-09 16:21 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 12+ messages in thread
From: Tom Lane @ 2024-02-09 16:21 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Clean up Windows-specific mutex code in libpq and ecpglib.
Fix pthread-win32.h and pthread-win32.c to provide a more complete
emulation of POSIX pthread mutexes: define PTHREAD_MUTEX_INITIALIZER
and make sure that pthread_mutex_lock() can operate on a mutex
object that's been initialized that way. Then we don't need the
duplicative platform-specific logic in default_threadlock() and
pgtls_init(), which we'd otherwise need yet a third copy of for
an upcoming bug fix.
Also, since default_threadlock() supposes that pthread_mutex_lock()
cannot fail, try to ensure that that's actually true, by getting
rid of the malloc call that was formerly involved in initializing
an emulated mutex. We can define an extra state for the spinlock
field instead.
Also, replace the similar code in ecpglib/misc.c with this version.
While ecpglib's version at least had a POSIX-compliant API, it
also had the potential of failing during mutex init (but here,
because of CreateMutex failure rather than malloc failure). Since
all of misc.c's callers ignore failures, it seems like a wise idea
to avoid failures here too.
A further improvement in this area could be to unify libpq's and
ecpglib's implementations into a src/port/pthread-win32.c file.
But that doesn't seem like a bug fix, so I'll desist for now.
In preparation for the aforementioned bug fix, back-patch to all
supported branches.
Discussion: https://postgr.es/m/264860.1707163416@sss.pgh.pa.us
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/0028b55bc8e2fc80816094620d116e2cbbd8e5f3
Modified Files
--------------
src/interfaces/ecpg/ecpglib/misc.c | 37 +++++++++++++++++++-----
src/interfaces/ecpg/include/ecpg-pthread-win32.h | 22 +++++---------
src/interfaces/libpq/fe-connect.c | 16 ----------
src/interfaces/libpq/fe-secure-openssl.c | 20 -------------
src/interfaces/libpq/pthread-win32.c | 26 ++++++++++-------
src/port/pthread-win32.h | 11 ++++++-
6 files changed, 63 insertions(+), 69 deletions(-)
^ permalink raw reply [nested|flat] 12+ messages in thread
* pgsql: Clean up Windows-specific mutex code in libpq and ecpglib.
@ 2024-02-09 16:21 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 12+ messages in thread
From: Tom Lane @ 2024-02-09 16:21 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Clean up Windows-specific mutex code in libpq and ecpglib.
Fix pthread-win32.h and pthread-win32.c to provide a more complete
emulation of POSIX pthread mutexes: define PTHREAD_MUTEX_INITIALIZER
and make sure that pthread_mutex_lock() can operate on a mutex
object that's been initialized that way. Then we don't need the
duplicative platform-specific logic in default_threadlock() and
pgtls_init(), which we'd otherwise need yet a third copy of for
an upcoming bug fix.
Also, since default_threadlock() supposes that pthread_mutex_lock()
cannot fail, try to ensure that that's actually true, by getting
rid of the malloc call that was formerly involved in initializing
an emulated mutex. We can define an extra state for the spinlock
field instead.
Also, replace the similar code in ecpglib/misc.c with this version.
While ecpglib's version at least had a POSIX-compliant API, it
also had the potential of failing during mutex init (but here,
because of CreateMutex failure rather than malloc failure). Since
all of misc.c's callers ignore failures, it seems like a wise idea
to avoid failures here too.
A further improvement in this area could be to unify libpq's and
ecpglib's implementations into a src/port/pthread-win32.c file.
But that doesn't seem like a bug fix, so I'll desist for now.
In preparation for the aforementioned bug fix, back-patch to all
supported branches.
Discussion: https://postgr.es/m/264860.1707163416@sss.pgh.pa.us
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/9440d23a018cab5e78cb4aa11e8a5c558dd0bb36
Modified Files
--------------
src/interfaces/ecpg/ecpglib/misc.c | 37 +++++++++++++++++++-----
src/interfaces/ecpg/include/ecpg-pthread-win32.h | 22 +++++---------
src/interfaces/libpq/fe-connect.c | 16 ----------
src/interfaces/libpq/fe-secure-openssl.c | 20 -------------
src/interfaces/libpq/pthread-win32.c | 26 ++++++++++-------
src/port/pthread-win32.h | 11 ++++++-
6 files changed, 63 insertions(+), 69 deletions(-)
^ permalink raw reply [nested|flat] 12+ messages in thread
* pgsql: Clean up Windows-specific mutex code in libpq and ecpglib.
@ 2024-02-09 16:21 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 12+ messages in thread
From: Tom Lane @ 2024-02-09 16:21 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Clean up Windows-specific mutex code in libpq and ecpglib.
Fix pthread-win32.h and pthread-win32.c to provide a more complete
emulation of POSIX pthread mutexes: define PTHREAD_MUTEX_INITIALIZER
and make sure that pthread_mutex_lock() can operate on a mutex
object that's been initialized that way. Then we don't need the
duplicative platform-specific logic in default_threadlock() and
pgtls_init(), which we'd otherwise need yet a third copy of for
an upcoming bug fix.
Also, since default_threadlock() supposes that pthread_mutex_lock()
cannot fail, try to ensure that that's actually true, by getting
rid of the malloc call that was formerly involved in initializing
an emulated mutex. We can define an extra state for the spinlock
field instead.
Also, replace the similar code in ecpglib/misc.c with this version.
While ecpglib's version at least had a POSIX-compliant API, it
also had the potential of failing during mutex init (but here,
because of CreateMutex failure rather than malloc failure). Since
all of misc.c's callers ignore failures, it seems like a wise idea
to avoid failures here too.
A further improvement in this area could be to unify libpq's and
ecpglib's implementations into a src/port/pthread-win32.c file.
But that doesn't seem like a bug fix, so I'll desist for now.
In preparation for the aforementioned bug fix, back-patch to all
supported branches.
Discussion: https://postgr.es/m/264860.1707163416@sss.pgh.pa.us
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/9f041b041feb3361748496e5813cd3a5b034361c
Modified Files
--------------
src/interfaces/ecpg/ecpglib/misc.c | 37 +++++++++++++++++++-----
src/interfaces/ecpg/include/ecpg-pthread-win32.h | 22 +++++---------
src/interfaces/libpq/fe-connect.c | 16 ----------
src/interfaces/libpq/fe-secure-openssl.c | 20 -------------
src/interfaces/libpq/pthread-win32.c | 26 ++++++++++-------
src/port/pthread-win32.h | 11 ++++++-
6 files changed, 63 insertions(+), 69 deletions(-)
^ permalink raw reply [nested|flat] 12+ messages in thread
* pgsql: Clean up Windows-specific mutex code in libpq and ecpglib.
@ 2024-02-09 16:21 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 12+ messages in thread
From: Tom Lane @ 2024-02-09 16:21 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Clean up Windows-specific mutex code in libpq and ecpglib.
Fix pthread-win32.h and pthread-win32.c to provide a more complete
emulation of POSIX pthread mutexes: define PTHREAD_MUTEX_INITIALIZER
and make sure that pthread_mutex_lock() can operate on a mutex
object that's been initialized that way. Then we don't need the
duplicative platform-specific logic in default_threadlock() and
pgtls_init(), which we'd otherwise need yet a third copy of for
an upcoming bug fix.
Also, since default_threadlock() supposes that pthread_mutex_lock()
cannot fail, try to ensure that that's actually true, by getting
rid of the malloc call that was formerly involved in initializing
an emulated mutex. We can define an extra state for the spinlock
field instead.
Also, replace the similar code in ecpglib/misc.c with this version.
While ecpglib's version at least had a POSIX-compliant API, it
also had the potential of failing during mutex init (but here,
because of CreateMutex failure rather than malloc failure). Since
all of misc.c's callers ignore failures, it seems like a wise idea
to avoid failures here too.
A further improvement in this area could be to unify libpq's and
ecpglib's implementations into a src/port/pthread-win32.c file.
But that doesn't seem like a bug fix, so I'll desist for now.
In preparation for the aforementioned bug fix, back-patch to all
supported branches.
Discussion: https://postgr.es/m/264860.1707163416@sss.pgh.pa.us
Branch
------
REL_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/7d7cc7fd6fbdfca68fe144476078c03d3c36e158
Modified Files
--------------
src/interfaces/ecpg/ecpglib/misc.c | 37 +++++++++++++++++++-----
src/interfaces/ecpg/include/ecpg-pthread-win32.h | 22 +++++---------
src/interfaces/libpq/fe-connect.c | 16 ----------
src/interfaces/libpq/fe-secure-openssl.c | 20 -------------
src/interfaces/libpq/pthread-win32.c | 26 ++++++++++-------
src/port/pthread-win32.h | 11 ++++++-
6 files changed, 63 insertions(+), 69 deletions(-)
^ permalink raw reply [nested|flat] 12+ messages in thread
* pgsql: Clean up Windows-specific mutex code in libpq and ecpglib.
@ 2024-02-09 16:21 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 12+ messages in thread
From: Tom Lane @ 2024-02-09 16:21 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Clean up Windows-specific mutex code in libpq and ecpglib.
Fix pthread-win32.h and pthread-win32.c to provide a more complete
emulation of POSIX pthread mutexes: define PTHREAD_MUTEX_INITIALIZER
and make sure that pthread_mutex_lock() can operate on a mutex
object that's been initialized that way. Then we don't need the
duplicative platform-specific logic in default_threadlock() and
pgtls_init(), which we'd otherwise need yet a third copy of for
an upcoming bug fix.
Also, since default_threadlock() supposes that pthread_mutex_lock()
cannot fail, try to ensure that that's actually true, by getting
rid of the malloc call that was formerly involved in initializing
an emulated mutex. We can define an extra state for the spinlock
field instead.
Also, replace the similar code in ecpglib/misc.c with this version.
While ecpglib's version at least had a POSIX-compliant API, it
also had the potential of failing during mutex init (but here,
because of CreateMutex failure rather than malloc failure). Since
all of misc.c's callers ignore failures, it seems like a wise idea
to avoid failures here too.
A further improvement in this area could be to unify libpq's and
ecpglib's implementations into a src/port/pthread-win32.c file.
But that doesn't seem like a bug fix, so I'll desist for now.
In preparation for the aforementioned bug fix, back-patch to all
supported branches.
Discussion: https://postgr.es/m/264860.1707163416@sss.pgh.pa.us
Branch
------
REL_13_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/67f8cf0f0acae970f1b1b61e97a9df4c3e88303e
Modified Files
--------------
src/interfaces/ecpg/ecpglib/misc.c | 37 +++++++++++++++++++-----
src/interfaces/ecpg/include/ecpg-pthread-win32.h | 22 +++++---------
src/interfaces/libpq/fe-connect.c | 16 ----------
src/interfaces/libpq/fe-secure-openssl.c | 20 -------------
src/interfaces/libpq/pthread-win32.c | 26 ++++++++++-------
src/port/pthread-win32.h | 11 ++++++-
6 files changed, 63 insertions(+), 69 deletions(-)
^ permalink raw reply [nested|flat] 12+ messages in thread
* pgsql: Clean up Windows-specific mutex code in libpq and ecpglib.
@ 2024-02-09 16:21 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 12+ messages in thread
From: Tom Lane @ 2024-02-09 16:21 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Clean up Windows-specific mutex code in libpq and ecpglib.
Fix pthread-win32.h and pthread-win32.c to provide a more complete
emulation of POSIX pthread mutexes: define PTHREAD_MUTEX_INITIALIZER
and make sure that pthread_mutex_lock() can operate on a mutex
object that's been initialized that way. Then we don't need the
duplicative platform-specific logic in default_threadlock() and
pgtls_init(), which we'd otherwise need yet a third copy of for
an upcoming bug fix.
Also, since default_threadlock() supposes that pthread_mutex_lock()
cannot fail, try to ensure that that's actually true, by getting
rid of the malloc call that was formerly involved in initializing
an emulated mutex. We can define an extra state for the spinlock
field instead.
Also, replace the similar code in ecpglib/misc.c with this version.
While ecpglib's version at least had a POSIX-compliant API, it
also had the potential of failing during mutex init (but here,
because of CreateMutex failure rather than malloc failure). Since
all of misc.c's callers ignore failures, it seems like a wise idea
to avoid failures here too.
A further improvement in this area could be to unify libpq's and
ecpglib's implementations into a src/port/pthread-win32.c file.
But that doesn't seem like a bug fix, so I'll desist for now.
In preparation for the aforementioned bug fix, back-patch to all
supported branches.
Discussion: https://postgr.es/m/264860.1707163416@sss.pgh.pa.us
Branch
------
REL_12_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/95e960e811b0699847912ecd8697f0d35c1ba38a
Modified Files
--------------
src/interfaces/ecpg/ecpglib/misc.c | 37 +++++++++++++++++++-----
src/interfaces/ecpg/include/ecpg-pthread-win32.h | 22 +++++---------
src/interfaces/libpq/fe-connect.c | 16 ----------
src/interfaces/libpq/fe-secure-openssl.c | 20 -------------
src/interfaces/libpq/pthread-win32.c | 26 ++++++++++-------
src/port/pthread-win32.h | 11 ++++++-
6 files changed, 63 insertions(+), 69 deletions(-)
^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2024-02-09 16:21 UTC | newest]
Thread overview: 12+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-04-02 08:50 Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. Magnus Hagander <magnus@hagander.net>
2009-04-08 10:36 ` Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
2009-04-20 09:37 ` Magnus Hagander <magnus@hagander.net>
2009-04-20 14:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-04-20 14:50 ` Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
2009-04-24 08:44 ` Magnus Hagander <magnus@hagander.net>
2024-02-09 16:21 pgsql: Clean up Windows-specific mutex code in libpq and ecpglib. Tom Lane <tgl@sss.pgh.pa.us>
2024-02-09 16:21 pgsql: Clean up Windows-specific mutex code in libpq and ecpglib. Tom Lane <tgl@sss.pgh.pa.us>
2024-02-09 16:21 pgsql: Clean up Windows-specific mutex code in libpq and ecpglib. Tom Lane <tgl@sss.pgh.pa.us>
2024-02-09 16:21 pgsql: Clean up Windows-specific mutex code in libpq and ecpglib. Tom Lane <tgl@sss.pgh.pa.us>
2024-02-09 16:21 pgsql: Clean up Windows-specific mutex code in libpq and ecpglib. Tom Lane <tgl@sss.pgh.pa.us>
2024-02-09 16:21 pgsql: Clean up Windows-specific mutex code in libpq and ecpglib. Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox