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
to correct these issues.
For Meson, on the other hand, I believe there is nothing in particular
that needs to be done.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/bin/pg_dump/nls.mk b/src/bin/pg_dump/nls.mk
index cd91737f48..ca7ce74275 100644
--- a/src/bin/pg_dump
At Thu, 30 Nov 2023 10:20:40 +0900 (JST), Kyotaro Horiguchi
wrote in
> Hello.
>
> Recently, a new --filter option was added to pg_dump. I might be
> wrong, but the syntax of the help message for this feels off. Is the
> word 'on' not necessary after 'based'?
>
>
/hoge.filter
pg_dump: error: invalid format in filter read from "/tmp/hoge.filter" on line
1: include filter for "index" is not allowed.
The attached patch includes modifications related to the calls to
pg_log_filter_error().
regards.
--
Kyotaro Horiguchi
NTT Open Source
based expressions in FILENAME
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Wed, 22 Nov 2023 11:04:01 -0500, Tom Lane wrote in
> Kyotaro Horiguchi writes:
> > Commit 3e51b278db leaves lc_* conf lines as commented-out when
> > their value is "C". This leads to the following behavior.
>
> Hmm ... I see a contributing factor here: this
Anyway, this requires rebsaing, and done.
Thanks for John (Naylor) for pointing this out.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From e56f1f24523e3e562a4db166dfeaadc79fd7b27a Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: Tue, 7 Mar 2023 14:55:58 +0900
Subj
around "C" by allowing explicit specification. (FWIW, I
prefer the last one.)
What do you think about these?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.c
index 0c6f5ceb0a..56a8c5b60e 100644
--- a/src
g it upfront doesn't seem unreasonable to me.
Oops. Sorry, and understood.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
rade
> mode.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/access/transam/xlog.c
b/src/backend/access/transam/xlog.c
index b541be8eec..319d4f5a81 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/x
this
comment is correct, wouldn't it mean that a lack of storage space for
the state at the location outputting the message indicates a bug in
the program, not a user configuration error? In other words, isn't
this message something that at least shouldn't be a user-facing
message, and might it be more appropriate to use an Assert instead?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
ats types.
The infrequent use of this feature, coupled with the fact that there
is no inherent need for these counters to be reset simultaneoulsy,
leads me to think that there is little point in cnetralizing the
locks.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
wrapper batch file (.bat) that records
%ERRORLEVEL% after running the target program. This may yield
insights, aothough its effectiveness is not guaranteed.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Wed, 1 Nov 2023 11:36:01 -0400, Bruce Momjian wrote in
> On Wed, Mar 31, 2021 at 01:43:47PM +0200, Christoph Berg wrote:
> > Re: Kyotaro Horiguchi
> > I like that because it points to the "point" syntax so users can
> > figure out how to spell a box.
>
&g
ror messages will
cause the subsequent code to fail with an error such as "unexpected
string: 'the output'". I'm not sure, but if this is permissive, the
returned error messages could potentially provide insight into the
underlying issue, paving the way for a potential solution.
regards.
--
Kyotaro H
so liked that style and considered using it, but I didn't
feel it was too hard to read in this particular case, so I ended up
using the current way. Just like with the point of other comments,
I'm not particularly attached to this style. Thus if someone find it
difficult to read, I have no issue with cha
during crash recovery.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
cking the file using a rudimentary script, I found no other
similar mistakes in the same file.
(FWIW, I also feel that these macros might be going a bit too far by
synthesizing even the function names.)
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/utils
le
> growth during pg_upgrade may be huge (transiently) unless the
> pg_resetwal step of pg_upgrade removes it at the end.
While I doubt anyone wishes to set the variable to a specific value
during upgrade, think there are individuals who might be reluctant to
edit the config file due to uncle
bout that:p
>
> Isn't calling pg_stat_reset_shared() for all stats types helping you
> out? Is there any problem with it? Can you be more specific about the
> use-case?
Oh. Sorry, it's my bad. pg_stat_reset_shared() is sufficient.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
t;,
> "wal"
>
> How about adding a new option 'all' to delete all targets above?
>
> I imagine there are cases where people want to initialize all of them
> at the same time in addition to initializing one at a time.
FWIW, I fairly often wanted it, but forgot about that:p
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
1 - 100 of 3132 matches
Mail list logo