On Fri, Jul 12, 2024 at 4:54 AM Euler Taveira wrote:
>
> On Thu, Jul 11, 2024, at 2:00 PM, Alexander Lakhin wrote:
>
> May I ask you to look at another failure of the test occurred today [1]?
>
>
> Thanks for the report!
>
> You are observing the same issue that Amit explained in [1]. The
> pg_cre
On Mon, Apr 29, 2024 at 1:17 PM Corey Huinker wrote:
>>
>> I've splitted it to7 patches.
>> each patch split one into separate new files.
>
>
> Seems like a good start. Looking at the diffs of these, I wonder if we would
> be better off with a func/ directory, each function gets its own file in
On 2024/07/15 14:00, Fujii Masao wrote:
Attached patch fixes unstable tests. Currently testing before pushing.
I pushed the patch at commit 4e5d6c4091, and some buildfarm animals
are back to green, but crake still reported an error. At first glance,
the error messages don't seem related to t
On 7/15/24 12:31, jian he wrote:
hi.
Here is the latest patch (v6),
I've made the following changes.
* disallow original Query->resultRelation participate in SJE.
for SELECT, nothing is changed. for UPDATE/DELETE/MERGE
we can do:
EXPLAIN (COSTS OFF)
UPDATE sj sq SET b = sq.b + sz.a FROM (select
On Fri, Jul 12, 2024 at 11:59 AM Ashutosh Bapat
wrote:
>
>
> Now that you are also seeing the slowdown with your earlier patch, I
> am wondering whether adding unlikely() by itself is a good
> optimization. There might be some other reason behind the perceived
> slowdown. How do the numbers look w
In [1], it is suggested that it might be a good idea to support
specifying the tablespace for each merged/split partition.
We can do the following after this feature is supported:
CREATE TABLESPACE tblspc LOCATION '/tmp/tblspc';
CREATE TABLE t (i int PRIMARY KEY) PARTITION BY RANGE (i);
CREATE TA
On 2024-04-03 Wn 04:21, Andrew Dunstan
> I don't think a cast that doesn't cater for all the forms json can take is
> going to work very well. At the very least you would need to error out in
> cases you didn't want to cover, and have tests for all of those errors. But
> the above is only a tiny f
Thanks for the patch!
I was not able to understand why we need a special error table for COPY?
Can't we just log it in a new log error file for COPY in a proper format?
Like
using table approach, PG would be unnecessarily be utilising its resources
like
extra CPU to format the data in pages to sto
Hi, I had a quick look at the patch v17-0004 which is the split-off
new BMS logic.
IIUC this 0004 is currently undergoing some refactoring and
cleaning-up, so I won't comment much about it except to give the
following observation below.
==
src/backend/replication/logical/proto.c.
I did not e
>
> Hello all.
>
> I have decided to explore more areas in which I can optimize and have added
> two new benchmarks. Do you have any thoughts on this?
>
> postgres=# select bench_int16_sort(100);
> bench_int16_sort
>
>
> --
On 2024/07/15 13:33, Fujii Masao wrote:
On 2024/07/12 21:17, Masahiko Sawada wrote:
On Thu, Jul 11, 2024 at 8:14 PM Fujii Masao wrote:
On 2024/07/10 22:35, Masahiko Sawada wrote:
BTW the new regression tests don't check the table and index names.
Isn't it better to show table and index
On Thu, Jul 11, 2024 at 4:35 PM cca5507 wrote:
>
> Thank you for review!
>
> The commitfest link for tracking:
> https://commitfest.postgresql.org/49/5121/
>
I've pushed and closed the CF entry.
--
With Regards,
Amit Kapila.
On 2024/07/12 21:17, Masahiko Sawada wrote:
On Thu, Jul 11, 2024 at 8:14 PM Fujii Masao wrote:
On 2024/07/10 22:35, Masahiko Sawada wrote:
BTW the new regression tests don't check the table and index names.
Isn't it better to show table and index names for better
diagnosability?
Sounds
On Fri, Jul 12, 2024 at 11:43 PM Noah Misch wrote:
> On Sat, May 18, 2024 at 05:29:12PM +1200, Thomas Munro wrote:
> > On Fri, May 17, 2024 at 4:46 PM Thomas Munro wrote:
> > > The specific problem here is that LocalProcessControlFile() runs in
> > > every launched child for EXEC_BACKEND builds.
On Mon, Jul 8, 2024 at 2:49 AM Noah Misch wrote:
> what is the scope of the review you seek?
The patch "Refactor tidstore.c memory management." could definitely
use some review. I wasn't sure if that should be proposed in a new
thread of its own, but then the need for it comes from this
streamif
On Thu, Jul 4, 2024 at 9:26 PM Heikki Linnakangas wrote:
> On 15/04/2024 04:20, Thomas Munro wrote:
> > I was grepping for iovec users and noticed that the shm_mq stuff
> > defines its own iovec struct. Is there any reason not to use the
> > standard one, now that we can? Will add to next commit
On 2024/07/12 1:16, Robert Haas wrote:
On Thu, Jul 11, 2024 at 6:51 AM Fujii Masao wrote:
It looks like the fast_forward field in WalSummarizerData is no longer
necessary.
So far, I haven't found any other issues with the patch.
Thanks for reviewing. Regarding fast_forward, I think I had
FWIW, in addition to fixing wrong result issues for queries with
grouping sets, the changes in 0001 also improve performance for
queries that have subqueries in the grouping expressions, because
different instances of the same subquery would need to be executed
only once. As a simple example, cons
Hi, here are some review comments about patch v17-0003
==
1.
Missing a docs change?
Previously, (v16-0002) the patch included a change to
doc/src/sgml/protocol.sgml like below to say STORED generated instead
of just generated.
-Boolean option to enable generated columns. Thi
On Thu, Jul 11, 2024 at 5:18 PM Richard Guo wrote:
> Attached is an updated version of this patch.
I've pushed this patch. Thanks for all the reviews.
Thanks
Richard
Thanks to Kyotaro for the review. And thanks to Ivan for the patch
revision. I made another revision of the patch.
On Tue, Jul 9, 2024 at 12:51 PM Kartyshov Ivan
wrote:
> Thank you for your interest in the patch.
>
> On 2024-06-20 11:30, Kyotaro Horiguchi wrote:
> > Hi, I looked through the pat
On Fri, Jul 12, 2024 at 11:19:05AM -0500, Nathan Bossart wrote:
> I suppose it would be silly to allow even lower values for
> autovacuum_naptime (e.g., by moving it to ConfigureNamesReal and setting
> the minimum to 0.1).
I've thought about that as well, and did not mention it as this would
encou
On Fri, Jul 12, 2024 at 11:17:25PM +0100, Ilya Gladyshev wrote:
> Sure, created a separate thread [1]. Please disregard the second patch in
> this thread. Duplicating the last version of the relevant patch here to
> avoid any confusion.
>
> [1]
> https://www.postgresql.org/message-id/b72f2d89-820
Hi Tomas!
Thank you so much for your interest in the patchset.
> On 10 Jul 2024, at 19:01, Tomas Vondra wrote:
>
> I realized amcheck GIN/GiST support would be useful for testing my
> patches adding parallel builds for these index types, so I decided to
> take a look at this and do an initial r
Hello, everyone!
While reviewing [1], I noticed that check_exclusion_or_unique_constraint
occasionally returns false negatives for btree unique indexes during UPSERT
operations.
Although this doesn't cause any real issues with INSERT ON CONFLICT, I
wanted to bring it to your attention, as it might
On Thu, Jul 04, 2024 at 03:08:16PM -0700, Noah Misch wrote:
> On Thu, Jul 04, 2024 at 08:00:00AM +0300, Alexander Lakhin wrote:
> > 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 fal
Hello Daniel and Michael,
12.07.2024 23:41, Daniel Gustafsson wrote:
On 10 Jul 2024, at 06:42, Michael Paquier wrote:
The rest mentioned upthread seems either not worth the effort or are likely to
be bugs warranting proper investigation.
I've filed a bug report about the "WITH RECURSIVE" an
Peter Eisentraut writes:
> On 04.07.24 03:55, Thomas Munro wrote:
>>> Personally, I find "PRId64" pretty unreadable. "INT64_MODIFIER" wasn't
>>> nice either, though, and following standards is good, so I'm sure I'll
>>> get used to it.
> Using PRId64 would be very beneficial because gettext under
On 04.07.24 03:55, Thomas Munro wrote:
Unfortunately, that theory turned out to be wrong. The usual suspect,
Windows, uses something else: "I64" or something like that. We could
teach our snprintf to grok that, but I don't like the idea anymore.
So let's go back to INT64_MODIFIER, with just a s
On 12.07.24 21:42, Daniel Gustafsson wrote:
On 11 Jul 2024, at 23:22, Peter Eisentraut wrote:
The 0001 patch removes the functions pgtls_init_library() and pgtls_init() but
keeps the declarations in libpq-int.h. This should be fixed.
Ah, nice catch. Done in the attached rebase.
This pat
30 matches
Mail list logo
