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 n
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 with
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.
>
> +1
>
> > IIUC we would make the remote apply wait just
> > before co
On Wed, Jul 3, 2024 at 9:21 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Amit,
>
> > IIUC, the problem is that the consistent_lsn value returned by
> > setup_publisher() is the "end +1" location of the required LSN whereas
> > the recovery_target_lsn used in wait_for_end_recovery() expects the
> > L
> On 2 Jul 2024, at 22:20, Tom Lane wrote:
>
> It sure looks like this is exact-to-the-nanosecond results,
> since the modal values match the overall per-loop timing,
> and there are no zero measurements.
That’s a very interesting result, from the UUID POV!
If time is almost always advancing,
On Wed, Jul 3, 2024 at 10:47 AM Dilip Kumar wrote:
>
> On Tue, Jul 2, 2024 at 2:40 PM shveta malik wrote:
> >
> > On Wed, Jun 19, 2024 at 1:52 PM Dilip Kumar wrote:
> > >
> > > On Tue, Jun 18, 2024 at 3:29 PM shveta malik
> > > wrote:
> > > > On Tue, Jun 18, 2024 at 11:34 AM Dilip Kumar
> >
On Tue, Jul 2, 2024 at 2:40 PM shveta malik wrote:
>
> On Wed, Jun 19, 2024 at 1:52 PM Dilip Kumar wrote:
> >
> > On Tue, Jun 18, 2024 at 3:29 PM shveta malik wrote:
> > > On Tue, Jun 18, 2024 at 11:34 AM Dilip Kumar
> > > wrote:
> > >
> > > I tried to work out a few scenarios with this, where
Dear Alexander and other hackers,
> As a recent buildfarm failure [1] shows, that test addition introduced
> new instability:
> ### Starting node "node_s"
> # Running: pg_ctl -w -D
> /home/bf/bf-build/piculet/HEAD/pgsql.build/testrun/pg_basebackup/040_pg_c
> reatesubscriber/data/t_040_pg_createsub
Dear Amit,
> IIUC, the problem is that the consistent_lsn value returned by
> setup_publisher() is the "end +1" location of the required LSN whereas
> the recovery_target_lsn used in wait_for_end_recovery() expects the
> LSN value to be "start" location of required LSN.
Yeah, right. It is same as
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 explaiations for each file file, see
> at
On Tue, Jul 02, 2024 at 02:42:50PM +0300, Heikki Linnakangas wrote:
> On 02/07/2024 02:24, Noah Misch wrote:
> > On Tue, Jul 02, 2024 at 12:53:05AM +0300, Heikki Linnakangas wrote:
> log_newpage_range() loads the pages to the buffer
> cache and dirties them. That kinds of sucks actually, I wish it
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 message for the revert commit, namely, committing this
> > > again early i
On Tue, Jul 2, 2024 at 5:56 AM Tom Lane wrote:
> Done at commit edadeb0710.
Here are some experimental patches to try out some ideas mentioned
upthread, that are approximately unlocked by that cleanup.
1. We could get rid of --disable-spinlocks. It is hard to imagine a
hypothetical new port th
Hello Noah,
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 inplace110-successors-v5.patch:
CREATE TABLE t (i int) PARTITION BY LIS
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 - typo /whethere/whether/
nitpick - reworded slightly using a ChatGPT su
Hi,
The 'cur_skey' parameter in `IndexScanOK` funciton doesn't seem to be useful.
The function does not use cur_skey for any operation. Is there any other
consideration
for retaining the cur_skey parameter here?
Best wishes
Hugo zhang
hi.
the following review is based on v2-0001, v2-0002.
"context_item can be a JSON document passed as a value of type json,
jsonb document, a character or an UTF8- endoded bytea string."
is wrong?
e.g. SELECT JSON_EXISTS( NULL::bytea, 'lax $.a[5]' ERROR ON ERROR)
check following query:
select oid
Hi,
On Tue, Jun 25, 2024 at 1:53 PM jian he wrote:
> On Tue, Jun 25, 2024 at 11:23 AM Amit Langote wrote:
> > > My thoughts for the above cases are:
> > > * json_value, json_query main description is the same:
> > > {{Returns the result of applying the SQL/JSON path_expression to the
> > > cont
On Mon, Jun 24, 2024 at 4:27 AM Heikki Linnakangas wrote:
>
> Would it be possible to make it robust so that we could always run it
> with "make check"? This seems like an important corner case to
> regression test.
Okay, I've attached a new version of the patch and a new version of
the repro tha
On Wed, Jul 03, 2024 at 12:05:09AM +0200, Peter Eisentraut wrote:
> On 02.07.24 18:51, Noah Misch wrote:
> > On Mon, Jul 01, 2024 at 06:19:08PM -0700, Jeff Davis wrote:
> > > On Mon, 2024-07-01 at 16:03 -0700, Noah Misch wrote:
> > > > An alternative would be to make pg_upgrade reject
> > > > op
On Wed, Jul 03, 2024 at 12:31:48AM +0300, Alexander Korotkov wrote:
> On Mon, Jul 1, 2024 at 2:18 AM Noah Misch wrote:
> > Commit e85662d wrote:
> > > --- a/src/backend/storage/ipc/procarray.c
> > > +++ b/src/backend/storage/ipc/procarray.c
> >
> > > @@ -2740,6 +2741,8 @@ GetRunningTransactionData
On 02.07.24 18:51, Noah Misch wrote:
On Mon, Jul 01, 2024 at 06:19:08PM -0700, Jeff Davis wrote:
On Mon, 2024-07-01 at 16:03 -0700, Noah Misch wrote:
An alternative would be to make pg_upgrade reject
operating on a cluster that contains use of $SUBJECT.
That wouldn't help anyone.
Can you
On 02.07.24 16:14, Tom Lane wrote:
Peter Eisentraut writes:
I had to revert the test case from the 0002 patch. It ended up running
some build farm machines out of memory.
That ties into what I said upthread: why are we involving MaxAllocSize
in this at all? The maximum parameter number you
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 change
to get to a seqscan.
> It almost feels like we should h
On 02/07/2024 22:54, Robert Haas wrote:
On Tue, Jul 2, 2024 at 3:36 PM Tom Lane wrote:
One could argue for other things, of course. And maybe those other
things are fine, if they're properly justified and documented.
[ shrug... ] This isn't a hill that I'm prepared to die on.
But I see no go
On Thu, Jun 27, 2024 at 6:32 PM Thomas Munro wrote:
> So I think we should request
> ghcr.io/cirruslabs/macos-sonoma-base:latest. Personal github accounts
> will use macos-runner:sonoma instead, but at least it's the same OS
> release. Here's a new version like that, to see if cfbot likes it.
T
On Mon, Jul 1, 2024 at 2:18 AM Noah Misch wrote:
> 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
Robert Haas writes:
> Well, I don't really know where to go from here. I mean, I think that
> three committers (David, Heikki, yourself) have expressed some
> concerns about changing the behavior. So maybe we shouldn't. But I
> don't understand how it's reasonable to have two very similarly named
Hi Robert,
I loved this initiative. Please allow me to introduce myself: I have been
using Postgres for 10 years both as a backend developer connecting to a
Postgres cluster, a DBA, and also I studied thoroughly the code of Postgres
and some plugins. I'm currently working on an ambitious plan to h
On Tue, Jul 2, 2024, at 22:10, Joel Jacobson wrote:
> * v4-optimize-numeric-mul_var-small-var1-arbitrary-var2.patch
Instead of these boundary checks, maybe it would be cleaner to just
skip this optimization if there are too few res_ndigits?
/Joel
On Tue, Jul 2, 2024, at 21:55, Joel Jacobson wrote:
> On Tue, Jul 2, 2024, at 20:53, Joel Jacobson wrote:
>> Trying to wrap my head around what could cause this.
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
I'll give it a shot.
On Mon, Jul 1, 2024 at 4:16 PM Kirill Reshke wrote:
> > Postgres 17
> 18
>
>
>
Hi,
I've now sent acceptance and rejection emails to, I believe, all
applicants. If you applied and didn't get an email, let me know.
For those who may be interested in the statistics, I received 34
applications. Although I initially anticipated being unable to accept
more than 9, because we had
On Tue, Jul 2, 2024, at 20:53, Joel Jacobson wrote:
> Trying to wrap my head around what could cause this.
>
> It's rounding down instead of up, and these cases all end with decimal
> .500.
Interesting, I actually think there is a bug in the normal mul_var() code.
Found a case that rounds dow
On Tue, Jul 2, 2024 at 3:36 PM Tom Lane wrote:
> > One could argue for other things, of course. And maybe those other
> > things are fine, if they're properly justified and documented.
>
> [ shrug... ] This isn't a hill that I'm prepared to die on.
> But I see no good reason to change the very lo
Robert Haas writes:
> What the patch does is: if you set either enable_indexscan=false or
> enable_indexonlyscan=false, then the corresponding path type is not
> generated, and the other is unaffected. To me, that seems like the
> logical way to clean this up.
> One could argue for other things,
On Tue, Jul 2, 2024 at 2:37 PM Tom Lane wrote:
> Robert Haas writes:
> > What happens right now is:
>
> > - If you set enable_indexscan=false, then disable_cost is added to the
> > cost of index scan paths and the cost of index-only scan paths.
>
> > - If you set enable_indexonlyscan=false, then
On Tue, Jul 2, 2024, at 18:20, Joel Jacobson wrote:
> * v3-optimize-numeric-mul_var-small-var1-arbitrary-var2.patch
Hmm, v3 contains a bug which I haven't been able to solve yet.
Reporting now to avoid time waste reviewing it since it's buggy.
The attached patch is how I tested and found the bug.
Robert Haas writes:
> What happens right now is:
> - If you set enable_indexscan=false, then disable_cost is added to the
> cost of index scan paths and the cost of index-only scan paths.
> - If you set enable_indexonlyscan=false, then index-only scan paths
> are not generated at all.
Hm. The
Hannu Krosing writes:
> At least "does it run" tests should be there -
> For example with the current toolchain on MacOS I was able to compile
> __builtin_readcyclecounter(); but it crashed when the result was
> executed.
> The same code compiled *and run* fine on same laptop with Ubuntu 24.04
On Tue, Jul 2, 2024 at 7:50 PM Tom Lane wrote:
>
> > Do we also need tests for this one ?
>
> Yeah, it was annoying me that we are eating the overhead of a TAP test
> for pg_test_timing and yet it covers barely a third of the code [1].
> We obviously can't expect any specific numbers out of a tes
Nathan Bossart writes:
> We could also add a GOVERNANCE.md file that points to the new
> https://www.postgresql.org/about/governance/ page, but I couldn't find
> where that gets displayed on GitHub, so AFAICT it would just be buried in
> .github/.
Not much point then. IMV this subdirectory is ju
On Mon, Jun 03, 2024 at 10:10:58AM -0500, Nathan Bossart wrote:
> Tom, Alvaro, and Peter have all expressed a preference to use the .github/
> directory, so at the moment I still intend to proceed with the v3 patch
> unless further discussion changes things.
Committed.
We could also add a GOVERNA
On Tue, Jul 2, 2024 at 1:40 PM Tom Lane wrote:
> FWIW, I disagree completely. I think it's entirely natural to
> consider bitmap index scans to be a subset of index scans, so that
> enable_indexscan should affect both. I admit that the current set
> of GUCs doesn't let you force a bitmap scan ov
Hannu Krosing writes:
> Also, reading directly in ticks on M1 gave "loop time including
> overhead: 2.13 ns" (attached code works on Clang, not sure about GCC)
I don't think we should mess with that, given the portability
problems you mentioned upthread.
> I'll also take a look at the docs and t
Robert Haas writes:
> On Tue, Jul 2, 2024 at 10:57 AM Heikki Linnakangas wrote:
>> I fear this will break people's applications, if they are currently
>> forcing a sequential scan with "set enable_indexscan=off". Now they will
>> need to do "set enable_indexscan=off; set enable_indexonlyscan=off"
Hi.
This is a series of patches to change styles, in assorted sources.
IMO, this improves a tiny bit and is worth trying.
1. Avoid dereference iss_SortSupport if it has nulls.
2. Avoid dereference plan_node_id if no dsm area.
3. Avoid dereference spill partitions if zero ntuples.
4. Avoid possibl
Also the step on M1 is slightly above 40ns (41.7ns) , but exactly 40
ns on Ampere Altra.
## M1 on MacBooc Air
Testing timing overhead for 3 seconds.
Total 24000177 ticks in 100056 ns, 24000175.655990 ticks per ns
This CPU is running at 24000175 ticks / second, will run test for 72000525 ticks
Hi Tom,
On various Intel CPUs I got either steps close to single nanosecond or
sometimes a little more on older ones
One specific CPU moved in in 2 tick increments while the ration to ns
was 2,1/1 or 2100 ticks per microsecond.
On Zen4 AMD the step seems to be 10 ns, even though the tick-to-ns
Thanks for the review!
On Tue, Jul 2, 2024 at 10:57 AM Heikki Linnakangas wrote:
> v3-0001-Remove-grotty-use-of-disable_cost-for-TID-scan-pl.patch:
>
> +1, this seems ready for commit
Cool.
> v3-0002-Rationalize-behavior-of-enable_indexscan-and-enab.patch:
>
> I fear this will break people's ap
BTW, getting back to the original point of the thread: I duplicated
Hannu's result showing that on Apple M1 the clock tick seems to be
about 40ns. But look at what I got with the v2 patch on my main
workstation (full output attached):
$ ./pg_test_timing
...
Per loop time including overhead: 16.60
On 10/05/2024 05:58, Xing Guo wrote:
On Thu, May 9, 2024 at 11:19 PM Tom Lane wrote:
Heikki Linnakangas writes:
At first I was sure this was introduced by my refactorings in v17, but
in fact it's been like this forever. I agree that InitProcessing makes
much more sense. The ProcessingMode va
On Tue, Jul 2, 2024 at 12:55 PM Peter Geoghegan wrote:
> Although v2 gives correct answers to the queries, the scan itself
> performs an excessive amount of leaf page accesses. In short, it
> behaves just like a full index scan would, even though we should
> expect it to skip over significant runs
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 discussed in [1], and feel it would be useful when loading
'dirty' data but
On Tue, Jul 2, 2024 at 12:25 PM Peter Geoghegan wrote:
> Attached v2 fixes this bug. The problem was that the skip support
> function used by the "char" opclass assumed signed char comparisons,
> even though the authoritative B-Tree comparator (support function 1)
> uses signed comparisons (via ui
I wrote:
> Hannu Krosing writes:
>> This is my current patch which also adds running % and optionally uses
>> faster way to count leading zeros, though I did not see a change from
>> that.
> I've not read the patch yet, but I did create a CF entry [1]
> to get some CI cycles on this. The cfbot
On Mon, Jul 01, 2024 at 06:19:08PM -0700, Jeff Davis wrote:
> On Mon, 2024-07-01 at 16:03 -0700, Noah Misch wrote:
> > An alternative would be to make pg_upgrade reject
> > operating on a cluster that contains use of $SUBJECT.
>
> That wouldn't help anyone.
Can you say more about that? For the
Hackers,
In fuzing around trying to work out what’s going on with the formatting of
timestamptz values cast by the timestamp_tz() jsonpath method[1], I noticed
that the formatting of the string() method applied to date and time objects was
not fully tested, or how the output is determined by th
Committed.
--
nathan
On Tue, Jul 2, 2024, at 13:44, Dean Rasheed wrote:
>> Can you think of an example that should trigger the bug?
>
> .0001 * 5000._ with rscale = 0 triggers it (returned
> 50004999 instead of 50005000).
Thanks, helpful.
Attached patch adds the var1ndigits=3 case.
Benchmark:
/*
* Appl
Hi,
This is a PoC that implements XMLCast (SQL/XML X025), which enables
conversions between SQL and XML data type.
It basically does the following:
* When casting an XML value to a SQL data type, XML values containing
XSD literals will be converted to their equivalent SQL data type.
* When casti
Andrew Dunstan writes:
> On 2024-07-02 Tu 8:55 AM, Dagfinn Ilmari Mannsåker wrote:
>> Relatedly, I also had a look at prohibiting unused regex captures
>> (RegularExpressions::ProhibitUnusedCapture), which found a few real
>> cases, but also lots of false positives in Catalog.pm, because it
>> do
On 7/2/24 02:07, Andy Fan wrote:
> Tomas Vondra writes:
>
> Hi Tomas,
>
> I am in a incompleted review process but I probably doesn't have much
> time on this because of my internal tasks. So I just shared what I
> did and the non-good-result patch.
>
> What I tried to do is:
> 1) remove all th
On 2024-07-02 Tu 8:55 AM, Dagfinn Ilmari Mannsåker wrote:
Relatedly, I also had a look at prohibiting unused regex captures
(RegularExpressions::ProhibitUnusedCapture), which found a few real
cases, but also lots of false positives in Catalog.pm, because it
doesn't understand that %+ uses all na
On 28/06/2024 18:46, Robert Haas wrote:
On Wed, Jun 12, 2024 at 11:35 AM Robert Haas wrote:
Well, that didn't generate much discussion, but here I am trying
again. Here I've got patches 0001 and 0002 from my previous posting;
I've dropped 0003 and 0004 from the previous set for now so as not to
On 2024-Jul-02, Andres Freund wrote:
> On 2024-07-01 21:12:25 +0200, Alvaro Herrera wrote:
> > On 2024-Jul-01, Andres Freund wrote:
> > I'm pretty sure the Microsoft docs I linked to are saying it must be
> > aligned.
>
> I don't think so:
> https://learn.microsoft.com/en-us/windows/win32/api/wi
On Jul 1, 2024, at 11:02, David E. Wheeler wrote:
> Anyway, should the output of timestamptz JSONB values be made more
> consistent? I’m happy to make a patch to do so, but could use a hand figuring
> out where the behavior varies.
I think if the formatting was more consistent, the test output
Erik Wienhold writes:
> On 2024-07-02 10:45 +0200, Peter Eisentraut wrote:
>> I had to revert the test case from the 0002 patch. It ended up running some
>> build farm machines out of memory.
>> +ERROR: out of memory
>> +DETAIL: Failed on request of size 1073741820 in memory context
>> "Porta
Peter Eisentraut writes:
> I had to revert the test case from the 0002 patch. It ended up running
> some build farm machines out of memory.
That ties into what I said upthread: why are we involving MaxAllocSize
in this at all? The maximum parameter number you can actually use in
extended queri
> On 2 Jul 2024, at 15:58, Erik Wienhold wrote:
> On 2024-07-02 14:27 +0200, Daniel Gustafsson wrote:
>> Considering the runway we typically give for deprecations, that seems like a
>> fairly short timeframe for a SQL level command which isn't unlikely to exist
>> in application code.
>
> Is ther
I wrote:
> Patch 0002 deprecates CREATE MATERIALIZED VIEW IF NOT EXISTS because it
> no longer seems necessary with patch 0001. Tom Lane commented[1] about
> the general dislike of IF NOT EXISTS, to which I agree, but maybe this
> was meant only in response to adding new commands.
One could also
On Tue, Jul 2, 2024 at 9:30 AM Peter Geoghegan wrote:
> > EXPLAIN [ANALYZE] SELECT COUNT(*) FROM test1 WHERE n > 900_000_000;
>
> For example, this first test query goes from needing a full index scan
> that has 5056 buffer hits to a skip scan that requires only 12 buffer
> hits.
Actually, looks
On 18/04/2024 23:29, Thomas Munro wrote:
On Thu, Apr 18, 2024 at 8:47 PM Peter Eisentraut wrote:
I'm not sure I understand the problem here. Do you mean that in theory
a platform's PRId64 could be something other than "l" or "ll"?
Yes. I don't know why anyone would do that, and the systems
On Tue, Jul 2, 2024 at 8:53 AM Aleksander Alekseev
wrote:
> CREATE TABLE test1(c char, n bigint);
> CREATE INDEX test1_idx ON test1 USING btree(c,n);
The type "char" (note the quotes) is different from char(1). It just
so happens that v1 has support for skipping attributes that use the
default op
Hi hackers,
David Rowley , 4 Nis 2024 Per, 04:44 tarihinde şunu
yazdı:
> My view on this is that there are a couple of things with the patch
> which could be considered separately:
>
> 1. Should we have a context_id in the view?
> 2. Should we also have an array of all parents?
>
I discussed the
On 28/06/2024 01:01, Paul Jungwirth wrote:
If it seems good to let people use SupportRequestSimplify to make their SRFs be
inlineable, I'm
happy to add tests and docs. We should really document the idea of inlined
functions in general, so
I'll do that too.
Another approach I considered is usin
Michael Paquier writes:
> On Fri, May 24, 2024 at 02:09:49PM +0900, Michael Paquier wrote:
>> For now, I have staged for commit the attached, that handles most of
>> the changes from Alexander (msvc could go for more cleanup?).
>
> This one has been applied as of 0c1aca461481 now that v18 is
> op
Hi Peter,
> Attached is a POC patch that adds skip scan to nbtree. The patch
> teaches nbtree index scans to efficiently use a composite index on
> '(a, b)' for queries with a predicate such as "WHERE b = 5". This is
> feasible in cases where the total number of distinct values in the
> column 'a'
On Fri, Jun 28, 2024 at 2:56 PM Amit Langote wrote:
> On Tue, Jun 25, 2024 at 3:47 PM David G. Johnston
> wrote:
> >
> > Hey!
> >
> > Lots of SQL/JSON threads going about. This one is less about technical
> > correctness and more about usability of the documentation. Though in
> > writing this
> On 2 Jul 2024, at 03:22, Erik Wienhold wrote:
> Patch 0002 deprecates CREATE MATERIALIZED VIEW IF NOT EXISTS because it
> no longer seems necessary with patch 0001. Tom Lane commented[1] about
> the general dislike of IF NOT EXISTS, to which I agree, but maybe this
> was meant only in response
On Mon, Jul 1, 2024 at 8:22 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > 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 of line
> > (for comparison, 010_pg_baseb
On Fri, 31 May 2024 at 05:26, David Rowley wrote:
>
> On Sat, 4 May 2024 at 03:51, Matthias van de Meent
> wrote:
> >
> > On Fri, 3 May 2024 at 15:55, David Rowley wrote:
> > > master @ 8f0a97dff
> > > Storage: Memory Maximum Storage: 16577kB
> > >
> > > patched:
> > > Storage: Memory Maximum
Hi,
On 2024-07-01 21:12:25 +0200, Alvaro Herrera wrote:
> On 2024-Jul-01, Andres Freund wrote:
>
> > On 2024-07-01 11:10:24 +0200, Alvaro Herrera wrote:
> > > In the meantime I noticed that pg_attribute_aligned() is not supported
> > > in every platform/compiler, so for safety sake I think it's b
Hello hackers,
25.05.2024 15:00, I wrote:
I've created such page to accumulate information on test failures:
https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures
One month later, I'd like to summarize failures that I've investigated
and classified during June, 2024 on the aforement
On 2024-Jul-01, Alvaro Herrera wrote:
> On 2024-Jul-01, Andres Freund wrote:
>
> > On 2024-07-01 11:10:24 +0200, Alvaro Herrera wrote:
> > > In the meantime I noticed that pg_attribute_aligned() is not supported
> > > in every platform/compiler, so for safety sake I think it's better to go
> > >
Em qui., 18 de abr. de 2024 às 14:43, Ranier Vilela
escreveu:
>
>
> Em qui., 18 de abr. de 2024 às 14:16, Andres Freund
> escreveu:
>
>> Hi,
>>
>> On 2024-04-18 09:07:43 -0300, Ranier Vilela wrote:
>> > On 18/04/2024 00:39, Andres Freund wrote:
>> > >There are lots of places that could benefit
On Tue, 2 Jul 2024 at 11:23, Joel Jacobson wrote:
>
> Just to be able to verify mul_var() is working as expected when
> rscale is less than the full result, I've added a numeric_mul_patched()
> function that takes a third rscale_adjustment parameter:
Yeah, we could expose such a function, and may
On 02/07/2024 02:24, Noah Misch wrote:
On Tue, Jul 02, 2024 at 12:53:05AM +0300, Heikki Linnakangas wrote:
On 01/07/2024 23:52, Noah Misch wrote:
Commit 8af2565 wrote:
--- /dev/null
+++ b/src/backend/storage/smgr/bulk_write.c
+/*
+ * Finish bulk write operation.
+ *
+ * This WAL-logs and fl
Em ter., 2 de jul. de 2024 às 06:44, Daniel Gustafsson
escreveu:
> > On 2 Jul 2024, at 02:33, Michael Paquier wrote:
> >
> > On Mon, Jul 01, 2024 at 09:19:59PM +0200, Daniel Gustafsson wrote:
> >>> The bit I don't understand about this discussion is what will happen
> >>> with users that current
Hi,
> Patch 0002 deprecates CREATE MATERIALIZED VIEW IF NOT EXISTS because it
> no longer seems necessary with patch 0001. Tom Lane commented[1] about
> the general dislike of IF NOT EXISTS, to which I agree, but maybe this
> was meant only in response to adding new commands. Anyway, my idea is
On Tue, Jun 25, 2024, at 09:13, Joel Jacobson wrote:
> Attachments:
> * v8-0001-Add-pg_get_acl.patch
Rebased version.
Uses ACL acronym added in commit 00d819d46a6f5b7e9d2e02948a1c80d11c4ce260:
doc: Add ACL acronym for "Access Control List"
/Joel
v9-0001-Add-pg_get_acl.patch
Description: Bina
Hello there,
The test src/test/modules/test_extensions/sql/test_extensions.sql don't
pass during make installcheck on the builds with ICU support (configure
--with-icu) and with database created with this one's locale provider
(initdb --locale-provider=icu --icu-locale=en-US).
A root cause i
On Tue, Jul 2, 2024, at 11:05, Joel Jacobson wrote:
> On Tue, Jul 2, 2024, at 10:22, Dean Rasheed wrote:
>> Shortly after posting that, I realised that there was a small bug. This bit:
>>
>> case 2:
>> newdig = (int) var1digits[1] * var2digits[res_ndigits - 4];
>>
>> isn
Hi Andy
On 08.06.24 08:05, Andy Fan wrote:
> Here is a new function which could produce an array of numbers with a
> controllable array length and duplicated elements in these arrays. I
> used it when working with gin index, and I think it would be helpful for
> others as well, so here it is.
>
>
On Tue, Jul 2, 2024 at 9:57 AM Shlok Kyal wrote:
>
> On Mon, 1 Jul 2024 at 11:44, Hayato Kuroda (Fujitsu)
> wrote:
> >
> > 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
> On 2 Jul 2024, at 02:33, Michael Paquier wrote:
>
> On Mon, Jul 01, 2024 at 09:19:59PM +0200, Daniel Gustafsson wrote:
>>> The bit I don't understand about this discussion is what will happen
>>> with users that currently have exactly 1024 chars in backup names today.
>>> With this change, we'l
On Sun, 30 Jun 2024 at 11:22, Joel Jacobson wrote:
>
> On Sat, Jun 29, 2024, at 14:22, Dean Rasheed wrote:
>
> > But why just split it into two pieces? That will just lead
> > to a lot of unnecessary recursion for very unbalanced inputs. Instead,
> > why not split the longer input into N roughly e
On 2024-07-02 10:45 +0200, Peter Eisentraut wrote:
> On 02.07.24 10:14, Peter Eisentraut wrote:
> > I have committed your two v4 patches.
>
> I had to revert the test case from the 0002 patch. It ended up running some
> build farm machines out of memory.
dhole, morepork, and schnauzer. For exam
On Sun, 30 Jun 2024 at 11:22, Joel Jacobson wrote:
>
> The surprising realization here is that there are actually (var1ndigits,
> var2ndigits)
> combinations where *only* doing mul_var_karatsuba_half() recursively
> all the way down to schoolbook *is* a performance win,
> even though we don't do
1 - 100 of 114 matches
Mail list logo
