Re: PITR on DROP DATABASE, deleting of the database directory despite the recovery_target_time set before.

viour. And give some examples on this. Maybe we could add some documentation in the xlog explanation and a warning in the recovery_target_time and xid in guc doc ? If there are better places in the docs let us know. Thanks -- Jean-Christophe Arnu

wal_dump output on CREATE DATABASE

I didn't do the things the right way, I would appreciate some help from a kind mentor. I'll put the patch for the next commitfest. Thank you, -- Jean-Christophe Arnu diff --git a/src/backend/access/rmgrdesc/dbasedesc.c b/src/backend/access/rmgrdesc/dbasedesc.c index 39e26d7ed4..7ee120f1d9

Re: wal_dump output on CREATE DATABASE

Le ven. 2 nov. 2018 à 08:37, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> a écrit : > On 26/10/2018 15:53, Jean-Christophe Arnu wrote: > > Exemple on CREATE DATABASE (without defining a template database) : > > rmgr: Databaselen (rec/tot): 42/42, tx:

Re: wal_dump output on CREATE DATABASE

Le dim. 4 nov. 2018 à 18:01, Jean-Christophe Arnu a écrit : > Le ven. 2 nov. 2018 à 08:37, Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> a écrit : > >> On 26/10/2018 15:53, Jean-Christophe Arnu wrote: >> > Exemple on CREATE DATABASE (without defining a

Re: wal_dump output on CREATE DATABASE

Le lun. 5 nov. 2018 à 15:37, Jean-Christophe Arnu a écrit : > > > Le dim. 4 nov. 2018 à 18:01, Jean-Christophe Arnu a > écrit : > >> Le ven. 2 nov. 2018 à 08:37, Peter Eisentraut < >> peter.eisentr...@2ndquadrant.com> a écrit : >> >>>

Re: wal_dump output on CREATE DATABASE

don't know whether it's relevant to perform these changes or not. If the A/B/C notation is to be generalized, it would be worth document it in the SGML file. If not, the first patch provided should be enough. Regards -- Jean-Christophe Arnu

Re: wal_dump output on CREATE DATABASE

lines with base/db/rel ... So there's some different format. Anyway, I handle all of them (I hope so) in my processing script. So keeping the things just as they are (out of the initial COPY patch that should be applied *to me*) is no problem for me. On the other hand, there's a consensus not to go further than the initial patch. -- Jean-Christophe Arnu

Re: wal_dump output on CREATE DATABASE

Le mar. 20 nov. 2018 à 13:34, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> a écrit : > On 16/11/2018 17:28, Jean-Christophe Arnu wrote: > > On the other hand, there's a consensus not to go further than the > > initial patch. > > I have committed your orig

FDW pushdown of non-collated functions

ation is not derived from a foreign * Var, it can't be sent to remote. */if (fe->inputcollid == InvalidOid || fe->funccollid == InvalidOid) /* OK, inputs are all noncollatable */ ;else if (inner_cxt.state != FDW_COLLATE_SAFE || fe->inputcollid != inner_cxt.co

Re: FDW pushdown of non-collated functions

Dear Hackers, I figured out this email was sent at release time. The worst time to ask for thoughts on a subject IMHO. Anyway, I hope this email will pop the topic over the stack! Thank you! Le ven. 8 sept. 2023 à 16:41, Jean-Christophe Arnu a écrit : > Dear hackers, > > I recentl

Re: FDW pushdown of non-collated functions

Hi Ashutosh, Le ven. 6 oct. 2023 à 14:16, Ashutosh Bapat a écrit : > Hi Jean-Christophe, > > On Fri, Sep 8, 2023 at 11:30 PM Jean-Christophe Arnu > wrote: > > > > Maybe we could add another condition to the first if statement in order > to allow a “no-collation” func

Empty string in lexeme for tsvector

hecks for empty strings on the pointed out functions. It comes with modified regression tests. Patch applies along head/master and 14_RC1. Comments are more than welcome! Thank you, -- Jean-Christophe Arnu diff --git a/src/backend/utils/adt/tsvector_op.c b/src/backend/utils/adt/tsvector_op.c index

Re: Empty string in lexeme for tsvector

he right thing to do (prevent further processing on lexemes as soon as possible) but I might omit something. Regards Jean-Christophe Arnu diff --git a/src/backend/utils/adt/tsvector_op.c b/src/backend/utils/adt/tsvector_op.c index 9236ebcc8f..00f80ffcbc 100644 --- a/src/backend/utils/adt/tsvector_op.c +

Re: Empty string in lexeme for tsvector

; '2'" > LINE 1: SELECT $$'' '1' '2'$$::tsvector; > > Thank you, Artur for spotting this test. It is now included into this patch. -- Jean-Christophe Arnu diff --git a/src/backend/utils/adt/tsvector_op.c b/src/backend/utils/adt/tsvector_

Re: Empty string in lexeme for tsvector

Le dim. 26 sept. 2021 à 22:41, Jean-Christophe Arnu a écrit : > > > Le dim. 26 sept. 2021 à 15:55, Artur Zakirov a écrit : > >> Nice catch! The patch looks good to me. >> Can you also add a more general test case: >> >> =# SELECT $$'' '1&#x

Re: Empty string in lexeme for tsvector

Thank you Tom for your review. Le mer. 29 sept. 2021 à 21:36, Tom Lane a écrit : > Jean-Christophe Arnu writes: > > [ empty_string_in_tsvector_v4.patch ] > > I looked through this patch a bit. I don't agree with adding > these new error conditions to tsvector_

Re: FileFallocate misbehaving on XFS

ndles that) but I will let you know of any developments. > > Cheers > Mike > > > -- Jean-Christophe Arnu

Re: restore_command return code behaviour

On fri. 25 jul. 2025, 00:01, Jacob Champion < jacob.champ...@enterprisedb.com> wrote : > > > If you agree, we can suggest a patch for the documentation. > > If you've tripped over it, I think we should consider a docs patch. > We've spent time on it, guessing it was a return code-driven behaviou

Re: restore_command return code behaviour

utdown) or an > error by > the shell **with an exit status greater than 125** (such as command not > found), then recovery will abort and the server will not start up. > » > > What do you think? > You're also right. That's more consistent and easier to read. Thank

Re: restore_command return code behaviour

Le lun. 28 juil. 2025 à 10:01, Jean-Christophe Arnu a écrit : > Here's a first version of this tiny doc patch. > > Hope this is clear enough. > Sorry, the previous version had a bad wording for one file. Please do not review it. The following version is the correct one. --

Re: restore_command return code behaviour

On friday, 25 jul. 2025 à 09:35, Jean-Christophe Arnu wrote : > On fri. 25 jul. 2025, 00:01, Jacob Champion < > jacob.champ...@enterprisedb.com> wrote : > > Here are the places where I think the details should be added : > - GUC documentation [1] > - Backup and R

restore_command return code behaviour

ND -- Jean-Christophe Arnu

Re: restore_command return code behaviour

th a simple scp returning 255 in some cases. Just adding rhe "over 126 return code leads to server stop" (or so) to the current doc version seems enough to me. Jean-Christophe Arnu

Re: restore_command return code behaviour

Le lun. 4 août 2025, 04:45, David G. Johnston a écrit : > > How about: > > Recovery will abort and the server will not start up upon any of the > following: > the shell is unable to execute the command (due to it not being found or > executable), > the command returns an exit status greater than

Re: restore_command return code behaviour

ch condition for shutting down the server (but it breaks the GUC style, where bullet points are only used for defining possible values). -- Jean-Christophe Arnu

Re: restore_command return code behaviour

and the server will not start up if any of the following events occur: the command is terminated by an unhandled signal or the command returns an exit status greater than 125 (including "command not found"). -- Jean-Christophe Arnu