Re: Add a different archive_command example for Linux / Unix
Hello Stephen, For the missing fsync directory, in case of a system crash which I had in mind using this command, I thought that fsck will fixed the discrepancy. I support your proposal i.e. archive_command = 'backup_tool %p /mnt/server/archivedir/%f' as at least people will investigate what choices they have for backup tools. Regards Gilles - Mail original - > De: "Stephen Frost" > À: "gparc" > Cc: "gparc" , "pgsql-docs" > Envoyé: Jeudi 8 Février 2024 22:54:29 > Objet: Re: Add a different archive_command example for Linux / Unix > Greetings, > > * gp...@free.fr (gp...@free.fr) wrote: >> Thanks Stephen for your detailed reply and broad perspective. >> But I see the cp example command used **as is** most of the time. > > In those cases- how would changing it to be a dd command be helpful? > The directory still wouldn't be fsync'd and there's a very good chance > that the rest of the documentation isn't followed or understood either, > leading almost certainly to broken backup setups. This wouldn't be the > only issue in any case, to be sure. > > This comes back to my earlier suggestion that perhaps we should just > change it to something like: > > archive_command = 'backup_tool %p /mnt/server/archivedir/%f' > > and not talk about specific tools that exist but don't perform in the > manner we actually expect from an archive command that we're using. We > already make it pretty clear to anyone who knows the tools mentioned > that the 'example' command won't work, if you read everything under that > section. > > Alternatively, we could actually document the tools we're aware of that > do work and which do strive, at least, to try and be good backup tools > and good archive commands for PG. That would certainly be a service to > our users and might result in far fewer misconfigured systems using the > examples because they thought (despite the explicit note in our > documentation) that they were recommendations. > > Thanks, > > Stephen
text and varchar are not equivalent
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/16/datatype-character.html
Description:
The documentation implies that the data types text and varchar are
equivalent, but this is not the case with this test in Postgresql version
16.
CREATE TEMPORARY TABLE test(ch char, vc varchar, txt text, txt0 text);
INSERT INTO test VALUES (' ', ' ', ' ','');
SELECT ch = vc AS ch_vc, ch = txt AS ch_txt, ch = txt0 AS ch_txt0,
vc = ch AS vc_ch, vc = txt AS vc_txt, vc = txt0 AS vc_txt0,
txt = ch AS txt_ch, txt = vc AS txt_vc, txt = txt0 AS txt_txt0,
txt0 = ch AS txt0_ch, txt0 = vc AS txt0_vc, txt0 = txt AS txt0_txt
FROM test;
ch_vc ch_txt ch_txt0 vc_ch vc_txt vc_txt0 txt_ch txt_vc txt_txt0
txt0_ch txt0_vc txt0_txt
TRUEFALSE TRUETRUETRUEFALSE FALSE TRUEFALSE TRUE
FALSE FALSE
The tests are showing that the space character is treated differently in a
one character string. Whilst varchar = text, the comparison with char is
treated differently with text and varchar
Re: text and varchar are not equivalent
On Fri, Feb 9, 2024, 10:12 PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/datatype-character.html > Description: > > The documentation implies that the data types text and varchar are > equivalent, but this is not the case with this test in Postgresql version > 16. > Fair point. But I'd rather further emphasize that char should just be avoided so this and other unexpected outcomes simply do not manifest in a real database scenario. Rather than try and document how odd it's behavior is when dealing with intra-textual type conversions. David J.
Re: text and varchar are not equivalent
"David G. Johnston" writes: > On Fri, Feb 9, 2024, 10:12 PG Doc comments form > wrote: >> The documentation implies that the data types text and varchar are >> equivalent, but this is not the case with this test in Postgresql version >> 16. > Fair point. But I'd rather further emphasize that char should just be > avoided so this and other unexpected outcomes simply do not manifest in a > real database scenario. Rather than try and document how odd it's behavior > is when dealing with intra-textual type conversions. Yeah, this is less about varchar acting oddly and more about char acting oddly. The short answer though is that text is a preferred type, varchar is not, and that makes a difference when resolving whether to apply text's or char's equality operator. You can detect how it's being handled with EXPLAIN: regression=# explain verbose SELECT vc = ch AS vc_ch FROM test; QUERY PLAN --- Seq Scan on pg_temp.test (cost=0.00..17.88 rows=630 width=1) Output: ((vc)::bpchar = ch) (2 rows) regression=# explain verbose SELECT txt = ch AS txt_ch FROM test; QUERY PLAN --- Seq Scan on pg_temp.test (cost=0.00..19.45 rows=630 width=1) Output: (txt = (ch)::text) (2 rows) regards, tom lane
