gt; RefreshXLogWriteResult(LogwrtResult);
> }
The code, which exists has existed for a long time, ensures that
GetInsertRecPtr() returns the accurate end of a record when it spanns
over page boundaries. This would need to be written in the new comment
if we use GetInsertRecPtr().
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
n preloading finishes?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
latest patch, the coherence
between the inHeap flag and the pairing heap is protected by LWLock,
so I believe we no longer need that test.
regards.
> Links.
> 1.
> https://www.postgresql.org/message-id/flat/CAPpHfdvGRssjqwX1%2Bidm5Tu-eWsTcx6DthB2LhGqA1tZ29jJaw%40mail.gmail.com#557900e860457a9e24256c93a2ad4920
--
Kyotaro Horiguchi
NTT Open Source Software Center
have its own strtok_r, but I haven't
checked how that fact affects the build.
> [0]:
> https://www.postgresql.org/message-id/856e5ec3-879f-42ee-8258-8bcc6ec9b...@eisentraut.org
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
revised the comment on the modified section to
make its intention clearer.
> > I'll consider this direction for a while.
> >
>
> Okay, thanks.
The attached patch is it. It's only for the master.
I decided not to create a new function because the simple code has
only one ca
At Tue, 11 Jun 2024 14:27:28 +0530, Amit Kapila wrote
in
> On Tue, Jun 11, 2024 at 12:34 PM Kyotaro Horiguchi
> wrote:
> >
> > At Tue, 11 Jun 2024 11:32:12 +0530, Amit Kapila
> > wrote in
> > > Sorry, it is not clear to me why we failed to flush the last
>
At Tue, 11 Jun 2024 09:27:20 +0900, Michael Paquier wrote
in
> On Thu, Jun 06, 2024 at 03:19:20PM +0900, Kyotaro Horiguchi wrote:
> > So, I believe the attached small patch fixes the behavior. I haven't
> > come up with a good test script for this issue.
t?
It seems that, it uses XLogBackgroundFlush(), which does not guarantee
flushing WAL until the end.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
on kinds, but introducing relfilenode stats to avoid this skew
doesn't seem to be the best way, as it invites inconclusive arguments
like the one raised above. The fact that we transfer counters from old
relfilenodes to new ones indicates that we are not really interested
in counts by relfilenode. If that's the case, wouldn't it be simpler
to call pgstat_count_relation_buffer_read() from bufmgr.c and then
branch according to relkind within that function? If you're concerned
about the additional branch, some ingenuity may be needed.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
their Japanese
translation '無期限' also sounds natural. However, I'm not sure we
want to go to that extent in transforming the table.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Thu, 06 Jun 2024 17:15:15 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Thu, 06 Jun 2024 16:45:00 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > I have been thinking about this since then. At first, I thought it
> > referred to FindFirstChangeNotification() and fr
At Thu, 06 Jun 2024 16:45:00 +0900 (JST), Kyotaro Horiguchi
wrote in
> I have been thinking about this since then. At first, I thought it
> referred to FindFirstChangeNotification() and friends, and inotify on
> Linux. However, I haven't found a way to simplify the specified code
>
I thought it
referred to FindFirstChangeNotification() and friends, and inotify on
Linux. However, I haven't found a way to simplify the specified code
area using those APIs.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
icant changes.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From 99cad7bd53a94b4b90937fb1eb2f37f2ebcadf6a Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: Thu, 6 Jun 2024 14:56:53 +0900
Subject: [PATCH] Fix infinite loop in walsender during publisher shutdown
When a publ
oided by setting stats_fetch_consistency to
> none.
It seems to me that this description already implies such an
incongruity in the functions' behavior from the "stable" behavior, but
we might want to explicitly mention that incongruity.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
() unless
compiler actually issues a false warning for it.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
behavior by exiting in the middle of the loop. It seems
we didn't want to bother collecting errors for every failed file in
that part.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
R cases. Even if this is not the case, the ownership
transition apperas quite callenging to follow.
It might be safer or clearer to pstrdup the token in jsonb_in_scalar()
and avoid NULLifying scalar_val after calling callbacks, or to let
jsonb_in_sclar() NULLify the pointer.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Rebased.
Along with rebasing, I changed the interface of XLogFsyncFile() to
return a boolean instead of an error message.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From bed74e638643d7491bbd86fe640c33db1e16f0e5 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: Mon,
ot; = "minimal" (but not use quotes for numeric values), as it
seems to be the most common practice. Anyway, we might want to unify
them.
Likewise, I saw two different versions of values with units.
> "max_stack_depth" must not exceed %ldkB.
> "vacuum_buffer_usage_li
ts.
+ errmsg("cannot change NO INHERIT status of NOT NULL constraint \"%s\" on
relation \"%s\"",
===
+ errmsg("cannot change NO INHERIT status of NOT NULL constraint \"%s\" in
relation \"%s\"",
I think we usually use on in this case.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
sm segment, shmem_exit
should have detached the region for the CV. CV cleanup code should be
invoked via before_shmem_exit.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Tue, 9 Apr 2024 15:00:27 +0900, Michael Paquier wrote
in
> I've checked the whole tree, and the two you are pointing at are the
> only incorrect paths. So applied, thanks!
Thank you for cross-checking and committing!
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Mon, 08 Apr 2024 16:27:02 +0900 (JST), Kyotaro Horiguchi
wrote in
> Hello.
>
> I noticed that NLS doesn't work for pg_combinebackup. The cause is
> that the tool forgets to call set_pglocale_pgservice().
>
> This issue is fixed by the following chage.
>
&
("pg_combinebackup"));
handle_help_version_opts(argc, argv, progname, help);
memset(, 0, sizeof(opt));
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Fri, 22 Mar 2024 11:44:08 +0900, Amit Langote
wrote in
> Thanks for the heads up.
>
> My bad, will push a fix shortly.
No problem. Thank you for the prompt correction.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
al, not split into multiple parts, for better
grep'ability.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Thank you for looking this.
At Tue, 19 Mar 2024 10:50:23 +0100, Peter Eisentraut
wrote in
> On 15.03.24 08:20, Kyotaro Horiguchi wrote:
> > diff --git a/src/backend/access/transam/twophase.c
> > b/src/backend/access/transam/twophase.c
> > @@ -1369,8 +1369,8 @@ ReadTwoPh
rmation
to the primary messages. The objective of the precedent for the use of
relname_only was somewhat different, but this use also seems legit.
In short, I think the distribution between message types (primary and
context) is fine as it is in the latest patch.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Fri, 15 Mar 2024 16:20:27 +0900 (JST), Kyotaro Horiguchi
wrote in
> I checked for that kind of msgids in a bit more intensive way. The
> numbers are the line numbers in ja.po of backend. I didn't check the
> same for other modules.
>
> > ###: invalid timeline %lld
&
At Fri, 15 Mar 2024 16:01:28 +1300, David Rowley wrote
in
> On Fri, 15 Mar 2024 at 15:27, Kyotaro Horiguchi
> wrote:
> > I have considered only the two messages. Actually, buffile.c and md.c
> > are already like that. The attached aligns the messages in
>
At Thu, 14 Mar 2024 11:23:38 +0530, Amit Kapila wrote
in
> On Thu, Mar 14, 2024 at 9:58 AM Kyotaro Horiguchi
> wrote:
> >
> > While examining reorderbuffer.c, I found several typos. I'm not sure
> > if fixing them is worthwhile, but I've attached a fix just in case.
only the two messages. Actually, buffile.c and md.c
are already like that. The attached aligns the messages in
pg_combinebackup.c and reconstruct.c with the precedents.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/bin/pg_combinebackup/pg_combinebackup.c b/src/bin/
Hello.
While examining reorderbuffer.c, I found several typos. I'm not sure
if fixing them is worthwhile, but I've attached a fix just in case.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/replication/logical/reorderbuffer.c b/src/backend/replication
t read file \"%s\": read only %d of
%d bytes",
+ pg_fatal("could not read file \"%s\": read only %d of
%u bytes",
rf->filename, rb, length);
I'd be happy if the two messages kept consistency. I suggest aligning
types instead
At Mon, 11 Mar 2024 16:43:32 +0900 (JST), Kyotaro Horiguchi
wrote in
> Oh, I once saw the fix work, but seems not to be working after some
> point. The new issue was a corruption of received WAL records on the
> first standby, and it may be related to the setting.
I identified
e, but I aplogize for the delay in the work..
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
nd with the change above, I saw that the behavior was
fixed. However, for reasons unclear to me, it shows another issue, and
I am running out of time and need more caffeine. I'll continue
investigating this tomorrow.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
rack of it.
> >
> > Thanks for doing that, because the cfbot pointed out a problem:
> > I should have written pg_strncasecmp not strncasecmp. If this
> > version tests cleanly, I'll push it.
>
> +1, LGTM.
Thank you for fixing this, Tom!
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Fri, 01 Mar 2024 12:37:55 +0900 (JST), Kyotaro Horiguchi
wrote in
> Anyway, our current policy here is to avoid record-rereads beyond
> source switches. However, fixing this seems to require that source
> switches cause record rereads unless some additional information is
> avail
At Fri, 01 Mar 2024 12:04:31 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 01 Mar 2024 10:29:12 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > After reading this, I came up with a possibility that walreceiver
> > recovers more quickly than th
At Fri, 01 Mar 2024 10:29:12 +0900 (JST), Kyotaro Horiguchi
wrote in
> After reading this, I came up with a possibility that walreceiver
> recovers more quickly than the calling interval to
> WaitForWALtoBecomeAvailable(). If walreceiver disconnects after a call
> to the functio
At Fri, 1 Mar 2024 08:17:04 +0900, Michael Paquier wrote
in
> On Thu, Feb 29, 2024 at 05:44:25PM +0100, Alexander Kukushkin wrote:
> > On Thu, 29 Feb 2024 at 08:18, Kyotaro Horiguchi
> > wrote:
> >> In the first place, it's important to note that we do not guarantee
&g
introduced
the XLP_FIRST_IS_OVERWRITE_CONTRECORD flag, which prevents overwriting
a WAL file that is already archived. However, in this case, the second
standby won't see the broken record because it cannot be in a
non-partial segment in the archive, and the new primary streams
END_OF_RECOVERY instea
e of them, commit_timestamp_buffers, transaction_buffers,
subtransaction_buffers use 0 to mean auto-tuning based on
shared-buffer size. I think it's worth adding an extra_desc such as "0
to automatically determine this value based on the shared buffer
size".
regards.
--
Kyotaro Horigu
ding more uses of CVs.
[1]
https://www.postgresql.org/message-id/20240227.150709.1766217736683815840.horikyota.ntt%40gmail.com
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
n both as logical publisher and physical
primary.
Regardless of this issue, I think we should provide separate waitlink
members for condition variables that can possibly be used
simultaneously.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
.
Thanks for the explanation. I'm fine with that.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Thu, 22 Feb 2024 09:36:43 +0900 (JST), Kyotaro Horiguchi
wrote in
> Yes, I'm happy with all of the changes. The proposed patch appears to
> cover all instances related to slotsync.c, and it looks fine to
> me. Thanks!
I'd like to raise another potential issue outside the patch.
s a separate issue.
./logical.c 122:errmsg("logical decoding requires wal_level >=
logical")));
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
s(). If it is true,
couldn't we make the SQL function require a database name to make a
connection, instead of requiring it in physical-replication conninfo?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/bin/pg_basebackup/streamutil.c
b/src/bin/pg_basebackup/stre
ad already sent the mail.. No harm done:p
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Mon, 19 Feb 2024 10:31:33 +0530, Robert Haas wrote
in
> On Mon, Feb 19, 2024 at 10:10 AM Kyotaro Horiguchi
> wrote:
> > A recent commit (7a424ece48) added the following message:
> >
> > > could not sync slot information as remote slot precedes local slot:
> &g
a separator between
"catalog xmin (%u)" and "local slot:", it is somewhat cluttered. Don't
we need something, for example a semicolon there to improve
readability and reduce clutter?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Mon, 19 Feb 2024 11:56:22 +0900 (JST), Kyotaro Horiguchi
wrote in
> Yeah, perhaps I was overly concerned. The removed comment made me
> think that someone could add code relying on the incorrect assumption
> that the remaining bytes beyond the returned count are cleared out. On
&
At Fri, 16 Feb 2024 19:50:00 +0530, Bharath Rupireddy
wrote in
> On Fri, Feb 16, 2024 at 7:10 AM Kyotaro Horiguchi
> wrote:
> > 1. It's useless to copy the whole page regardless of the 'count'. It's
> > enough to copy only up to the 'count'. The patch looks good in
ers -
> https://www.postgresql.org/message-id/CALj2ACV=C1GZT9XQRm4iN1NV1T=hla_hsgwnx2y5-g+mswd...@mail.gmail.com.
>
> If we have no reason, can the WALRead() callers just read how much
> they want like walsender for physical replication? Attached a patch
> for the change.
>
> T
minimal background
information. In this case, a translator needs to know which values
wal_level can take. It's relatively easy in this case, but I'm not
sure if this is always the case. Therefore, I would be slightly
happier if "logical" were double-quoted.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Wed, 14 Feb 2024 16:26:52 +0900 (JST), Kyotaro Horiguchi
wrote in
> > "wal_level" must be >= logical.
..
> > wal_level must be set to "replica" or "logical" at server start.
..
> I suggest making the quoting policy consistent.
Just aft
have the following message:
> wal_level must be set to "replica" or "logical" at server start.
This has the conflicting policy about quotation of variable names and
enum values.
I suggest making the quoting policy consistent.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
ady exists.
> STATEMENT: CREATE USER u;
This seems to be another instance of a similar thinko.
I vaguely think that we should just regard the absence as a concurrent
drop and either adjust or remove the message, then fix the
comment. The situation is slightly different for the duplication
cas
rst segment installation. That
being said, we could avoid it by initializing
last_known_installed_segno properly.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
nt, the action name in this example
has the suffix '-column'.
COPY (on_error 'replace-colomn', replacement 'null') ..
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Sorry for a minor correction, but..
At Thu, 01 Feb 2024 14:53:57 +0900 (JST), Kyotaro Horiguchi
wrote in
> Ah.. Understood. "NaN or Infinity" cannot be used in those
> cases. Additionally, for jpiBoolean and jpiBigint, we lack the text
> representation of the value.
At Thu, 1 Feb 2024 09:22:22 +0530, Jeevan Chalke
wrote in
> On Thu, Feb 1, 2024 at 7:24 AM Kyotaro Horiguchi
> wrote:
>
> > At Thu, 01 Feb 2024 10:49:57 +0900 (JST), Kyotaro Horiguchi <
> > horikyota@gmail.com> wrote in
> > > By the way, while
eric_int[248]().
jsonb_float[48]() converts it into float4 using numeric_float[48]().
Given these facts, it seems more efficient for jbvNumber to retain the
original scalar value, converting it only when necessary. If needed,
we could also add a numeric struct member as a cache for better
performance. I'm not sure we refer the values more than once, though.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Thu, 01 Feb 2024 10:49:57 +0900 (JST), Kyotaro Horiguchi
wrote in
> By the way, while playing with this feature, I noticed the following
> error message:
>
> > select jsonb_path_query('1.1' , '$.boolean()');
> > ERROR: numeric argument of jsonpath item method .bool
Thank you for the fix!
At Tue, 30 Jan 2024 13:46:17 +0530, Jeevan Chalke
wrote in
> On Mon, Jan 29, 2024 at 11:03 AM Tom Lane wrote:
>
> > Kyotaro Horiguchi writes:
> > > Having said that, I'm a bit concerned about the case where an overly
> > > long
4
=> build failure regarding LTO
Given these issues, it seems there might be some issues with including
fat objects in the -devel package.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
FI to ignore
ProcDiePending, is a matter I think is open to discussion.
Attached patches are the rebased version of v3 (0003 is updated) and
additional 0005 that makes use of die() instead of walreceiver's
custom function.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From daac3aa06
At Sun, 28 Jan 2024 22:47:02 -0500, Tom Lane
wrote in
Kyotaro Horiguchi writes:
> They seem to be suggesting that PostgreSQL has the types
"decimal" and
> "number". I know of the former, but I don't think PostgreSQL has
the
> latter type. Perhaps the &
quot;
> time_tz format is not recognized: "%s"
> timestamp format is not recognized: "%s"
> timestamp_tz format is not recognized: "%s"
I believe that the first line was intended to cover all the others:p
They are attached to this message separately.
regard
e're holding a spinlock. Instead, the
And I think we should keep the considerations it suggests. The patch
removes the comment itself, but it does so because it implements our
standard process exit procedure, which incorporates points suggested
by the now-removed comment.
--
Kyotaro Horig
ix:
- GUC_check_errdetail("timestamp out of range:
\"%s\"", str);
+ GUC_check_errdetail("Timestamp out of range:
\"%s\".", str);
But I'm not quite confident about whether capitalizing the type name
believed that it would be better to further
generalize in this direction rather than reverting. That's why I
proposed that patch.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
related
to this patch.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From 9a2b6fbda882587c127d3e50bccf89508837d1a5 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: Mon, 15 Jan 2024 15:57:53 +0900
Subject: [PATCH v32 1/3] Export wal_sync_method related functions
Export seve
d its validity or safety can certainly be contested. On
the other hand, if we seek perfection in this area of judgment, we may
need to have the WAL format itself more robust. In any case, since the
majority of the feedback on this patch seems to be negative, I am
going to withdraw
cessary.
>
> ==
> [1] https://commitfest.postgresql.org/46/2490/
> [2]
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/46/2490
Thanks for noticing of that. Will repost a new version.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Sun, 31 Dec 2023 20:07:41 +0900 (JST), Kyotaro Horiguchi
wrote in
> We've noticed that when walreceiver is waiting for a connection to
> complete, standby does not immediately respond to promotion
> requests. In PG14, upon receiving a promotion request, walreceiver
> terminat
rite processing code out of the loop was I wanted to
avoid adding more lines that are executed only once into the
loop. However, it is in exchange of additional complexity to remember
the original spelling of the parameter name. Personally, I believe
separating the search and rewrite processi
an 'action'. I somewhat suspect that this
parameter name intially conceived with the assupmtion that it would
take file names or similar parameters. I'm not sure if others will
agree, but I think the parameter name might not be the best
choice. For instance, considering the addition of the third v
, those familiar with these warnings tend to ignore them and
only pay attention to details when actual issues arise. Therefore, the
intention of this patch is to label them as "no issue" unless a
problem is blatantly evident, in order to prevent unnecessary concern.
> Does anyone agree or maybe I'm making things up?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
r simple modifications on this line, I will
withdraw this CF entry. At the moment, I also lack a fundamental,
comprehensive solution, but should if I or anyone else come up with
such a solution in the future, I believe it would worth a separate
discussion.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
ges to enable the use of
wal_sync_method outside of xlog.c as the first part of the patchset.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From 40749357f24adf89dc79db9b34f5c053288489bb Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: Mon, 15 Jan 2024 15:57:53 +0900
Subject:
At Wed, 10 Jan 2024 18:16:03 -0500, Tom Lane wrote in
> Kyotaro Horiguchi writes:
> > It seems somewhat intentional that only lc_messages references the
> > environment at boot time. On the other hand, previously, in the
> > absence of a specified locale, initdb would em
Thank you for the comments. This will help move the discussion
forward.
At Fri, 5 Jan 2024 15:17:11 -0500, Robert Haas wrote in
> On Thu, Mar 23, 2023 at 11:02 PM Kyotaro Horiguchi
> wrote:
> > [ new patch ]
>
> Well, I guess nobody is too excited about fixing this, b
* parent cmd.exe with the /D option specified, it is sometimes observed
+* that another cmd.exe is launched for unknown reasons. Therefore, it
is
+* crucial to verify the program file name to avoid returning the wrong
+ * PID.
*/
regards.
--
Kyotaro Horiguchi
At Fri, 5 Jan 2024 16:02:24 +0530, vignesh C wrote in
> On Wed, 22 Nov 2023 at 13:01, Kyotaro Horiguchi
> wrote:
> >
> > Anyway, this requires rebsaing, and done.
>
> Few tests are failing at [1], kindly post an updated patch:
Thanks!
The errors occurred in a p
will continue
to refine this patch. For now, I plan to register it for the upcoming
commitfest.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
it for the upcoming
commitfest.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c b/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
index 693b3669ba..e503799bd8 100644
--- a/src/backend/replication
l and a brief
>> grep'ing told me that it is almost always or consistently used in
>> uppercase in our tree.
> I pushed this also.
Thanks for pushing them!
regads.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Tue, 26 Dec 2023 19:04:53 +0900, Michael Paquier wrote
in
> On Mon, Dec 25, 2023 at 05:07:28PM +0900, Kyotaro Horiguchi wrote:
> > Yes. So, it turns out that they're found after they have been
> > committed.
>
> No problem. I've just applied what you had. I hope t
At Mon, 25 Dec 2023 15:42:41 +0900, Michael Paquier wrote
in
> On Mon, Dec 25, 2023 at 02:39:16PM +0900, Kyotaro Horiguchi wrote:
> > The attached patch contains both of the above fixes.
>
> Good catches, let's fix them. You have noticed that while translating
> these new
ently used in
uppercase in our tree.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/bin/pg_combinebackup/pg_combinebackup.c b/src/bin/pg_combinebackup/pg_combinebackup.c
index b6ae6f2aef..049c60cbf8 100644
--- a/src/bin/pg_combinebackup/pg_combinebackup.c
+++ b/s
elocate tablespace in OLDDIR to
> NEWDIR\n"));
The attached patch contains both of the above fixes.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/bin/pg_basebackup/pg_basebackup.c b/src/bin/pg_basebackup/pg_basebackup.c
index 5795b91261..28d2ee435b 100644
--
printf(_(" -i, --incremental=OLDMANIFEST\n"
> + " take incremental backup\n"));
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/bin/pg_basebackup/pg_basebackup.c b/src/bin/pg_basebackup/pg_basebackup
;The first
unsummarized LSN is this range is %X/%X.",
+errdetail("The first
unsummarized LSN in this range is %X/%X.",
LSN_FORMAT_ARGS(tli_missing_lsn;
}
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Thu, 7 Dec 2023 09:43:37 +1300, Thomas Munro wrote
in
> On Tue, Dec 5, 2023 at 3:43 PM Kyotaro Horiguchi
> wrote:
> > Windows' gai_strerror outputs messages that correspond to the language
> > environment. Similarly, I think that the messages that the messages
> >
le seems to have a
misalignment between the descriptions before and after the colon, but
do you think it's not something to be concerned about to this extent?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
s
(« ») or alternatively, lower quotetaion marks. Japanese commonly uses
corner brackets (「」), but can also adopt double or single quotation
marks in certain contexts. I took a look at the backend's fr.po file
for a trial, and it indeed seems that guillemets are being used.
regards.
--
Ky
1 - 100 of 3152 matches
Mail list logo