On Sat, 29 Jun 2024 at 16:25, Tom Lane wrote:
>
> Dean Rasheed writes:
> > There's another complication though (if the threshold is made
> > configurable): the various numeric functions that use mul_var() are
> > immutable, which means that the results from the Karatsuba algorithm
> > must match
Hi,
merge sorts requires all the tuples in each input are pre-sorted (1),
and in tuplesort.c, when the workmem is full, we dumptuples into
destTape. (2). it looks to me that we need a unlimited number of Tapes
if the number of input tuples is big enough. However we set a maxTapes
in 'inittapes'
On 30/06/2024 12:48, Andy Fan wrote:
merge sorts requires all the tuples in each input are pre-sorted (1),
and in tuplesort.c, when the workmem is full, we dumptuples into
destTape. (2). it looks to me that we need a unlimited number of Tapes
if the number of input tuples is big enough. However
On Sat, Jun 29, 2024, at 14:22, Dean Rasheed wrote:
> On Sun, Jun 23, 2024 at 09:00:29AM +0200, Joel Jacobson wrote:
>> Attached, rebased version of the patch that implements the Karatsuba
>> algorithm in numeric.c's mul_var().
>>
>
> Something to watch out for is that not all callers of mul_var()
On Thu, Jun 27, 2024, at 10:42, Joel Jacobson wrote:
> I'll start a new separate thread about fixing the other non-canonical URLs.
Here is the separate thread to fix the docs to use canonical links:
https://postgr.es/m/8ccc96c7-0515-491b-be98-cfacdaeda...@app.fastmail.com
On 2024-Jun-30, Joel Jacobson wrote:
> However, I can imagine other crypto algorithms might require larger factors,
> as well as other scientific research use cases, such as astronomy and physics,
> that could desire storage of numeric values of very high precision.
FWIW I was talking to some peo
Heikki Linnakangas writes:
> On 30/06/2024 12:48, Andy Fan wrote:
>> for example, at the first use of outputTapes[x], it stores (1, 3, 5,
>> 7),
>> and later (2, 4, 6, 8) are put into it. so the overall of (1, 3, 5, 7,
>> 2, 4, 6, 8) are not sorted? Where did I go wrong?
>
> There's a distincti
On Sat, Jun 29, 2024, at 17:25, Tom Lane wrote:
> Dean Rasheed writes:
>> There's another complication though (if the threshold is made
>> configurable): the various numeric functions that use mul_var() are
>> immutable, which means that the results from the Karatsuba algorithm
>> must match those
Hello Peter and Euler,
17.06.2024 14:04, Peter Eisentraut wrote:
On 07.06.24 05:49, Euler Taveira wrote:
Here it is a patch series to fix the issues reported in recent discussions. The
patches 0001 and 0003 aim to fix the buildfarm issues. The patch 0002 removes
synchronized failover slots on s
Hi hackers,
Is there any extension that uses meson as build systems?
I'm starting a extension project that written in c++, cmake is my
initial choice as the build system, but since PostgreSQL has adopted
Meson, so I'm wondering if there is any extension that also uses
meson that I can reference.
Hi
ne 30. 6. 2024 v 15:17 odesílatel Junwang Zhao napsal:
> Hi hackers,
>
> Is there any extension that uses meson as build systems?
> I'm starting a extension project that written in c++, cmake is my
> initial choice as the build system, but since PostgreSQL has adopted
> Meson, so I'm wonderi
On Sun, Jun 30, 2024 at 9:20 PM Pavel Stehule wrote:
>
> Hi
>
> ne 30. 6. 2024 v 15:17 odesílatel Junwang Zhao napsal:
>>
>> Hi hackers,
>>
>> Is there any extension that uses meson as build systems?
>> I'm starting a extension project that written in c++, cmake is my
>> initial choice as the bu
ne 30. 6. 2024 v 15:28 odesílatel Junwang Zhao napsal:
> On Sun, Jun 30, 2024 at 9:20 PM Pavel Stehule
> wrote:
> >
> > Hi
> >
> > ne 30. 6. 2024 v 15:17 odesílatel Junwang Zhao
> napsal:
> >>
> >> Hi hackers,
> >>
> >> Is there any extension that uses meson as build systems?
> >> I'm starting
On Sun, Jun 30, 2024 at 9:31 PM Pavel Stehule wrote:
>
>
>
> ne 30. 6. 2024 v 15:28 odesílatel Junwang Zhao napsal:
>>
>> On Sun, Jun 30, 2024 at 9:20 PM Pavel Stehule
>> wrote:
>> >
>> > Hi
>> >
>> > ne 30. 6. 2024 v 15:17 odesílatel Junwang Zhao napsal:
>> >>
>> >> Hi hackers,
>> >>
>> >> I
ne 30. 6. 2024 v 15:39 odesílatel Junwang Zhao napsal:
> On Sun, Jun 30, 2024 at 9:31 PM Pavel Stehule
> wrote:
> >
> >
> >
> > ne 30. 6. 2024 v 15:28 odesílatel Junwang Zhao
> napsal:
> >>
> >> On Sun, Jun 30, 2024 at 9:20 PM Pavel Stehule
> wrote:
> >> >
> >> > Hi
> >> >
> >> > ne 30. 6. 202
Hi Hackers
When I saw this document:https://en.wikipedia.org/wiki/Branch_predictor,
I thought of Linux likely() vs unlikely() and thus thought that there are
some code segments in src/backend/executor/execMain.c that can be optimized.
For example :
if (ExecutorStart_hook)
(*ExecutorStart_hook) (
On Sun, 30 Jun 2024, 15:56 wenhui qiu, wrote:
>
> Hi Hackers
>When I saw this document:https://en.wikipedia.org/wiki/Branch_predictor, I
> thought of Linux likely() vs unlikely() and thus thought that there are some
> code segments in src/backend/executor/execMain.c that can be optimized.
>
On Sat, Jun 29, 2024, at 14:22, Dean Rasheed wrote:
> However, I really don't like having these magic constants at all,
> because in practice the threshold above which the Karatsuba algorithm
> is a win can vary depending on a number of factors, such as whether
> it's running on 32-bit or 64-bit, w
Matthias van de Meent writes:
> On Sun, 30 Jun 2024, 15:56 wenhui qiu, wrote:
>> if (unlikely(ExecutorRun_hook)),
> While hooks are generally not installed by default, I would advise
> against marking the hooks as unlikely, as that would unfairly penalize
> the performance of extensions that do
"Joel Jacobson" writes:
> On Sat, Jun 29, 2024, at 17:25, Tom Lane wrote:
>> (In general I find this patch seriously undercommented.)
> However, I think the comments above split_var_at(),
> mul_var_karatsuba_full() and mul_var_karatsuba_half()
> are quite good already, what do you think?
Not rem
Alexander Lakhin writes:
> As a recent buildfarm failure [1] shows, that test addition introduced
> new instability:
I have a different but possibly-related complaint: why is
040_pg_createsubscriber.pl so miserably slow? On my machine it
runs for a bit over 19 seconds, which seems completely out
On Mon, May 06, 2024 at 02:23:38PM -0700, Jacob Champion wrote:
> =# select * from pg_stat_activity where state = 'authenticating';
> -[ RECORD 1 ]+--
> datid|
> datname |
> pid | 745662
> leader_pid |
>
On Sun, Jun 30, 2024, at 17:44, Tom Lane wrote:
> "Joel Jacobson" writes:
>> On Sat, Jun 29, 2024, at 17:25, Tom Lane wrote:
>>> (In general I find this patch seriously undercommented.)
>
>> However, I think the comments above split_var_at(),
>> mul_var_karatsuba_full() and mul_var_karatsuba_half(
In hopes of moving things along as we approach the v18 branch,
I went ahead and pushed Kuroda-san's patches (with a bit of
further editorialization). AFAICS that allows closing out
the concerns raised by Noah, so I've marked that open item
done. However, I added a new open item about how the
040_
Hello,
This patches changes the HeapKeyTest macro to add handling for SK_SEARCHNULL
and SK_SEARCHNOTNULL. While currently no core codes uses these ScanKey flags
it would be useful for extensions if it was supported so extensions
dont have to implement
handling for those by themself.
--
Regards,
Hi,
I've pushed the first three patches, fixing the headers, adding the
--copy option and PG_TEST_PG_COMBINEBACKUP_MODE variable.
I haven't pushed the CI changes, I'm not sure if there's a clear
consensus on which combination to test. It's something we can tweak
later, I think.
FWIW I've added t
I wrote:
> In hopes of moving things along as we approach the v18 branch,
> I went ahead and pushed Kuroda-san's patches (with a bit of
> further editorialization).
So b3f5ccebd promptly blew up on fairywren [1]:
connection error: 'psql: error: unterminated quoted string in connection info
strin
On Tue, Mar 12, 2024 at 05:50:48PM +0100, Alvaro Herrera wrote:
> On 2024-Mar-12, Jelte Fennema-Nio wrote:
> > On Tue, 12 Mar 2024 at 10:19, Alvaro Herrera
> > wrote:
> > > Here's a last one for the cfbot.
> >
> > Thanks for committing the first 3 patches btw.
>
> Thanks, I included it.
PGcanc
On Sun, Jun 30, 2024 at 02:58:00PM -0400, Tom Lane wrote:
> I wrote:
> > In hopes of moving things along as we approach the v18 branch,
> > I went ahead and pushed Kuroda-san's patches (with a bit of
> > further editorialization).
>
> So b3f5ccebd promptly blew up on fairywren [1]:
>
> connection
Noah Misch writes:
> On Sun, Jun 30, 2024 at 02:58:00PM -0400, Tom Lane wrote:
>> So b3f5ccebd promptly blew up on fairywren [1]:
> It does look consistent with IPC::Run predating v20220807.0, hence lacking the
> https://github.com/toddr/IPC-Run/issues/142 fix. I wondered how this animal
> was p
On Sun, Jun 30, 2024 at 05:01:52PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sun, Jun 30, 2024 at 02:58:00PM -0400, Tom Lane wrote:
> >> So b3f5ccebd promptly blew up on fairywren [1]:
>
> > It does look consistent with IPC::Run predating v20220807.0, hence lacking
> > the
> > https://g
> From: Fujii Yuki
> Sent: Monday, July 1, 2024 6:42 AM
> Hi hackers.
>
> On Wed, Jun 5, 2024 at 9:15?AM fujii.y...@df.mitsubishielectric.co.jp
> wrote:
> > Requirement2. Consider appropriate position of the new keyword
> > "PARTIAL_AGGREGATE". (with Robert)
> > Existing patch: Before th
On Mon, Mar 04, 2024 at 07:52:05PM -0800, Jeff Davis wrote:
> Committed.
Commit 2af07e2 wrote:
> --- a/src/backend/access/brin/brin.c
> +++ b/src/backend/access/brin/brin.c
> @@ -1412,6 +1412,8 @@ brin_summarize_range(PG_FUNCTION_ARGS)
> SetUserIdAndSecContext(heapRel->rd_rel->relown
On Tue, Nov 14, 2023 at 08:13:25PM -0800, Jeff Davis wrote:
> On Thu, 2023-10-19 at 19:01 -0700, Jeff Davis wrote:
> > 0003: Cache for recomputeNamespacePath.
>
> Committed
Commit f26c236 wrote:
> Add cache for recomputeNamespacePath().
>
> When search_path is changed to something th
On Sun, 30 Jun 2024 at 21:00, Noah Misch wrote:
> Shouldn't that be s/conn->status/cancelConn->status/?
Ugh yes, I think this was a copy paste error. See attached patch 0003
to fix this (rest of the patches are untouched from previous
revision).
v3-0001-Make-postgres_fdw-cancel-test-not-flaky-a
On Tue, Mar 12, 2024 at 02:10:59PM +0200, Alexander Korotkov wrote:
> I'm going to push this if no objections.
Commit e85662d wrote:
> --- a/src/backend/storage/ipc/procarray.c
> +++ b/src/backend/storage/ipc/procarray.c
> @@ -2740,6 +2741,8 @@ GetRunningTransactionData(void)
>*/
>
On Fri, Jun 28, 2024 at 4:18 PM Amit Kapila wrote:
>
...
> Shouldn't the check for flushptr (if (flushptr < targetPagePtr +
> reqLen)) be moved immediately after the call to WalSndWaitForWal().
> The comment seems to suggests the same: "Make sure we have enough WAL
> available before retrieving th
Hi all,
As some of you may have noticed, a new stable branch named
REL_17_STABLE has just been created, meaning that we are on time to
begin the development cycle for v18.
Commit fest 2024-07 (https://commitfest.postgresql.org/48/) is still
open for patches, and will be switched as active in the
On Thu, 27 Jun 2024 at 23:57, Peter Eisentraut wrote:
> Maybe we should really be thinking about deprecating these special
> values and steering users more urgently toward more robust alternatives.
>
> Imagine if 'random' were a valid input value for numeric types.
I think there are valid reasons
On Sun, Jun 30, 2024 at 4:55 PM David Rowley wrote:
>
> I'd like to know what led someone down the path of doing something
> like DEFAULT 'now()'::timestamp in a CREATE TABLE. Could it be a
> faulty migration tool that created these and people copy them thinking
> it's a legitimate syntax?
>
>
My
On Wed, Jun 26, 2024 at 2:39 AM Tom Lane wrote:
> I think the immediate action item should be to push back on the
> change and see if we can get Apple to undo it. If we have to
> fix it on our side, it is likely to involve API-breaking changes
> that will cause trouble for extensions. The more s
On Mon, 1 Jul 2024 at 12:16, David G. Johnston
wrote:
>
> On Sun, Jun 30, 2024 at 4:55 PM David Rowley wrote:
>>
>>
>> I'd like to know what led someone down the path of doing something
>> like DEFAULT 'now()'::timestamp in a CREATE TABLE. Could it be a
>> faulty migration tool that created these
On Wed, Jun 26, 2024 at 09:30:27AM +0900, Michael Paquier wrote:
> Fine by me as well. I guess I'll just apply that once v18 opens up.
And done with 00d819d46a6f.
--
Michael
signature.asc
Description: PGP signature
On Sat, Jun 08, 2024 at 07:31:21AM +0900, Michael Paquier wrote:
> Thanks for looking, Andres! I guess I'll just apply that once v18
> opens up.
Applied as of b19db55bd687.
--
Michael
signature.asc
Description: PGP signature
Noah Misch writes:
> On Sun, Jun 30, 2024 at 05:01:52PM -0400, Tom Lane wrote:
>> I'm tempted to lobotomize the new test case on Windows until
>> we have that resolved.
> Sounds fine. The pg_upgrade suite adequately tests appendShellString() and
> appendConnStrVal() with the larger character rep
On Sun, Jun 30, 2024 at 5:47 PM David Rowley wrote:
> On Mon, 1 Jul 2024 at 12:16, David G. Johnston
> wrote:
> >
> > On Sun, Jun 30, 2024 at 4:55 PM David Rowley
> wrote:
> >>
> >>
> >> I'd like to know what led someone down the path of doing something
> >> like DEFAULT 'now()'::timestamp in a
Hi Tom ,Matthias
Thank you for your explanation.Maybe future compilers will be able to
do intelligent prediction?
Thanks
Tom Lane 于2024年6月30日周日 23:23写道：
> Matthias van de Meent writes:
> > On Sun, 30 Jun 2024, 15:56 wenhui qiu, wrote:
> >> if (unlikely(ExecutorRun_hook)),
>
> > While ho
Thomas Munro writes:
> I don't have any great ideas about what to do about this.
> Cybersquatting system facilities is a messy business, so maybe the
> proposed grotty solution is actually appropriate! We did bring this
> duelling Henry Spencers problem upon ourselves. Longer term,
> pg_regex_t
On Sun, Jun 30, 2024 at 11:23 AM Tom Lane wrote:
> The real win would be if constructs like
>
> if (trouble)
> ereport(ERROR, ...);
>
> could be interpreted as
>
> if (unlikely(trouble))
> ereport(ERROR, ...);
>
> But I surely don't want to make thou
On Mon, 1 Jul 2024 at 14:08, Peter Geoghegan wrote:
>
> On Sun, Jun 30, 2024 at 11:23 AM Tom Lane wrote:
> > if (trouble)
> > ereport(ERROR, ...);
> >
> > could be interpreted as
> >
> > if (unlikely(trouble))
> > ereport(ERROR, ...);
> >
> > But I
On Sun, Jun 30, 2024 at 09:32:57PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sun, Jun 30, 2024 at 05:01:52PM -0400, Tom Lane wrote:
> >> I'm tempted to lobotomize the new test case on Windows until
> >> we have that resolved.
>
> > Sounds fine. The pg_upgrade suite adequately tests appe
On Mon, 1 Jul 2024 at 13:41, David G. Johnston
wrote:
> I presume the relatively new atomic SQL functions pose a similar hazard.
Do you have an example of this?
> The fact that 'now()'::timestamp fails to fail doesn't help...
If that's the case, maybe a tiny step towards what Peter proposed is
On 2024-06-28 21:05, Matthias van de Meent wrote:
> On Fri, 28 Jun 2024 at 10:59, Jelte Fennema-Nio wrote:
>>
>> On Fri, 28 Jun 2024 at 00:41, Peter Geoghegan wrote:
>> > Typically, no, it won't be. But there's really no telling for sure.
>> > The access patterns for a composite index on '(a, b)'
On 2024-06-29 03:27, Peter Geoghegan wrote:
> On Thu, Jun 27, 2024 at 11:06 PM wrote:
>> Although I haven't looked on your patch yet, if it's difficult to know
>> how it can optimize during the planning phase, it's enough for me to just
>> show "Skip Scan Cond (or Non-Key Filter)". This is because
On Sun, Jun 30, 2024 at 7:52 PM David Rowley wrote:
> On Mon, 1 Jul 2024 at 13:41, David G. Johnston
> wrote:
> > I presume the relatively new atomic SQL functions pose a similar hazard.
>
> Do you have an example of this?
>
>
create function testnow() returns timestamptz language sql
return 'no
On Sun, Jun 30, 2024 at 7:52 PM David Rowley wrote:
> If that's the case, maybe a tiny step towards what Peter proposed is
> just to make trailing punctuation fail for timestamp special values in
> v18.
>
>
I'm game. If anyone is using the ambiguous spelling it is probably to their
benefit to hav
Noah Misch writes:
> On Sun, Jun 30, 2024 at 09:32:57PM -0400, Tom Lane wrote:
>> Hmph ... according to [1], 545082091 was not enough to fix this.
>> I guess that old version of IPC::Run also misbehaves for cases
>> involving backslash, single quote, and/or some other special
>> characters?
> The
Hi,
On Fri, Jun 28, 2024 at 08:07:39PM +, Imseih (AWS), Sami wrote:
> > 46ebdfe164 will interrupt the leaders sleep every time a parallel workers
> > reports
> > progress, and we currently don't handle interrupts by restarting the sleep
> > with
> > the remaining time. nanosleep does provide
On Thu, 27 Jun 2024 at 08:38, Amit Kapila wrote:
>
> On Wed, Jun 26, 2024 at 4:57 PM Tomas Vondra
> wrote:
> >
> > On 6/25/24 07:04, Amit Kapila wrote:
> > > On Mon, Jun 24, 2024 at 8:06 PM Tomas Vondra
> > > wrote:
> > >>
> > >> On 6/24/24 12:54, Amit Kapila wrote:
> > >>> ...
> >
> >
On Wed, May 08, 2024 at 10:21:56AM +0900, Michael Paquier wrote:
> Yup, I've looked at that yesterday and the read order remains the same
> so I don't see a need for a version bump.
While looking at this stuff again, I got no objections for it except a
few edits to make the new code more consisten
Hi,
In HEAD, I encountered the following assertion failure when I enabled
summarize_wal
and ran pg_createsubscriber.
2024-07-01 14:42:15.697 JST [19195] LOG: database system is ready to accept
connections
TRAP: failed Assert("switchpoint >= state->EndRecPtr"), File:
"walsummarizer.c", Line:
On Wed, Jun 12, 2024 at 4:22 AM David Christensen
wrote:
> On Mon, Jun 10, 2024 at 8:15 AM Robert Haas wrote:
> >
> > On Mon, Jun 10, 2024 at 3:09 AM Ashutosh Bapat
> > wrote:
> > > This is just one instance of measurements. If I run the experiment
> multiple times the results and the patterns
Hello hackers,
Attached patch introduces an optimization of mul_var() in numeric.c, targeting
cases where the multiplicands consist of only one or two base-NBASE digits.
Such small multiplicands can fit into an int64 and thus be computed directly,
resulting in a significant performance improvem
On Thu, Jun 27, 2024 at 11:27:45AM +0200, Joel Jacobson wrote:
> During work in the separate thread [1], I discovered more cases
> where the link in docs wasn't the canonical link [2].
>
> [1]
> https://postgr.es/m/cakfquwyex9pj9g0zhjewsmsbnquygh+fycw-66ezjfvg4ko...@mail.gmail.com
> [2] https://e
On Mon, Jul 01, 2024 at 02:54:56PM +0900, Fujii Masao wrote:
> In HEAD, I encountered the following assertion failure when I enabled
> summarize_wal
> and ran pg_createsubscriber.
>
> Is this the known issue?
Nope. So, Open Item, here we go.
--
Michael
signature.asc
Description: PGP signature
Dear Amit,
Thanks for giving comments! PSA new version.
> Thanks, this is a better approach. I have changed a few comments and
> made some other cosmetic changes. See attached.
I checked your attached and LGTM. Based on that, I added some changes
like below:
- Made dbname be escaped while listi
Hi,
On Thu, May 23, 2024 at 3:37 PM shveta malik wrote:
>
> DELETE
>
> Conflict Type:
>
> delete_missing: An incoming delete is trying to delete a row on a
> target node which does not exist.
IIUC the 'delete_missing' conflict doesn't cover the case where an
inc
Hi hackers,
While working on a rebase for [1] due to 0cecc908e97, I noticed that
CheckRelationLockedByMe() and CheckRelationOidLockedByMe() are used only in
assertions.
I think it would make sense to declare / define those functions only for
assert enabled build: please find attached a tiny patch
68 matches
Mail list logo
