public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v27 5/5] Doc: Add Collation Versions section.
5+ messages / 3 participants
[nested] [flat]
* [PATCH v27 5/5] Doc: Add Collation Versions section.
@ 2020-03-11 02:01 Thomas Munro <[email protected]>
0 siblings, 0 replies; 5+ messages in thread
From: Thomas Munro @ 2020-03-11 02:01 UTC (permalink / raw)
Supply a brief introduction to collation version concepts.
Author: Thomas Munro <[email protected]>
Reviewed-by: Julien Rouhaud <[email protected]>
Discussion: https://postgr.es/m/CAEepm%3D0uEQCpfq_%2BLYFBdArCe4Ot98t1aR4eYiYTe%3DyavQygiQ%40mail.gmail.com
---
doc/src/sgml/charset.sgml | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/doc/src/sgml/charset.sgml b/doc/src/sgml/charset.sgml
index 4b4563c5b9..12a82ff18c 100644
--- a/doc/src/sgml/charset.sgml
+++ b/doc/src/sgml/charset.sgml
@@ -948,6 +948,41 @@ CREATE COLLATION ignore_accents (provider = icu, locale = 'und-u-ks-level1-kc-tr
</tip>
</sect3>
</sect2>
+
+ <sect2 id="collation-versions">
+ <title>Collation Versions</title>
+
+ <para>
+ The ordering defined by a collation is not necessarily fixed over time.
+ If a collation changes for any reason, persistent data structures such as
+ b-trees that depend on a stable ordering of text might be corrupted.
+ <productname>PostgreSQL</productname> defends against this by recording
+ the current version of each referenced collation for any index that
+ depends on it in the
+ <link linkend="catalog-pg-depend"><structname>pg_depend</structname></link>
+ catalog, if the collation provider makes it available. If the provider
+ later begins to report a different version, a warning will be issued
+ when the index is accessed, until either the <xref linkend="sql-reindex"/>
+ or the <xref linkend="sql-alterindex"/> command is used to update the
+ version.
+ </para>
+ <para>
+ Version information is available for collations from the
+ <literal>icu</literal> provider on all operating systems. For the
+ <literal>libc</literal> provider, versions are currently only available
+ on systems using the GNU C library (most Linux systems).
+ </para>
+
+ <note>
+ <para>
+ When using the GNU C library for collations, the C library's version
+ is used as a proxy for the collation version. Many Linux distributions
+ change collation definitions only when upgrading the C library, but this
+ approach is imperfect as maintainers are free to back-port newer
+ collation definitions to older C library releases.
+ </para>
+ </note>
+ </sect2>
</sect1>
<sect1 id="multibyte">
--
2.20.1
--o56keubw4jpehgac--
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name
@ 2023-03-15 09:38 Daniel Gustafsson <[email protected]>
2023-04-20 23:32 ` Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name Nathan Bossart <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Gustafsson @ 2023-03-15 09:38 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Yurii Rashkovskii <[email protected]>; [email protected]
> On 13 Mar 2023, at 18:35, Nathan Bossart <[email protected]> wrote:
>
> On Mon, Mar 13, 2023 at 07:57:47AM -0700, Yurii Rashkovskii wrote:
>> However, there are use cases where [potentially] longer names are
>> expected/desired; for example, test benches (where library files may not
>> [or can not] be copied to Postgres installation) or alternative library
>> installation methods that do not put them into $libdir.
>>
>> The patch is backwards-compatible and ensures that bgw_library_name stays
>> *at least* as long as BGW_MAXLEN. Existing external code that uses
>> BGW_MAXLEN is a length boundary (for example, in `strncpy`) will continue
>> to work as expected.
>
> I see that BGW_MAXLEN was originally set to 64 in 2013 (7f7485a) [0], but
> was increased to 96 in 2018 (3a4b891) [1]. It seems generally reasonable
> to me to increase the length of bgw_library_name further for the use-case
> you describe, but I wonder if it'd be better to simply increase BGW_MAXLEN
> again. However, IIUC bgw_library_name is the only field that is likely to
> be used for absolute paths, so only increasing that one to MAXPGPATH makes
> sense.
Yeah, raising just bgw_library_name to MAXPGPATH seems reasonable here. While
the memory usage does grow it's still quite modest, and has an upper limit in
max_worker_processes.
While here, I wonder if we should document what BGW_MAXLEN is defined as in
bgworker.sgml?
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name
2023-03-15 09:38 Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name Daniel Gustafsson <[email protected]>
@ 2023-04-20 23:32 ` Nathan Bossart <[email protected]>
2023-04-21 08:49 ` Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name Daniel Gustafsson <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Nathan Bossart @ 2023-04-20 23:32 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; +Cc: Yurii Rashkovskii <[email protected]>; [email protected]
On Wed, Mar 15, 2023 at 10:38:34AM +0100, Daniel Gustafsson wrote:
> While here, I wonder if we should document what BGW_MAXLEN is defined as in
> bgworker.sgml?
I am -0.5 for this. If you are writing a new background worker, it's
probably reasonable to expect that you can locate the definition of
BGW_MAXLEN. Also, I think there's a good chance that we'd forget to update
such documentation the next time we adjust it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name
2023-03-15 09:38 Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name Daniel Gustafsson <[email protected]>
2023-04-20 23:32 ` Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name Nathan Bossart <[email protected]>
@ 2023-04-21 08:49 ` Daniel Gustafsson <[email protected]>
2023-04-21 20:44 ` Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name Nathan Bossart <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Gustafsson @ 2023-04-21 08:49 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Yurii Rashkovskii <[email protected]>; [email protected]
> On 21 Apr 2023, at 01:32, Nathan Bossart <[email protected]> wrote:
>
> On Wed, Mar 15, 2023 at 10:38:34AM +0100, Daniel Gustafsson wrote:
>> While here, I wonder if we should document what BGW_MAXLEN is defined as in
>> bgworker.sgml?
>
> I am -0.5 for this. If you are writing a new background worker, it's
> probably reasonable to expect that you can locate the definition of
> BGW_MAXLEN.
Of course. The question is if it's a helpful addition for someone who is
reading the documentation section on implementing background workers where we
explicitly mention BGW_MAXLEN without saying what it is.
> Also, I think there's a good chance that we'd forget to update
> such documentation the next time we adjust it.
There is that, but once set to MAXPGPATH it seems unlikely to change
particularly often so it seems the wrong thing to optimize for.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name
2023-03-15 09:38 Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name Daniel Gustafsson <[email protected]>
2023-04-20 23:32 ` Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name Nathan Bossart <[email protected]>
2023-04-21 08:49 ` Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name Daniel Gustafsson <[email protected]>
@ 2023-04-21 20:44 ` Nathan Bossart <[email protected]>
0 siblings, 0 replies; 5+ messages in thread
From: Nathan Bossart @ 2023-04-21 20:44 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; +Cc: Yurii Rashkovskii <[email protected]>; [email protected]
On Fri, Apr 21, 2023 at 10:49:48AM +0200, Daniel Gustafsson wrote:
> On 21 Apr 2023, at 01:32, Nathan Bossart <[email protected]> wrote:
>> I am -0.5 for this. If you are writing a new background worker, it's
>> probably reasonable to expect that you can locate the definition of
>> BGW_MAXLEN.
>
> Of course. The question is if it's a helpful addition for someone who is
> reading the documentation section on implementing background workers where we
> explicitly mention BGW_MAXLEN without saying what it is.
IMHO it's better to have folks use the macro so that their calls to
snprintf(), etc. are updated when BGW_MAXLEN is changed. But I can't say
I'm strongly opposed to adding the value to the docs if you think it is
helpful.
>> Also, I think there's a good chance that we'd forget to update
>> such documentation the next time we adjust it.
>
> There is that, but once set to MAXPGPATH it seems unlikely to change
> particularly often so it seems the wrong thing to optimize for.
True.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2023-04-21 20:44 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-03-11 02:01 [PATCH v27 5/5] Doc: Add Collation Versions section. Thomas Munro <[email protected]>
2023-03-15 09:38 Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name Daniel Gustafsson <[email protected]>
2023-04-20 23:32 ` Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name Nathan Bossart <[email protected]>
2023-04-21 08:49 ` Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name Daniel Gustafsson <[email protected]>
2023-04-21 20:44 ` Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name Nathan Bossart <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox