> Hi,
>
> Attached is a small patch to fix a comment on PQcancelErrorMessage.
>
> It was accidentally "Get the socket of the cancel connection."
> I rewrote it to "Returns the error message most recently generated
> by an operation on the cancel connection."
Good catch. The proposed message
Hello Noah,
28.06.2024 08:13, Noah Misch wrote:
Pushed. ...
Please look also at another anomaly, I've discovered.
An Assert added with d5f788b41 may be falsified with:
CREATE TABLE t(a int PRIMARY KEY);
INSERT INTO t VALUES (1);
CREATE VIEW v AS SELECT * FROM t;
MERGE INTO v USING (VALUES
"David G. Johnston" writes:
> On Wed, Jul 3, 2024 at 8:46 PM Steve Lau wrote:
>> While reading the source code, I noticed comments like "-cim 9/10/89".
> It's the initials of the person who, back in 1989, wrote the preceding
> comments
Right.
> PostgreSQL inherited the code which is when our
Hi,
Attached is a small patch to fix a comment on PQcancelErrorMessage.
It was accidentally "Get the socket of the cancel connection."
I rewrote it to "Returns the error message most recently generated
by an operation on the cancel connection."
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git
On Jul 4, 2024, at 12:16 PM, David G. Johnston
wrote:
On Wed, Jul 3, 2024 at 8:46 PM Steve Lau
mailto:stevel...@outlook.com>> wrote:
While reading the source code, I noticed comments like "-cim 9/10/89". I think
this might be an annotation by a developer to indicate the commit time, but
On Thu, Jul 04, 2024 at 10:11:02AM +0700, Andrei Lepikhov wrote:
> It is a feature my extensions (which usually change planning behaviour)
> definitely need. It is a problem to show the user if the extension does
> something or not because TPS smooths the execution time of a single query
> and
On Wed, Jul 3, 2024 at 8:46 PM Steve Lau wrote:
>
> While reading the source code, I noticed comments like "-cim 9/10/89". I
> think this might be an annotation by a developer to indicate the commit
> time, but from the commit history (using git), they does not seem to match.
>
It's the
Hi, Postgres hackers!
While reading the source code, I noticed comments like "-cim 9/10/89". I think
this might be an annotation by a developer to indicate the commit time, but
from the commit history (using git), they does not seem to match.
Specifically:
1. What does “cim” mean here?
On Thu, Jul 4, 2024 at 3:10 PM Tom Lane wrote:
> Unless you've specifically checked that this reduces diffs against
> upstream tzcode, I'd really prefer not to touch that code right now.
> I know I'm overdue for a round of syncing src/timezone/ with upstream,
> but I can't see how drive-by
On 6/13/24 14:59, Michael Paquier wrote:
This will hopefully spark a discussion, and I was looking for answers
regarding these questions:
- Should the pgstat_kind_infos array in pgstat.c be refactored to use
something similar to pgstat_add_kind?
- How should the persistence of the custom stats
Thomas Munro writes:
> New version attached. This time I was brave enough to try to tackle
> src/timezone too, which had comments planning to drop a lot of small
> differences against the upstream tzcode once all supported branches
> required C99.
Unless you've specifically checked that this
On 2024-07-03 02:07, Fujii Masao wrote:
Thanks for your comments!
On 2024/01/26 18:49, torikoshia wrote:
Hi,
9e2d870 enabled the COPY command to skip soft error, and I think we
can add another option which specifies the maximum tolerable number of
soft errors.
I remember this was
On Thu, Jul 4, 2024 at 5:15 AM jian he wrote:
> in remove_self_join_rel, i have
> ```ChangeVarNodes((Node *) root->parse, toRemove->relid, toKeep->relid, 0);```
> which will change the joinlist(RangeTblRef) from (1,2) to (2,2).
> Immediately after this call, I wrote a function
On Wed, Jul 03, 2024 at 04:09:54PM -0700, Noah Misch wrote:
> On Wed, Jul 03, 2024 at 06:00:00AM +0300, Alexander Lakhin wrote:
> > 29.06.2024 05:42, Noah Misch wrote:
> > > Good point, any effort on (2) would be wasted once the fixes get
> > > certified. I
> > > pushed (1). I'm attaching the
On Wed, Jul 3, 2024 at 11:39 AM Alexander Korotkov wrote:
>
> On Mon, Jun 17, 2024 at 3:00 AM jian he wrote:
> > On Mon, May 6, 2024 at 11:55 PM Tom Lane wrote:
> > >
> > > Robert Haas writes:
> > > > I want to go on record right now as disagreeing with the plan proposed
> > > > in the commit
On Wed, 3 Jul 2024 at 09:49, Tom Lane wrote:
>
> Heikki Linnakangas writes:
> > 3. Oh right, bitmap scan, I forgot about that one. Let's disable that too:
>
> Yeah, I've hit that too, although more often (for me) it's the first
> choice of plan. In any case, it usually takes more than one
Hi Vignesh. Here are my comments for the latest patch v20240703-0001.
==
doc/src/sgml/func.sgml
nitpick - /lsn/LSN/ (all other doc pages I found use uppercase for this acronym)
==
src/backend/commands/sequence.c
nitpick - /lsn/LSN/
==
Please see attached nitpicks diff.
==
On Sat, May 18, 2024 at 10:56:43AM +0900, Michael Paquier wrote:
> Thanks. I'll look again at that once v18 opens up for business.
Looked at that again, and one in tablecmds.c is not needed anymore,
and there was a conflict in be-secure-openssl.c. Removed the first
one, fixed the second one,
On Wed, Jul 03, 2024 at 06:00:00AM +0300, Alexander Lakhin wrote:
> 29.06.2024 05:42, Noah Misch wrote:
> > Good point, any effort on (2) would be wasted once the fixes get certified.
> > I
> > pushed (1). I'm attaching the rebased fix patches.
>
> Please look at a new anomaly, introduced by
pgproc.h has this:
struct PGPROC
{
/* proc->links MUST BE FIRST IN STRUCT (see ProcSleep,ProcWakeup,etc) */
dlist_node links; /* list link if process is in a
list */
dlist_head *procgloballist; /* procglobal list that owns this PGPROC */
...
I
On Thu, 4 Jul 2024 at 04:19, Tom Lane wrote:
> - * Return the current fileset based BufFile size.
> + * Returns the size if the given BufFile in bytes.
>
> "Returns the size of", no doubt?
Yes, thanks.
> A shade less nit-pickily, I wonder if "size" is sufficient.
> It's not really obvious that
On Tue, 2024-07-02 at 16:03 -0700, Noah Misch wrote:
> Each packager can choose their dependencies so the v16 providers
> don't have
> the problem. With the $SUBJECT provider, a packager won't have that
> option.
While nothing needs to be changed for 17, I agree that we may need to
be careful in
On Wed, Jul 3, 2024, at 22:27, Joel Jacobson wrote:
> On Wed, Jul 3, 2024, at 20:57, Dean Rasheed wrote:
>> I wouldn't expect it to ever be off by more than 1, given that
>> MUL_GUARD_DIGITS = 2, which corresponds to 8 decimal digits, and the
>> number of digits in the smaller input (and hence the
On Wed, Jul 3, 2024, at 20:57, Dean Rasheed wrote:
> Ah yes, I think I was looking at a newer version of the code where I'd
> already fixed that bug. Unless you think there are still bugs in any
> of the boundary checks, which is entirely possible.
Ah, that explains it.
And no, I can't find any
Committed.
--
nathan
On Wed, Jul 3, 2024 at 10:09 AM Fujii Masao wrote:
> The documentation states that "WAL summarization cannot be enabled when
> wal_level is set to minimal." Therefore, at startup, the postmaster checks
> these settings and exits with an error if they are not configured properly.
>
> However, I
On Wed, Jul 3, 2024, at 15:48, Joel Jacobson wrote:
> On Wed, Jul 3, 2024, at 13:17, Dean Rasheed wrote:
>> On Tue, 2 Jul 2024 at 21:10, Joel Jacobson wrote:
>>>
>>> I found the bug in the case 3 code,
>>> and it turns out the same type of bug also exists in the case 2 code:
>>>
>>>
On Wed, 3 Jul 2024 at 14:49, Joel Jacobson wrote:
>
> Hmm, I don't see how the case 2 code can be correct?
> If, like you say, res_ndigits can't be less than 3, that means it can be 3,
> right?
> And if res_ndigits=3 then `var2digits[res_ndigits - 4]` would try to access
> `var2digits[-1]`.
>
Is there a guidebook, any guidelines for writing grammar in Postgres, or
any suggestions to keep in mind?
Do we have a set of guidelines to write production rules in gram.y (for the
Bison Parser Generator) to make the grammar conflict-free and extendible in
the future?
On Mon, 24 Jun 2024 at 02:58, Tomas Vondra
wrote:
>
> Here's a bit more cleaned up version, clarifying a lot of comments,
> removing a bunch of obsolete comments, or comments speculating about
> possible solutions, that sort of thing. I've also removed couple more
> XXX comments, etc.
>
> The
On 6/26/24 22:39, Tom Browder wrote:
> On Tue, Jun 25, 2024 at 9:15 AM Muhammad Ikram wrote:
>> Hi ,
>> Here is a lately published book
>> https://www.amazon.com/PostgreSQL-Administration-Cookbook-real-world-challenges-ebook/dp/B0CP5PPSTQ
>
> Thanks, Muhammed, I just bought it.
>
> And thanks
On 7/3/24 18:51, Andrey M. Borodin wrote:
>
>
>> On 3 Jul 2024, at 01:08, Corey Huinker
>> wrote:
>>
>> I'll give it a shot.
>
> Great, thank you! Do you have extended access to CF? Like activity
> log and mass-mail functions? If no I think someone from PG_INFRA can
> grant you necessary
On Thu, May 09, 2024 at 05:19:47PM +1200, Thomas Munro wrote:
> On Thu, Dec 28, 2023 at 11:42 AM Tom Lane wrote:
> > Thomas Munro writes:
> > > In CommitTransaction() there is a stretch of code beginning s->state =
> > > TRANS_COMMIT and ending s->state = TRANS_DEFAULT, from which we call
> > >
On Mon, Jul 1, 2024 at 2:08 AM Michael Paquier wrote:
> Nope. So, Open Item, here we go.
Some initial investigation:
In this test case, pg_subscriber, during the "starting the subscriber"
section of its work, starts up the database in the "sub" directory as
a standby. It enters standby mode,
> On 3 Jul 2024, at 01:08, Corey Huinker wrote:
>
> I'll give it a shot.
Great, thank you! Do you have extended access to CF? Like activity log and
mass-mail functions?
If no I think someone from PG_INFRA can grant you necessary access.
> On 3 Jul 2024, at 20:21, Tomas Vondra wrote:
>
I had a look at this patchset today and I think I've come around to the idea of
having a separate GUC for cipher suites. I don't have strong opinions on
renaming ssl_ecdh_curve to reflect that it can take a list of multiple values,
there is merit to having descriptive names but it would also be
David Rowley writes:
> I've attached an updated patch which updates the comments and also
> removes the misplaced Asserts from BufFileAppend.
> If there are no objections or additional feedback, I'll push this patch soon.
- * Return the current fileset based BufFile size.
+ * Returns the size if
V4 path with fixed usage PG_GETARG_BYTEA_PP instead of PG_GETARG_TEXT_PP
--
With best regards,
Marat Bukharov
>
> V3 patch with fixed length comparison
>
> >
> > V2 patch with fixed tests
> >
> > >
> > > Hello. BYTEA type has the ability to use comparison operations. But it
> > > is absent of
Hi,
This reminded me that one of the changes proposed at pgconf.dev was
having multiple CF managers, each responsible for a subset of the CF
entries. Do we want to do try that?
IIRC the idea was that it's not really feasible to shepherd ~400 patches
(the current count for 2024-07), especially if
Nathan Bossart writes:
> This sort of thing comes up enough that perhaps we should add a
> better-supported way to deal with GUCs that depend on each other...
Yeah, a GUC check hook that tries to inspect the value of some
other GUC is generally going to create more problems than it
solves; we've
On Wed, 3 Jul 2024 at 16:46, Jelte Fennema-Nio wrote:
>
> Ugh copy paste mistake, this is what I meant
>
> On Wed, 3 Jul 2024 at 16:45, Jelte Fennema-Nio wrote:
> > This hits the already existing check:
> > summarize_wal = 'true'
> > wal_level = 'minimal'
> >
> > This hits the new check:
> >
V3 patch with fixed length comparison
--
With best regards,
Marat Bukharov
>
> V2 patch with fixed tests
>
> >
> > Hello. BYTEA type has the ability to use comparison operations. But it
> > is absent of min/max aggregate functions. They are nice to have to
> > provide consistency with the TEXT
V3 patch with fixed length comparison
--
With best regards,
Marat Bukharov
>
> V2 patch with fixed tests
>
> >
> > Hello. BYTEA type has the ability to use comparison operations. But it
> > is absent of min/max aggregate functions. They are nice to have to
> > provide consistency with the TEXT
Ugh copy paste mistake, this is what I meant
On Wed, 3 Jul 2024 at 16:45, Jelte Fennema-Nio wrote:
> This hits the already existing check:
> summarize_wal = 'true'
> wal_level = 'minimal'
>
> This hits the new check:
> summarize_wal = 'true'
> wal_level = 'minimal'
>
> And actually this would
On Wed, 3 Jul 2024 at 16:30, Nathan Bossart wrote:
> IME these sorts of GUC hooks that depend on the value of other GUCs tend to
> be quite fragile. This one might be okay because wal_level defaults to
> 'replica' and because there is an additional check in postmaster.c, but
> that at least
> On 3 Jul 2024, at 16:29, Nathan Bossart wrote:
> This sort of thing comes up enough that perhaps we should add a
> better-supported way to deal with GUCs that depend on each other...
+1
--
Daniel Gustafsson
On Wed, 3 Jul 2024 at 08:24, Peter Smith wrote:
>
> Here are my comments for patch v20240702-0001
>
> They are all cosmetic and/or typos. Apart from these the 0001 patch LGTM.
>
> ==
> doc/src/sgml/func.sgml
>
> Section 9.17. Sequence Manipulation Functions
>
> pg_sequence_state:
> nitpick -
On Wed, Jul 03, 2024 at 11:08:48PM +0900, Fujii Masao wrote:
> +/*
> + * GUC check_hook for summarize_wal
> + */
> +bool
> +check_summarize_wal(bool *newval, void **extra, GucSource source)
> +{
> + if (*newval && wal_level == WAL_LEVEL_MINIMAL)
> + {
> + GUC_check_errmsg("WAL
V2 patch with fixed tests
--
With best regards,
Marat Bukharov
ср, 3 июл. 2024 г. в 16:03, Marat Buharov :
>
> Hello. BYTEA type has the ability to use comparison operations. But it
> is absent of min/max aggregate functions. They are nice to have to
> provide consistency with the TEXT type.
>
Hi,
The documentation states that "WAL summarization cannot be enabled when wal_level is
set to minimal." Therefore, at startup, the postmaster checks these settings and
exits with an error if they are not configured properly.
However, I found that summarize_wal can still be enabled while the
On Wed, Jul 3, 2024, at 13:17, Dean Rasheed wrote:
> On Tue, 2 Jul 2024 at 21:10, Joel Jacobson wrote:
>>
>> I found the bug in the case 3 code,
>> and it turns out the same type of bug also exists in the case 2 code:
>>
>> case 2:
>> newdig
> On 3 Jul 2024, at 15:41, Aleksander Alekseev wrote:
>> The 'cur_skey' parameter in `IndexScanOK` funciton doesn't seem to be useful.
> Good catch. As I understand it is not used for anything since
> a78fcfb51243 (dated 2006) and this is a static function, so we
> shouldn't worry about
On Wed, Jul 3, 2024 at 5:34 AM Fujii Masao wrote:
> pg_wal_summary_contents() seems to miss the summary information with "limit"
> that pg_walsummary reports. This appears to be a bug. The attached patch
> fixes this.
Oops. It looks like pg_wal_summary_contents() forgets to emit the
limit
Hi,
> The 'cur_skey' parameter in `IndexScanOK` funciton doesn't seem to be useful.
Good catch. As I understand it is not used for anything since
a78fcfb51243 (dated 2006) and this is a static function, so we
shouldn't worry about third-party extensions.
I wonder why none of the compilers
Hi,
On July 3, 2024 3:17:29 PM GMT+02:00, Joe Conway wrote:
>On 7/2/24 17:39, Thomas Munro wrote:
>> One difference that jumps out is that the successful v3 run has label
>> worker:jc-m2-1 (Mac hosted by Joe), and the failure has
>> worker:pgx-m2-1 (Mac hosted by Christophe P). Is this a
On 18/05/2024 08:24, Thomas Munro wrote:
Nitpicking from UBSan with EXEC_BACKEND on Linux (line numbers may be
a bit off, from a branch of mine):
../src/backend/postmaster/launch_backend.c:772:2: runtime error: null
pointer passed as argument 2, which is declared to never be null
==13303==Using
Michael Paquier writes:
> On Tue, Jul 02, 2024 at 01:55:25PM +0100, Dagfinn Ilmari Mannsåker wrote:
>> For clarity, I've rebased my addional unused-variable changes (except
>> the errcodes-related ones, see below) onto current master, and split it
>> into separate commits with detailed
On 7/2/24 17:39, Thomas Munro wrote:
One difference that jumps out is that the successful v3 run has label
worker:jc-m2-1 (Mac hosted by Joe), and the failure has
worker:pgx-m2-1 (Mac hosted by Christophe P). Is this a software
version issue, ie need newer Tart to use that image, or could be a
Hello. BYTEA type has the ability to use comparison operations. But it
is absent of min/max aggregate functions. They are nice to have to
provide consistency with the TEXT type.
--
With best regards,
Marat Bukharov
From 109b91999b7a8d8c1808658134494b91616c2825 Mon Sep 17 00:00:00 2001
From:
On Tue, Jul 2, 2024 at 5:39 PM Heikki Linnakangas wrote:
> I would be somewhat annoyed if we add another step to that, to also
> disable index-only scans separately. It would be nice if
> enable_indexscan=off would also disable bitmap scans, that would
> eliminate one step from the above. Almost
On Mon, Jul 1, 2024 at 6:19 PM Dean Rasheed wrote:
> Repeating your benchmark where both numbers have up to 2 NBASE-digits,
> this new approach was slightly faster:
>
> SELECT SUM(num1*num2) FROM bench_mul_var; -- HEAD
> Time: 4762.990 ms (00:04.763)
> Time: 4332.166 ms (00:04.332)
> Time:
On Wed, Jul 3, 2024 at 5:08 PM shveta malik wrote:
>
> On Wed, Jul 3, 2024 at 4:12 PM Dilip Kumar wrote:
> >
> > On Wed, Jul 3, 2024 at 4:02 PM shveta malik wrote:
> > >
> > > On Wed, Jul 3, 2024 at 11:29 AM Dilip Kumar wrote:
> > > >
> > > > On Wed, Jul 3, 2024 at 11:00 AM shveta malik
> >
Hi,
> We currently do something similar with OIDs where we just keep
> generating them and then testing for conflicts.
>
> I don't think this is the best way to do it but it mostly works when
> you can actually test for uniqueness, like for example in TOAST or
> system tables.
>
> Not sure this
> On 3 Jul 2024, at 16:29, Hannu Krosing wrote:
>
> We currently do something similar with OIDs where we just keep
> generating them and then testing for conflicts.
>
> I don't think this is the best way to do it but it mostly works when
> you can actually test for uniqueness, like for
Em qua., 3 de jul. de 2024 às 08:18, Dean Rasheed
escreveu:
> On Tue, 2 Jul 2024 at 21:10, Joel Jacobson wrote:
> >
> > I found the bug in the case 3 code,
> > and it turns out the same type of bug also exists in the case 2 code:
> >
> > case 2:
> >
On Wed, 3 Jul 2024 at 08:36, Joel Jacobson wrote:
>
> Hello hackers,
>
> I have discovered a peculiar behavior in mul_var() when it is called with
> rscale=0, but the input variables have many decimal digits, resulting in a
> product with a .5 decimal part. Given that no decimals are requested by
On Wed, Jul 3, 2024 at 4:12 PM Dilip Kumar wrote:
>
> On Wed, Jul 3, 2024 at 4:02 PM shveta malik wrote:
> >
> > On Wed, Jul 3, 2024 at 11:29 AM Dilip Kumar wrote:
> > >
> > > On Wed, Jul 3, 2024 at 11:00 AM shveta malik
> > > wrote:
> > > >
> > > > > Yes, I also think it should be
On Wed, Jul 3, 2024 at 4:48 PM Amit Kapila wrote:
>
> On Wed, Jul 3, 2024 at 4:04 PM Dilip Kumar wrote:
> >
> > On Wed, Jul 3, 2024 at 3:35 PM Amit Kapila wrote:
> > >
> > > On Wed, Jul 3, 2024 at 2:16 PM Dilip Kumar wrote:
> > > >
> > > > On Wed, Jul 3, 2024 at 12:30 PM Amit Kapila
> > > >
We currently do something similar with OIDs where we just keep
generating them and then testing for conflicts.
I don't think this is the best way to do it but it mostly works when
you can actually test for uniqueness, like for example in TOAST or
system tables.
Not sure this works even
Em qua., 3 de jul. de 2024 às 04:37, Daniel Gustafsson
escreveu:
> Re-reading Nathans recent 8213df9effaf I noticed a few more small things
> which
> can be cleaned up. In two of the get functions we lack a
> fast-path for
> when no tuples are found which leads to pg_malloc(0) calls. Another
Hi Daniel,
Thanks for rebasing the patch and submitting it again!
On 7/3/24 08:41, Daniel Gustafsson wrote:
> After some off-list discussion about the desirability of this feature, where
> several hackers opined that it's something that we should have, I've decided
> to
> rebase this patch and
On Wed, Jul 3, 2024 at 4:04 PM Dilip Kumar wrote:
>
> On Wed, Jul 3, 2024 at 3:35 PM Amit Kapila wrote:
> >
> > On Wed, Jul 3, 2024 at 2:16 PM Dilip Kumar wrote:
> > >
> > > On Wed, Jul 3, 2024 at 12:30 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Wed, Jul 3, 2024 at 11:29 AM Dilip Kumar
On Tue, 2 Jul 2024 at 21:10, Joel Jacobson wrote:
>
> I found the bug in the case 3 code,
> and it turns out the same type of bug also exists in the case 2 code:
>
> case 2:
> newdig = (int) var1digits[1] *
> var2digits[res_ndigits - 4];
>
On Wed, Jul 3, 2024 at 12:42 PM Hayato Kuroda (Fujitsu)
wrote:
>
> >
> > Disabling on the primary node should be sufficient. Let's do the
> > minimum required to stabilize this test.
>
> +1, removed.
>
> PSA new version. 0001 has not been changed yet. A comment was added
> in 0002 to clarify why
On 2024/07/03 17:51, hajime.matsun...@nttdata.com wrote:
Thanks for the suggestions the other day.
I have created a patch that incorporates your suggestions.
-pg_stat_database, in the output of
+pg_stat_database and
+
+pg_stat_io, in the output of
I'm not a
On Wed, Jul 3, 2024 at 4:02 PM shveta malik wrote:
>
> On Wed, Jul 3, 2024 at 11:29 AM Dilip Kumar wrote:
> >
> > On Wed, Jul 3, 2024 at 11:00 AM shveta malik wrote:
> > >
> > > > Yes, I also think it should be independent of CDR. IMHO, it should be
> > > > based on the user-configured maximum
On Tue, 2 Jul 2024 at 20:55, Joel Jacobson wrote:
>
> Interesting, I actually think there is a bug in the normal mul_var() code.
> Found a case that rounds down, when it should round up:
>
> Calling mul_var() with:
> var1=51.2945442386599
> var2=0.828548712212
> rscale=0
>
> returns 42, but I
Thank you for having another look at this.
On Wed, 3 Jul 2024 at 00:20, Matthias van de Meent
wrote:
> I noticed this change to buffile.c shows up in both v1 and v2 of the
> patchset, but I can't trace the reasoning why it changed with this
> patch (rather than a separate bugfix):
I didn't
On Wed, Jul 3, 2024 at 3:35 PM Amit Kapila wrote:
>
> On Wed, Jul 3, 2024 at 2:16 PM Dilip Kumar wrote:
> >
> > On Wed, Jul 3, 2024 at 12:30 PM Amit Kapila wrote:
> > >
> > > On Wed, Jul 3, 2024 at 11:29 AM Dilip Kumar wrote:
> >
> > > But waiting after applying the operations and before
> On 3 Jul 2024, at 13:48, Aleksander Alekseev wrote:
>
> Hi,
>
>> That’s a very interesting result, from the UUID POV!
>> If time is almost always advancing, using time readings instead of a counter
>> is very reasonable: we have interprocess monotonicity almost for free.
>> Though time is
On Wed, Jul 3, 2024 at 3:35 PM Amit Kapila wrote:
>
> On Wed, Jul 3, 2024 at 2:16 PM Dilip Kumar wrote:
> >
> > On Wed, Jul 3, 2024 at 12:30 PM Amit Kapila wrote:
> > >
> > > On Wed, Jul 3, 2024 at 11:29 AM Dilip Kumar wrote:
> >
> > > But waiting after applying the operations and before
On Wed, Jul 3, 2024 at 11:29 AM Dilip Kumar wrote:
>
> On Wed, Jul 3, 2024 at 11:00 AM shveta malik wrote:
> >
> > > Yes, I also think it should be independent of CDR. IMHO, it should be
> > > based on the user-configured maximum clock skew tolerance and can be
> > > independent of CDR.
> >
> >
On Wed, Jul 3, 2024 at 10:03 AM Tom Lane wrote:
Keep in mind also that instr_time.h does not pretend to provide
> real time --- the clock origin is arbitrary. But these results
> do give me additional confidence that gettimeofday() should be
> good to the microsecond on any remotely-modern
On Wed, Jul 3, 2024 at 2:16 PM Dilip Kumar wrote:
>
> On Wed, Jul 3, 2024 at 12:30 PM Amit Kapila wrote:
> >
> > On Wed, Jul 3, 2024 at 11:29 AM Dilip Kumar wrote:
>
> > But waiting after applying the operations and before applying the
> > commit would mean that we need to wait with the locks
On Fri, Jun 21, 2024 at 08:13:15AM +0900, Michael Paquier wrote:
> On Thu, Jun 20, 2024 at 02:27:14PM +, Bertrand Drouvot wrote:
>> On Thu, Jun 20, 2024 at 09:46:30AM +0900, Michael Paquier wrote:
>> I think it makes sense to follow the same "behavior" as the custom
>> wal resource managers.
Hi,
I found that pg_wal_summary_contents() may miss some results that pg_walsummary
returns for the same WAL summary file. Here are the steps to reproduce the
issue:
-
initdb -D data
echo "summarize_wal = on" >> data/postgresql.conf
pg_ctl -D data start
psql
From: Nazir Bilal Yavuz
Sent: Thursday, June 27, 2024 9:01 PM
>
> Hi,
>
> On Thu, 27 Jun 2024 at 14:30, Melanie Plageman
> wrote:
> >
> > On Thu, Jun 27, 2024 at 5:06 AM wrote:
> > >
> > > Hi,
> > >
> > > pg_stat_io has I/O statistics that are collected when track_io_timing is
> > > enabled,
On Wed, 3 Jul 2024 at 08:06, David Rowley wrote:
>
> On Fri, 17 May 2024 at 19:19, David Rowley wrote:
> >
> > On Thu, 16 May 2024 at 07:20, Peter Geoghegan wrote:
> > > Notice that comments above BufFileSize() say "Return the current
> > > fileset based BufFile size". There are numerous
Hi,
> That’s a very interesting result, from the UUID POV!
> If time is almost always advancing, using time readings instead of a counter
> is very reasonable: we have interprocess monotonicity almost for free.
> Though time is advancing in a very small steps… RFC assumes that we use
>
On Wed, Jul 3, 2024 at 12:30 PM Amit Kapila wrote:
>
> On Wed, Jul 3, 2024 at 11:29 AM Dilip Kumar wrote:
> But waiting after applying the operations and before applying the
> commit would mean that we need to wait with the locks held. That could
> be a recipe for deadlocks in the system. I see
On 7/1/24 16:17, Andrei Lepikhov wrote:
On 10/12/23 14:52, Andy Fan wrote:
Here the sublink can't be pulled up because of its reference to
the LHS of left join, the original logic is that no matter the 'b.t
in ..'
returns the true or false, the rows in LHS will be returned. If we
pull it
Thomas Munro writes:
> Here are some experimental patches to try out some ideas mentioned
> upthread, that are approximately unlocked by that cleanup.
FWIW, I'm good with getting rid of --disable-spinlocks and
--disable-atomics. That's a fair amount of code and needing to
support it causes
"Andrey M. Borodin" writes:
> That’s a very interesting result, from the UUID POV!
> If time is almost always advancing, using time readings instead of a counter
> is very reasonable: we have interprocess monotonicity almost for free.
> Though time is advancing in a very small steps… RFC assumes
Re-reading Nathans recent 8213df9effaf I noticed a few more small things which
can be cleaned up. In two of the get functions we lack a fast-path for
when no tuples are found which leads to pg_malloc(0) calls. Another thing is
that we in one place reset the PQExpBuffer immediately after creating
Hello hackers,
I have discovered a peculiar behavior in mul_var() when it is called with
rscale=0, but the input variables have many decimal digits, resulting in a
product with a .5 decimal part. Given that no decimals are requested by the
caller, I would expect the result to be rounded up.
Dear Amit,
> Your analysis looks correct to me. The test could fail due to
> autovacuum. See the following comment in
> 040_standby_failover_slots_sync.
>
> # Disable autovacuum to avoid generating xid during stats update as otherwise
> # the new XID could then be replicated to standby at some
On Wed, Jul 3, 2024 at 11:29 AM Dilip Kumar wrote:
>
> On Wed, Jul 3, 2024 at 11:00 AM shveta malik wrote:
> >
> > > Yes, I also think it should be independent of CDR. IMHO, it should be
> > > based on the user-configured maximum clock skew tolerance and can be
> > > independent of CDR.
> >
> >
On Wed, Jul 3, 2024 at 10:42 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Based on that, I considered a scenario why the slot could not be synchronized.
> I felt this was not caused by the pg_createsubscriber.
>
> 1. At initial stage, the xmin of the physical slot is 743, and nextXid of the
>primary
On Wed, Jul 3, 2024 at 11:27 AM Amit Kapila wrote:
>
> > Do you have any other idea?
> >
>
> The other idea could be that we use the minimum restart_lsn of all the
> slots created by this tool as a consistent_lsn. We can probably get
> that value by using pg_get_replication_slots() but this idea
On Fri, 17 May 2024 at 19:19, David Rowley wrote:
>
> On Thu, 16 May 2024 at 07:20, Peter Geoghegan wrote:
> > Notice that comments above BufFileSize() say "Return the current
> > fileset based BufFile size". There are numerous identical assertions
> > at the start of several other functions
100 matches
Mail list logo
