Translations contributions urgently needed

Hi, I have found that Japanese language support for the database server has been dropped for 10. This is because it fell below the 80% of strings translated requirement, so it was shipped without Japanese. This isn't true of all components, but it seems quite alarming that we've pushed out

Re: Translations contributions urgently needed

On 22 February 2018 at 17:24, Magnus Hagander <mag...@hagander.net> wrote: > On Thu, Feb 22, 2018 at 6:20 PM, Thom Brown <t...@linux.com> wrote: >> >> Hi, >> >> I have found that Japanese language support for the database server >> has been dropped

Re: Translations contributions urgently needed

On 23 February 2018 at 04:04, Tom Lane wrote: > Alvaro Herrera writes: >> Please join pgsql-translat...@postgresql.org. > > What surprises me about this thread is that apparently the sad state > of the v10 translations wasn't already discussed on that

SQL/JSON path issues/questions

Hi, I've been reading through the documentation regarding jsonpath and jsonb_path_query etc., and I have found it lacking explanation for some functionality, and I've also had some confusion when using the feature. ? operator == The first mention of '?' is in section 9.15, where it says:

Re: SQL/JSON path issues/questions

On Fri, 14 Jun 2019 at 08:16, Kyotaro Horiguchi wrote: > > Hi, Thom. > > At Thu, 13 Jun 2019 14:59:51 +0100, Thom Brown wrote > in > > Hi, > > > > I've been reading through the documentation regarding jsonpath and > > jsonb_path_query etc., and I have fo

Re: SQL/JSON path issues/questions

On Thu, 13 Jun 2019 at 14:59, Thom Brown wrote: > > Hi, > > I've been reading through the documentation regarding jsonpath and > jsonb_path_query etc., and I have found it lacking explanation for > some functionality, and I've also had some confusion when using the > fe

Re: SQL/JSON path issues/questions

On Wed, 19 Jun 2019 at 20:04, Alexander Korotkov wrote: > > On Wed, Jun 19, 2019 at 7:07 PM Thom Brown wrote: > > On Thu, 13 Jun 2019 at 14:59, Thom Brown wrote: > > > > > > Hi, > > > > > > I've been reading through the documentation regarding

Re: SQL/JSON path issues/questions

On Wed, 10 Jul 2019 at 05:58, Alexander Korotkov wrote: > > On Mon, Jul 8, 2019 at 12:30 AM Alexander Korotkov > wrote: > > On Thu, Jul 4, 2019 at 4:38 PM Liudmila Mantrova > > wrote: > > > Thank you! > > > > > > I think we can make this sentence even shorter, the fix is attached: > > > > > >

Re: SQL/JSON path issues/questions

On Thu, 11 Jul 2019 at 16:23, Alexander Korotkov wrote: > > On Thu, Jul 11, 2019 at 5:10 PM Thom Brown wrote: > > On Wed, 10 Jul 2019 at 05:58, Alexander Korotkov > > wrote: > > > > > > On Mon, Jul 8, 2019 at 12:30 AM Alexander Korotkov > > >

Re: SQL/JSON path issues/questions

On Tue, 16 Jul 2019 at 19:44, Alexander Korotkov wrote: > > On Tue, Jul 16, 2019 at 9:22 PM Thom Brown wrote: > > Now I'm looking at the @? and @@ operators, and getting a bit > > confused. This following query returns true, but I can't determine > > why: > >

Re: [HACKERS] Look-behind regular expressions

On Tue, 29 Jun 2010 at 17:49, David E. Wheeler wrote: > > On Jun 29, 2010, at 7:44 AM, Thom Brown wrote: > > >> No. Or are you volunteering? > > > > A n00b like me volunteer for that? It's more of a suggestion. > > N00bs gotta start somewhere… 10 years la

Multi-byte character case-folding

Hi, At the moment, only single-byte characters in identifiers are case-folded, and multi-byte characters are not. For example, abĉDĚF is case-folded to "abĉdĚf". This can be referred to as "abĉdĚf" or "ABĉDĚF", but not "abĉděf" or "ABĈDĚF". downcase_identifier() has the following comment:

Blank archive_command

Hi, Should archive_command being blank when archiving is enabled result in a fatal error? This doesn't even produce a warning when restarting, just an entry in the log when it goes to archive a WAL segment, and finds the archive_command is empty. Is there a valid scenario where someone would

Re: Blank archive_command

On Mon, 17 Jan 2022 at 15:25, Bharath Rupireddy wrote: > > On Mon, Jan 17, 2022 at 8:14 PM Thom Brown wrote: > > > > Hi, > > > > Should archive_command being blank when archiving is enabled result in > > a fatal error? This doesn't even produce a warnin

Re: [COMMITTERS] pgsql: Allow time delayed standbys and recovery

On Tue, 5 Apr 2022 at 16:02, Robert Haas wrote: > > On Tue, Apr 5, 2022 at 10:58 AM Magnus Hagander wrote: > >> Makes sense. I will do this soon if nobody objects. > >> > >> I'm mildly uncomfortable with the phrase "WAL records generated over > >> the delay period" because it seems a bit

Re: [COMMITTERS] pgsql: Allow time delayed standbys and recovery

On Wed, 6 Apr 2022 at 01:42, Thom Brown wrote: > > On Tue, 5 Apr 2022 at 16:02, Robert Haas wrote: > > > > On Tue, Apr 5, 2022 at 10:58 AM Magnus Hagander wrote: > > >> Makes sense. I will do this soon if nobody objects. > > >> > > >>

Re: [COMMITTERS] pgsql: Allow time delayed standbys and recovery

On Mon, 11 Apr 2022, 15:55 Robert Haas, wrote: > On Fri, Apr 8, 2022 at 11:10 AM Robert Haas wrote: > > On Fri, Apr 8, 2022 at 10:45 AM Thom Brown wrote: > > > Thanks. This doesn't include my self-correction: > > > > > > s/kept on standby/kept on the stan

Re: generalized conveyor belt storage

On Wed, 20 Apr 2022 at 13:02, Alvaro Herrera wrote: > > What's with the free text in cbstorage.h? I would guess that this > wouldn't even compile, and nobody has noticed because the file is not > included by anything yet ... I'm not able to compile: cbfsmpage.c: In function

Re: [COMMITTERS] pgsql: Allow time delayed standbys and recovery

On Fri, 8 Apr 2022, 14:36 Robert Haas, wrote: > On Wed, Apr 6, 2022 at 8:15 AM Robert Haas wrote: > > On Tue, Apr 5, 2022 at 8:43 PM Thom Brown wrote: > > > I share your discomfort with the wording. How about: > > > > > > WAL records must be kept on standb

Re: [PoC] Reducing planning time when tables have many partitions

On Mon, 5 Dec 2022 at 21:28, David Rowley wrote: > > On Tue, 6 Dec 2022 at 04:45, Thom Brown wrote: > > Testing your patches with the same 1024 partitions, each with 64 > > sub-partitions, I get a planning time of 205.020 ms, which is now a > > 1,377x speedup. This

Re: [PoC] Reducing planning time when tables have many partitions

On Sun, 4 Dec 2022 at 00:35, David Rowley wrote: > > On Tue, 29 Nov 2022 at 21:59, Yuya Watari wrote: > > Thank you for testing the patch with an actual query. This speedup is > > very impressive. When I used an original query with 1024 partitions, > > its planning time was about 200ms. Given

Re: [PoC] Reducing planning time when tables have many partitions

On Mon, 7 Nov 2022 at 06:33, Zhang Mingli wrote: > > HI, > > Regards, > Zhang Mingli > On Nov 7, 2022, 14:26 +0800, Tom Lane , wrote: > > Andrey Lepikhov writes: > > I'm still in review of your patch now. At most it seems ok, but are you > really need both eq_sources and eq_derives lists now? >

Re: [PoC] Reducing planning time when tables have many partitions

On Thu, 17 Nov 2022 at 11:20, Thom Brown wrote: > > On Thu, 17 Nov 2022 at 09:31, Alvaro Herrera wrote: > > > > On 2022-Nov-16, Thom Brown wrote: > > > > > Once the issue Tom identified has been resolved, I'd like to test > > > drive newer patches. >

Re: [PoC] Reducing planning time when tables have many partitions

On Thu, 17 Nov 2022 at 09:31, Alvaro Herrera wrote: > > On 2022-Nov-16, Thom Brown wrote: > > > Once the issue Tom identified has been resolved, I'd like to test > > drive newer patches. > > What issue? If you mean the one from the thread "Reducing > duplicat

Re: Add 64-bit XIDs into PostgreSQL 15

On Thu, 3 Nov 2022 at 08:12, Maxim Orlov wrote: > > Hi! > >> I attach an additional V48-0009 patch as they are just comments, apply it if >> you want to. > > Big thank you for your review. I've applied your addition in the recent patch > set below. > > Besides, mentioned above, next changes are

Remove references to pre-11 versions

Hi, I've attached a patch that removes some now redundant messaging about unsupported versions. Regards Thom old_version_removal.patch Description: Binary data

Re: Remove references to pre-11 versions

On Wed, 19 Apr 2023 at 14:58, Tom Lane wrote: > > Thom Brown writes: > > I've attached a patch that removes some now redundant messaging about > > unsupported versions. > > If we want to make that a policy, I think a lot more could be done > --- I remember noticing a

Various typo fixes

Hi, I've attached a patch with a few typo and grammatical fixes. Regards Thom various_typos_and_grammar_fixes.patch Description: Binary data

Re: Various typo fixes

On Tue, 11 Apr 2023 at 15:39, Justin Pryzby wrote: > > On Tue, Apr 11, 2023 at 03:36:02PM +0100, Thom Brown wrote: > > I've attached a patch with a few typo and grammatical fixes. > > I think you actually sent the "git-diff" manpage :( Oh dear, well that's a first.

Re: Disabling Heap-Only Tuples

On Thu, 6 Jul 2023 at 21:18, Matthias van de Meent wrote: > > On Wed, 5 Jul 2023 at 19:55, Thom Brown wrote: > > > > On Wed, 5 Jul 2023 at 18:05, Matthias van de Meent > > wrote: > > > So what were you thinking of? A session GUC? A table option? >

Re: generic plans and "initial" pruning

On Tue, 18 Jul 2023, 08:26 Amit Langote, wrote: > Hi Thom, > > On Tue, Jul 18, 2023 at 1:33 AM Thom Brown wrote: > > On Thu, 13 Jul 2023 at 13:59, Amit Langote > wrote: > > > In an absolutely brown-paper-bag moment, I realized that I had not > > > updated sr

Re: generic plans and "initial" pruning

On Thu, 13 Jul 2023 at 13:59, Amit Langote wrote: > In an absolutely brown-paper-bag moment, I realized that I had not > updated src/backend/executor/README to reflect the changes to the > executor's control flow that this patch makes. That is, after > scrapping the old design back in January

Re: Disabling Heap-Only Tuples

On Wed, 19 Jul 2023, 13:58 Laurenz Albe, wrote: > On Thu, 2023-07-06 at 22:18 +0200, Matthias van de Meent wrote: > > On Wed, 5 Jul 2023 at 19:55, Thom Brown wrote: > > > > > > On Wed, 5 Jul 2023 at 18:05, Matthias van de Meent > > > wrote: > > >

Re: Disabling Heap-Only Tuples

On Wed, 5 Jul 2023 at 13:12, Matthias van de Meent wrote: > > On Wed, 5 Jul 2023 at 13:03, Thom Brown wrote: > > > > On Wed, 5 Jul 2023 at 11:57, Matthias van de Meent > > wrote: > > > > > > On Wed, 5 Jul 2023 at 12:45, Thom Brown wrote: > > >

Re: Allow specifying a dbname in pg_basebackup connection string

On Mon, 3 Jul 2023 at 13:23, Jelte Fennema wrote: > > Normally it doesn't really matter which dbname is used in the connection > string that pg_basebackup and other physical replication CLI tools use. > The reason being, that physical replication does not work at the > database level, but instead

Re: Disabling Heap-Only Tuples

On Wed, 5 Jul 2023 at 11:57, Matthias van de Meent wrote: > > On Wed, 5 Jul 2023 at 12:45, Thom Brown wrote: > > Heap-Only Tuple (HOT) updates are a significant performance > > enhancement, as they prevent unnecessary page writes. However, HOT > > comes with a caveat:

Disabling Heap-Only Tuples

Hi, Heap-Only Tuple (HOT) updates are a significant performance enhancement, as they prevent unnecessary page writes. However, HOT comes with a caveat: it means that if we have lots of available space earlier on in the relation, it can only be used for new tuples or in cases where there's

Re: Disabling Heap-Only Tuples

On Wed, 5 Jul 2023 at 18:05, Matthias van de Meent wrote: > > On Wed, 5 Jul 2023 at 14:39, Thom Brown wrote: > > > > On Wed, 5 Jul 2023 at 13:12, Matthias van de Meent > > wrote: > > > > > > On Wed, 5 Jul 2023 at 13:03, Thom Brown wrote: > > &

Re: Allow specifying a dbname in pg_basebackup connection string

On Wed, 5 Jul 2023 at 16:50, Jelte Fennema wrote: > > On Wed, 5 Jul 2023 at 16:01, Euler Taveira wrote: > > One of the PgBouncer's missions is to be a transparent proxy. > > > > Sometimes you cannot reach out the database directly due to a security > > policy. > > Indeed the transparent proxy

Does a cancelled REINDEX CONCURRENTLY need to be messy?

Hi, It's documented that a failed REINDEX can leave behind a transient index, and I'm not going to speculate on all the conditions that could lead to this situation. However, cancelling a REINDEX CONCURRENTLY will reliably leave behind the index it was building (_ccnew). Doesn't a cancellation

Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?

On Thu, 29 Jun 2023, 14:45 Álvaro Herrera, wrote: > ALTER TABLE DETACH CONCURRENTLY had to deal with this also, and it did it > by having a COMPLETE option you can run later in case things got stuck the > first time around. I suppose we could do something similar, where the > server

Re: trying again to get incremental backup

On Wed, 3 Jan 2024 at 15:10, Robert Haas wrote: > On Fri, Dec 22, 2023 at 12:00 AM Alexander Lakhin > wrote: > > My quick experiment shows that that TimestampDifferenceMilliseconds call > > always returns zero, due to it's arguments swapped. > > Thanks. Tom already changed the unsigned -> int

Automatic tablespace management in pg_basebackup

Hi, Manually specifying tablespace mappings in pg_basebackup, especially in environments where tablespaces can come and go, or with incremental backups, can be tedious and error-prone. I propose a solution using pattern-based mapping to automate this process. So rather than having to specify.

Re: Document NULL

On Wed, May 1, 2024, 16:13 David G. Johnston wrote: > Hi, > > Over in [1] it was rediscovered that our documentation assumes the reader > is familiar with NULL. It seems worthwhile to provide both an introduction > to the topic and an overview of how this special value gets handled > throughout

Re: Document NULL

On Sat, May 11, 2024, 16:34 David G. Johnston wrote: > On Fri, May 3, 2024 at 9:00 AM David G. Johnston < > david.g.johns...@gmail.com> wrote: > >> On Fri, May 3, 2024 at 8:44 AM Tom Lane wrote: >> >>> Having said that, I reiterate my proposal that we make it a new >>> >> under DDL, before 5.2