On Mon, Jul 26, 2021 at 9:43 PM Robert Haas wrote:
>
> StartupXLOG() has code beginning around line 7900 of xlog.c that
> decides, at the end of recovery, between four possible courses of
> action. It either writes an end-of-recovery record, or requests a
> checkpoint, or creates a checkpoint, or
At Wed, 28 Jul 2021 12:57:39 +0200, Ronan Dunklau
wrote in
> Le mercredi 28 juillet 2021, 08:22:30 CEST Kyotaro Horiguchi a écrit :
> > At Tue, 27 Jul 2021 07:50:39 +0200, Ronan Dunklau
> > wrote in
> > > I don't know if it should be the default, toggled by a command line flag,
> > > or if we
Hi Hackers,
I propose adding trackable information in postgres_fdw, in order to track
remote query correctly.
## Background and motivation
Currently postgres_fdw connects remote servers by using connect_pg_server().
However the function just calls PQconnectdbParams() with
On Thu, Jul 29, 2021 at 3:28 AM Andres Freund wrote:
>
> [1] I really wish somebody had the energy to just remove single user and
> bootstrap modes. The degree to which they increase complexity in the rest of
> the system is entirely unreasonable. There's not actually any reason
> bootstrapping
On Wed, Jul 28, 2021 at 6:52 PM Bruce Momjian wrote:
> I came up with the attached patch.
>
Thank you. It is an improvement but I think more could be done here (not
exactly sure what - though removing the "copy binaries for contrib modules
from the old server" seems like a decent second step.)
Hello,
On Fri, 18 Jun 2021 15:58:48 +0200 (CEST)
Fabien COELHO wrote:
> Attached Yugo-san patch with some updates discussed in the previous mails,
> so as to move things along.
I attached the patch rebased to a change due to 856de3b39cf.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git
Ranier Vilela writes:
> IMO, I think that "char *msg" is unnecessary, isn't it?
> + if (!PQExpBufferBroken(errorMessage))
> + res->errMsg = pqResultStrdup(res, errorMessage->data);
> else
> - res->errMsg = NULL;
> + res->errMsg = libpq_gettext("out of memory\n");
Please read the comment.
On Mon, Jul 26, 2021 at 11:05 AM Bossart, Nathan wrote:
> Here are my suggestions in patch form.
+printf(_(" -S, --sync-only safely write all database
files to disk and exit\n"));
Not your patch's fault, but the word "write" does not seem to convey
the true intent of the option,
On Thu, Jul 15, 2021 at 08:15:57AM -0700, David G. Johnston wrote:
> On Thursday, July 15, 2021, David G. Johnston
> My uncertainty revolves around core extensions since it seems odd to tell
> the user to overwrite them with versions from an older version of
> PostgreSQL.
>
> Ok.
On Thu, Jul 8, 2021 at 3:55 PM osumi.takami...@fujitsu.com
wrote:
>
> Hello, hackers
>
>
> When the current HEAD fails during logical decoding, the failure
> increments txns count in pg_stat_replication_slots - [1] and adds
> the transaction size to the sum of bytes in the same repeatedly
> on
Em qua., 28 de jul. de 2021 às 21:25, Tom Lane escreveu:
> I wrote:
> > Andres Freund writes:
> >> Hm. It seems we should be able to guarantee that the recovery path can
> print
> >> something, at least in the PGconn case. Is it perhaps worth pre-sizing
> >> PGConn->errorMessage so it'd fit an
On Wed, Jul 28, 2021 at 04:15:19PM +0200, Daniel Gustafsson wrote:
> Since get_namespace_name() returns a palloced string, this will lead to a 2x
> leak of the namespace length as opposed to the 1x of today. While hardly a
> big
> deal, it seems prudent to cap this by storing the returned string
On Wed, Jul 28, 2021 at 08:28:12PM +, Bossart, Nathan wrote:
> On 7/28/21, 11:32 AM, "Tom Lane" wrote:
>> I follow the idea of using WaitLatch to ensure that the delays are
>> interruptible by postmaster signals, but even that isn't worth a
>> lot given the expected use of these things. I
I wrote:
> Andres Freund writes:
>> Hm. It seems we should be able to guarantee that the recovery path can print
>> something, at least in the PGconn case. Is it perhaps worth pre-sizing
>> PGConn->errorMessage so it'd fit an error like this?
>> But perhaps that's more effort than it's worth.
>
On Wed, Jul 28, 2021 at 01:16:19PM -0400, Tom Lane wrote:
> I do not see any RESTART option in SQL:2021 11.72 definition>. Since we don't document it either, there's really no
> expectation that anyone would use it.
Okay, good point. I was not aware of that.
> I don't particularly think that
On Wed, Jul 28, 2021 at 11:32 AM Michael Paquier wrote:
>
> On Wed, Jul 28, 2021 at 09:39:02AM +1000, Peter Smith wrote:
> > IMO the PG code comments are not an appropriate place for leetspeak
> > creativity.
> >
> > PSA a patch to replace a few examples that I recently noticed.
> >
> >
Andres Freund writes:
> Hm. It seems we should be able to guarantee that the recovery path can print
> something, at least in the PGconn case. Is it perhaps worth pre-sizing
> PGConn->errorMessage so it'd fit an error like this?
Forgot to address this. Right now, the normal situation is that
> On 28 Jul 2021, at 23:02, Tom Lane wrote:
> Jacob Champion writes:
>> As long as the .SECONDARYEXPANSION magic is clear enough to others, I'm
>> happy.
>
> After reading the gmake docs about that, I'd have to say it's likely to be
> next
> door to unmaintainable.
Personally, I don’t think
Jacob Champion writes:
> On Wed, 2021-07-28 at 00:24 +0200, Daniel Gustafsson wrote:
>> GNU Make is already a requirement, I don't see this shifting the needle in
>> any
>> direction.
Um ... the existing requirement is for gmake 3.80 or newer;
if you want to use newer features we'd have to have
Andres Freund writes:
> I should probably know this, but I don't. Nor did I quickly find an answer. I
> assume gettext() reliably and reasonably deals with OOM?
I've always assumed that their fallback in cases of OOM, can't read
the message file, yadda yadda is to return the original string.
I
On 7/28/21 4:10 PM, Jacob Champion wrote:
>
>>> - I am making _heavy_ use of GNU Make-isms, which does not improve
>>> long-term maintainability.
>> GNU Make is already a requirement, I don't see this shifting the needle in
>> any
>> direction.
> As long as the .SECONDARYEXPANSION magic is
On 7/28/21, 11:32 AM, "Tom Lane" wrote:
> I'm detecting a certain amount of lily-gilding here. Neither of these
> delays are meant for anything except debugging purposes, and nobody as
> far as I've heard has ever expressed great concern about identifying
> which process they need to attach to
On Wed, 2021-07-28 at 00:24 +0200, Daniel Gustafsson wrote:
> > On 4 Mar 2021, at 01:03, Jacob Champion wrote:
> > Andrew pointed out elsewhere [1] that it's pretty difficult to add new
> > certificates to the test/ssl suite without blowing away the current
> > state and starting over. I needed
On Wed, 2021-07-28 at 14:02 +0900, Michael Paquier wrote:
> Arg, sorry about that! I was unclear what the situation of the patch
> was.
No problem, race condition ;-)
> Right. Isn't that an older issue though? A rewrite involved after a
> change of relpersistence does not call the hook
Hi,
On 2021-07-27 18:40:48 -0400, Tom Lane wrote:
> The first half of that just saves a few hundred bytes of repetitive
> coding. However, I think that the addition of recovery logic is
> important for robustness, because as things stand libpq may be
> worse off than before for OOM handling.
Hi,
On 2021-07-26 12:12:53 -0400, Robert Haas wrote:
> My first thought was that we should do the check unconditionally,
> rather than just when bgwriterLaunched && LocalPromoteIsTriggered, and
> ERROR if it fails. But then I wondered what the point of that would be
> exactly. If we have such a
Hi,
On 2021-07-27 13:06:56 +0900, Masahiko Sawada wrote:
> Apart from performance and memory usage points of view, we also need
> to consider the reusability of the code. When I started this thread, I
> thought the best data structure would be the one optimized for
> vacuum's dead tuple storage.
Hi,
On 2021-07-25 19:07:18 +0300, Yura Sokolov wrote:
> I've dreamed to write more compact structure for vacuum for three
> years, but life didn't give me a time to.
>
> Let me join to friendly competition.
>
> I've bet on HATM approach: popcount-ing bitmaps for non-empty elements.
My concern
Justin Pryzby writes:
> On Wed, Jul 28, 2021 at 09:10:35PM +0530, Bharath Rupireddy wrote:
>> Hm. That's a good idea to show up in the ps display.
> Keep in mind that ps is apparently so expensive under windows that the GUC
> defaults to off.
> The admin can leave the ps display off, but I
On Wed, Jul 28, 2021 at 09:10:35PM +0530, Bharath Rupireddy wrote:
> On Wed, Jul 28, 2021 at 8:12 AM Kyotaro Horiguchi
> wrote:
> >
> > - It seems that the additional wait-event is effectively useless for
> > most of the processes. Considering that this feature is for debugging
> > purpose,
I wrote:
> On Mon, Jul 26, 2021 at 7:55 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> >
> > >+ utf8_advance(s, state, len);
> > >+
> > >+ /*
> > >+ * If we saw an error during the loop, let the caller handle it. We
treat
> > >+ * all other states as success.
> > >+ */
> > >+ if
Hi,
On 2021-07-28 13:37:48 -0400, Melanie Plageman wrote:
> Attached is a patch on top of the AIO branch which does bitmapheapscan
> prefetching using the PgStreamingRead helper already used by sequential
> scan and vacuum on the AIO branch.
>
> The prefetch iterator is removed and the main
Robert Haas writes:
> On Wed, Jul 28, 2021 at 1:05 PM Tom Lane wrote:
>> That would clearly be a bug fix. I'm just troubled that there are
>> still behaviors that people will see as bugs.
> That's a reasonable thing to be troubled about, but the date and time
> related datatypes have so many
On Tue, Feb 23, 2021 at 5:04 AM Andres Freund wrote:
>
> ## AIO API overview
>
> The main steps to use AIO (without higher level helpers) are:
>
> 1) acquire an "unused" AIO: pgaio_io_get()
>
> 2) start some IO, this is done by functions like
>
On Wed, Jul 28, 2021 at 1:05 PM Tom Lane wrote:
> Fair point, but you decided when you chose to use float that you don't
> care about the differences between numbers that only differ at the
> seventeenth or so decimal place. (Maybe, if you don't understand what
> float is, you didn't make that
On 2021/07/28 16:15, Yugo NAGATA wrote:
I found another disconnect_all().
/* XXX should this be connection time? */
disconnect_all(state, nclients);
The measurement is also not necessary here.
So the above comment should be removed or updated?
I think this disconnect_all
Fujii Masao writes:
> On 2021/07/28 23:53, Bharath Rupireddy wrote:
>> -1. IMHO, this is something creating more confusion to the user. We
>> say that we allow both START and RESTART that RESTART is accepted as a
>> consequence of our internal option handling in gram.y. Instead, I
>> recommend
Robert Haas writes:
> On Wed, Jul 28, 2021 at 11:52 AM Tom Lane wrote:
>> You know, I was thinking exactly that thing earlier. Changing the
>> on-disk representation is certainly a nonstarter, but the problem
>> here stems from expecting interval_in to do something sane with inputs
>> that do
On 2021/07/28 23:53, Bharath Rupireddy wrote:
On Wed, Jul 28, 2021 at 11:50 AM Michael Paquier wrote:
On Mon, Jul 26, 2021 at 04:57:53PM +0900, Michael Paquier wrote:
FWIW, like Ashutosh upthread, my vote would be to do nothing here in
terms of behavior changes as this is just breaking a
Andrew Dunstan writes:
> Is it worth making the first one a macro?
It'd be the same from a source-code perspective, but probably a
shade bulkier in terms of object code.
regards, tom lane
On 2021/07/28 12:44, Fujii Masao wrote:
On 2021/07/28 6:25, Heikki Linnakangas wrote:
On 27/07/2021 19:49, Fujii Masao wrote:
Anyway I attached the patch that changes only xact_redo_abort()
so that it calls XLogFlush() to update min recovery point.
Looks good to me, thanks! FWIW, I used
On Wed, Jul 28, 2021 at 11:52 AM Tom Lane wrote:
> You know, I was thinking exactly that thing earlier. Changing the
> on-disk representation is certainly a nonstarter, but the problem
> here stems from expecting interval_in to do something sane with inputs
> that do not correspond to any
On 7/28/21 11:02 AM, Tom Lane wrote:
>
> Here I've got to disagree. We do need the form with a PQExpBuffer
> argument, because there are some places where that isn't a pointer
> to a PGconn's errorMessage. But the large majority of the calls
> are "pqReportOOM(conn)", and I think having to
On Wed, Jul 28, 2021 at 12:15 AM Michael Paquier
wrote:
>
> On Tue, Jul 27, 2021 at 12:05:51PM -0400, John Naylor wrote:
> > Concretely, I propose to push the attached on master and v14. Since
we're
> > in beta 2 and this thread might not get much attention, I've CC'd the
RMT.
>
> (It looks like
Robert Haas writes:
> If we were doing this over again, I would argue that, with this
> on-disk representation, 0.7 months ought to be rejected as invalid
> input, because it's generally not a good idea to have a data type that
> silently converts a value into a different value that is not
>
On Wed, Jul 28, 2021 at 8:12 AM Kyotaro Horiguchi
wrote:
>
> Hello.
>
> At Tue, 27 Jul 2021 11:04:09 +0530, Bharath Rupireddy
> wrote in
> > On Mon, Jul 26, 2021 at 11:03 PM Bossart, Nathan
> > wrote:
> > PSA v3 patch.
>
> I have some comments.
>
> - No harm, but it's pointless to feed
On Wed, Jul 28, 2021 at 11:25 AM Bharath Rupireddy
wrote:
> > Perhaps during initdb we don't want messages, but I'm not sure that we
> > need to do anything about that here. None of the messages that the
> > server normally produces show up when you run initdb, so I guess they
> > are getting
On Tue, Jul 27, 2021 at 4:02 PM Tom Lane wrote:
> What I think we have consensus on is that interval_in is doing the
> wrong thing in a particular corner case. I have heard nobody but
> you suggesting that we should start undertaking behavioral changes
> in other interval functions, and I don't
On 2021-Jul-27, Drouvot, Bertrand wrote:
> diff --git a/src/backend/utils/cache/lsyscache.c
> b/src/backend/utils/cache/lsyscache.c
> +bool
> +get_rel_logical_catalog(Oid relid)
> +{
> + boolres;
> + Relation rel;
> +
> + /* assume previously locked */
> + rel =
On Wed, Jul 28, 2021 at 7:02 PM Robert Haas wrote:
>
> On Wed, Jul 28, 2021 at 5:24 AM Nitin Jadhav
> wrote:
> > I also agree that this is the better place to do it. Hence modified
> > the patch accordingly. The condition "!AmStartupProcess()" is added to
> > differentiate whether the call is
On Wed, Jul 28, 2021 at 08:42:31AM +0100, Dean Rasheed wrote:
> On Wed, 28 Jul 2021 at 00:08, John W Higgins wrote:
> >
> > It's nice to envision all forms of fancy calculations. But the fact is that
> >
> > '1.5 month'::interval * 2 != '3 month"::interval
> >
>
> That's not exactly true. Even
Hi Wenjing
would you please rebase the code?
Thank you very much
Tony
The new status of this patch is: Waiting on Author
Michael Paquier writes:
> On Tue, Jul 27, 2021 at 10:31:25PM -0400, Tom Lane wrote:
>> Yeah, there are half a dozen places that currently print something
>> more specific than "out of memory". I judged that the value of this
>> was not worth the complexity it'd add to support it in this scheme.
On Wed, Jul 28, 2021 at 11:50 AM Michael Paquier wrote:
>
> On Mon, Jul 26, 2021 at 04:57:53PM +0900, Michael Paquier wrote:
> > FWIW, like Ashutosh upthread, my vote would be to do nothing here in
> > terms of behavior changes as this is just breaking a behavior for the
> > sake of breaking it,
Le 26/07/2021 à 18:03, Alexander Pyhalov a écrit :
Tom Lane писал 2021-07-26 18:18:
Alexander Pyhalov writes:
[ 0001-Allow-pushing-CASE-expression-to-foreign-server-v6.patch ]
This doesn't compile cleanly:
deparse.c: In function 'foreign_expr_walker.isra.4':
deparse.c:920:8: warning:
On Tue, Jul 27, 2021 at 11:18 PM Michael Paquier wrote:
> I have been looking at that. Here are some findings:
> - In pg_archivecleanup, CleanupPriorWALFiles() does not bother
> exit()'ing with an error code. Shouldn't we worry about reporting
> that correctly? It seems strange to not inform
On Wed, Jul 28, 2021 at 12:42 AM Dean Rasheed
wrote:
> On Wed, 28 Jul 2021 at 00:08, John W Higgins wrote:
> >
> > It's nice to envision all forms of fancy calculations. But the fact is
> that
> >
> > '1.5 month'::interval * 2 != '3 month"::interval
> >
>
> That's not exactly true. Even without
I took a look at this I agree with the reviewer that it's a good change. The
output from multiple jobs in vacuumdb is clearly easier to parse with this
since the initial LOG and later DETAIL can be interleaved with other relations
of the same name in other namespaces.
+
On Wed, Jul 28, 2021 at 5:24 AM Nitin Jadhav
wrote:
> I also agree that this is the better place to do it. Hence modified
> the patch accordingly. The condition "!AmStartupProcess()" is added to
> differentiate whether the call is done from a startup process or some
> other process. Actually
While looking into issues with fairywren and pg_basebackup tests, I
created a similar environment but with more modern Windows / msys2.
Before it even got to the test that failed on fairywren it failed the
first TAP test for a variety of reasons, all connected to
TestLib::perl2host.
First, this
On Wed, Jul 28, 2021 at 6:48 AM Dipesh Pandit wrote:
> As of now shared memory is not attached to the archiver. Archiver cannot
> access ThisTimeLineID or a flag available in shared memory.
If that is true, why are there functions PgArchShmemSize() and
PgArchShmemInit(), and how does this
On Tue, Jul 27, 2021 at 4:50 PM Tom Lane wrote:
> TBH I do not agree that this is a great idea. I think it's inevitably
> exposing a lot of unstable internal planner details.
Well, that is a risk, but I think I like the alternative even less.
Imagine if we had a CREATE INDEX command but no way
On Tuesday, July 27, 2021 3:59 PM Ajin Cherian wrote:
> On Thu, Jul 8, 2021 at 4:55 PM osumi.takami...@fujitsu.com
> wrote:
>
> > Attached file is the POC patch for this.
> > Current design is to save failed stats data in the ReplicationSlot struct.
> > This is because after the error, I'm not
On Wed, 28 Jul 2021 at 03:52, Dagfinn Ilmari Mannsåker
wrote:
>
> Alvaro Herrera writes:
> > I think using the return value of grep as a boolean is confusing. It
> > seems more legible to compare to 0. So instead of this:
> >
> > + if (! grep { $_ eq $ref} @{ $self->{references} })
On 2021-07-28 03:45, Pavel Stehule wrote:
út 27. 7. 2021 v 20:34 odesílatel Fujii Masao
napsal:
On 2021/07/09 14:05, torikoshia wrote:
On 2021-07-02 23:21, Bharath Rupireddy wrote:
On Tue, Jun 22, 2021 at 8:00 AM torikoshia
wrote:
Updated the patch.
Thanks for the patch. Here are some
On Wed, Jul 28, 2021 at 4:37 PM Amul Sul wrote:
>
> On Wed, Jul 28, 2021 at 2:26 AM Robert Haas wrote:
> >
> > On Fri, Jul 23, 2021 at 4:03 PM Robert Haas wrote:
> > > My 0003 is where I see some lingering problems. It creates
> > > XLogAcceptWrites(), moves the appropriate stuff there, and
> On 28 Jul 2021, at 13:10, Andrew Dunstan wrote:
>
> On 7/27/21 12:06 PM, Dagfinn Ilmari Mannsåker wrote:
>> Hi hackers,
>>
>> In the patches for improving the MSVC build process, I noticed a use of
>> `map` in void context. This is considered bad form, and has a
>> perlcritic policy
On 7/27/21 6:40 PM, Tom Lane wrote:
> While cleaning out dead branches in my git repo, I came across an
> early draft of what eventually became commit ffa2e4670 ("In libpq,
> always append new error messages to conn->errorMessage"). I realized
> that it contained a good idea that had gotten
On 7/27/21 12:06 PM, Dagfinn Ilmari Mannsåker wrote:
> Hi hackers,
>
> In the patches for improving the MSVC build process, I noticed a use of
> `map` in void context. This is considered bad form, and has a
> perlcritic policy forbidding it:
>
On Wed, Jul 28, 2021 at 2:26 AM Robert Haas wrote:
>
> On Fri, Jul 23, 2021 at 4:03 PM Robert Haas wrote:
> > My 0003 is where I see some lingering problems. It creates
> > XLogAcceptWrites(), moves the appropriate stuff there, and doesn't
> > need the xlogreader. But it doesn't really solve the
Le mercredi 28 juillet 2021, 08:22:30 CEST Kyotaro Horiguchi a écrit :
> At Tue, 27 Jul 2021 07:50:39 +0200, Ronan Dunklau
> wrote in
> > Hello,
> >
> > I've notived that pg_receivewal logic for deciding which LSN to start
> >
> > streaming at consists of:
> > - looking up the latest WAL file
On Tue, Jul 27, 2021 at 5:11 AM Greg Nancarrow wrote:
>
> On Mon, Jul 26, 2021 at 3:21 PM vignesh C wrote:
> >
> > Thanks for the comment, this is modified in the v15 patch attached.
> >
>
> I have several minor review comments.
>
> (1) src/backend/catalog/objectaddress.c
> Should start comment
Hi,
> I don't think it's great that we're using up SIGINT for this purpose.
> There aren't that many signals available at the O/S level that we can
> use for our purposes, and we generally try to multiplex them at the
> application layer, e.g. by setting a latch or a flag in shared memory,
>
On 7/28/21 3:15 AM, Amit Langote wrote:
> On Wed, Jul 28, 2021 at 1:07 AM Tomas Vondra
> wrote:
>> On 7/27/21 4:28 AM, Amit Langote wrote:
>>> I think it can be incorrect to use the same TupleDesc for both the
>>> slots in ri_Slots (for ready-to-be-inserted tuples) and ri_PlanSlots
>>> (for
> > > I saw that you fixed it by calling InitStartupProgress() after the
> > > walkdir()
> > > calls which do pre_sync_fname. So then walkdir is calling
> > > LogStartupProgress(STARTUP_PROCESS_OP_FSYNC) even when it's not doing
> > > fsync,
> > > and then LogStartupProgress() is returning
At Tue, 27 Jul 2021 11:03:14 -0400, Robert Haas wrote
in
> On Tue, Jul 27, 2021 at 9:18 AM Kyotaro Horiguchi
> wrote:
> > FWIW, by the way, I complained that the variable name "promoted" is a
> > bit confusing. It's old name was fast_promoted, which means that fast
> > promotion is being
pá 23. 7. 2021 v 10:47 odesílatel Pavel Stehule
napsal:
>
>
> pá 23. 7. 2021 v 10:30 odesílatel Aleksander Alekseev <
> aleksan...@timescale.com> napsal:
>
>> Hi Pavel,
>>
>> > I know it. Attached patch try to fix this issue
>> >
>> > I merged you patch (thank you)
>>
>> Thanks! I did some more
On Wed, 28 Jul 2021 at 00:08, John W Higgins wrote:
>
> It's nice to envision all forms of fancy calculations. But the fact is that
>
> '1.5 month'::interval * 2 != '3 month"::interval
>
That's not exactly true. Even without the patch:
SELECT '1.5 month'::interval * 2 AS product,
'3
Hi all,
In commit 3f90ec85 we are trying to postpone gathering partial paths for
topmost scan/join rel until we know the final targetlist, in order to
allow more accurate costing of parallel paths. We do this by the
following code snippet in standard_join_search:
+ /*
+* Except for the
Hi
út 13. 7. 2021 v 1:16 odesílatel Tom Lane napsal:
> Alvaro Herrera writes:
> > [1] your proposal of "[+-] OBJTYPE OBJIDENT" plus empty lines allowed
> > plus lines starting with # are comments, seems plenty. Any line not
> > following that format would cause an error to be thrown.
Hello Fujii-san,
On Wed, 28 Jul 2021 00:20:21 +0900
Fujii Masao wrote:
>
>
> On 2021/07/27 11:02, Yugo NAGATA wrote:
> > Hello Fujii-san,
> >
> > Thank you for looking at it.
> >
> > On Tue, 27 Jul 2021 03:04:35 +0900
> > Fujii Masao wrote:
> + * Per-thread
[...] Thoughts?
For pgbench it is definitely ok to add the exit. For others the added
exits look reasonable, but I do not know them intimately enough to be sure
that it is the right thing to do in all cases.
All that does not seem to enter into the category of things worth
On Wed, Jul 28, 2021 at 12:37:47AM +0200, Daniel Gustafsson wrote:
> The original import of the SSL tests saved the clientside log in /client-log,
> which was later removed in 1caef31d9. The test/ssl .gitignore didn't get the
> memo though.
Good catch. Thanks.
--
Michael
signature.asc
At Tue, 27 Jul 2021 07:50:39 +0200, Ronan Dunklau
wrote in
> Hello,
>
> I've notived that pg_receivewal logic for deciding which LSN to start
> streaming at consists of:
> - looking up the latest WAL file in our destination folder, and resume from
> here
> - if there isn't, use the
On Mon, Jul 26, 2021 at 04:57:53PM +0900, Michael Paquier wrote:
> FWIW, like Ashutosh upthread, my vote would be to do nothing here in
> terms of behavior changes as this is just breaking a behavior for the
> sake of breaking it, so there are chances that this is going to piss
> some users that
85 matches
Mail list logo
