On Sat, 20 Jul 2024 at 00:03, Robert Haas wrote:
>
> On Tue, Jul 16, 2024 at 8:04 AM Yasir wrote:
> > Please ignore the above 4 lines in my review. See my comments in blue.
>
> OK, so I think it's unclear what the next steps are for this patch.
>
> 1. On June 3rd, Michael Paquier said that Tom La
On Wed, Mar 26, 2025 at 9:11 PM cca5507 wrote:
>
> Hi,
>
> Thanks for the comments!
>
> Here are the new version patches, I think it will be more clear.
>
> --
+{
+/*
+ * Note that during or after BUILDING_SNAPSHOT, we need handle the xlog
+ * that might mark a transac
Dear Amit, Bertrand,
> Seeing all these failures, I wonder whether we can reliably test
> active slots apart from wal_level change test (aka Scenario 6:
> incorrect wal_level on primary.).
Hmm, agreed. We do not have good solution to stabilize tests, at least for now.
I've created a patch for PG1
Re: Peter Eisentraut
> Moreover, if there are zero-based months, why not zero-based days,
> or any of the other fields?
I would suspect this is coming from C's struct tm where tm_mon is
0..11 and all other fields being "normal". Used by asctime(), gmtime()
and friends.
Christoph
On Wed, Mar 26, 2025 at 11:10 AM David G. Johnston
wrote:
> I'm willing to say "I don't know why this is so very important to Nikolay,
> but I trust him that it is, and since my opinion isn't that strong and this
> isn't a big deal, so I will accommodate the person screaming that adding this
>
Christoph Berg writes:
> Re: Peter Eisentraut
>> Moreover, if there are zero-based months, why not zero-based days,
>> or any of the other fields?
> I would suspect this is coming from C's struct tm where tm_mon is
> 0..11 and all other fields being "normal". Used by asctime(), gmtime()
> and fri
On Wed, Mar 26, 2025 at 10:40 AM Nikolay Shaplov wrote:
> Then please, listen to a reason. If we add isset_offset, it will make code
> inconsistent, because it follow same purpose as unreachable default_value in
> other non boolean options. Having two conflicting ways to do same thing is a
> bad d
> On 26 Mar 2025, at 07:41, Richard Guo wrote:
> I plan to go ahead and push Kevin's fix, barring any objections.
Thanks for picking this up, I had missed this thread.
--
Daniel Gustafsson
Hi,
Working on improving partition pruning [1] I found a case that I may
treat like a bug. I mean the case with expression on a partitioning
column like:
id = ARRAY[$1,$2]
Basically, pruning on ARRAY[$1,$2] works in the case of single column
(see correct-pruning-example.sql in attachment):
Daniel Gustafsson writes:
> Thanks for review! Pushed after making the above changes and taking it for
> another CI run.
CF entry should be marked closed no?
https://commitfest.postgresql.org/patch/5060/
regards, tom lane
> On 26 Mar 2025, at 17:15, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> Thanks for review! Pushed after making the above changes and taking it for
>> another CI run.
>
> CF entry should be marked closed no?
Yep, just wanted to allow some time to see how the buildfarm liked it before
clos
Hi!
Vladlen, I've checked your example and also got this behavior
on the current master under Gdb (Ubuntu 22.04 LTS).
On the query above server waits in this state (as shown by gdb):
Program received signal SIGUSR1, User defined signal 1.
0x562beb21c6ed in ExecInterpExpr (state=0x562bec781858
Hello PostgreSQL Developers,
My name is Kruti Popat, and I am an IT engineering student interested in
contributing to PostgreSQL for GSoC 2025.
I am comfortable with C, C++, and have a basic understanding of PostgreSQL.
I am eager to explore database internals and open-source development. While
I
Dear PostgreSQL Hackers,
This patch modifies the instr_time.h header to prefer CLOCK_MONOTONIC_COARSE
when available. By using CLOCK_MONOTONIC_COARSE, we can leverage a lower
resolution(4ms) but faster alternative for timing operations, which reduces
the overhead of frequent timestamp retrievals.
On Thu, Feb 27, 2025 at 4:12 PM Robert Haas wrote:
> On Thu, Feb 27, 2025 at 4:08 PM Tom Lane wrote:
> > I was down on it to start with, on the grounds that it wasn't adding
> > enough ease-of-use to justify even a relatively small amount of added
> > code. I'm not sure that the dump-reload fail
On Wed, Mar 26, 2025 at 1:29 PM Nikolay Shaplov wrote:
> > What I'm upset about is that it feels to me like Nikolay is trying to
> > win the argument by yelling.
>
> I do not think it is fair. When votes are against you (and I did not ask
> anybody else's help for it) it turned out, that I am yell
This reflects the correct insertion of 100 million rows instead of 10
million.
-- Create table and insert 100 million rows
CREATE TABLE t1(a int);
INSERT INTO t1 SELECT * FROM generate_series(1, 1);
-- close parallel
SET max_parallel_workers_per_gather = 0;
SET max_parallel_workers =
Hi,
On 2025-03-26 21:53:35 +0700, Vladlen Popolitov wrote:
> During debug session I found, that queries with Parallel Seq Scan hang
> in the current master - the leader worker waits indefinitely the signal
> from parallel workers. A query is not possible to break, the leader
> does not check inter
> On 26 Mar 2025, at 10:12, Pavel Stehule wrote:
> yes, it is ok after this change
Thanks for confirming, committed.
--
Daniel Gustafsson
在 2025/3/26 16:37, Kirill Reshke 写道:
On Wed, 26 Mar 2025 at 12:17, Steven Niu wrote:
Hi,
Hi!
This double scanning can be inefficient, especially for large inputs.
So I optimized the function to eliminate the need for two scans,
while preserving correctness and efficiency.
While the arg
On Wed, Mar 26, 2025 at 03:30:49PM +0100, Álvaro Herrera wrote:
> On 2025-Mar-26, David G. Johnston wrote:
>> The argument being made is that the enum patch adheres to established
>> practices; and when adding new code that new code is encouraged to adhere
>> to how existing code is written. A vot
В письме от среда, 26 марта 2025 г. 16:52:09 MSK пользователь Robert Haas
написал:
> But we also decide things by providing reasons that other people can
> engage with intellectually, and I still say you're not really doing
> that. You're just saying you like X better than Y, but without really
>
On Wed, Mar 26, 2025 at 7:42 AM Robert Haas wrote:
> On Wed, Mar 26, 2025 at 10:17 AM David G. Johnston
> wrote:
> > The argument being made is that the enum patch adheres to established
> practices; and when adding new code that new code is encouraged to adhere
> to how existing code is written
Vladlen Popolitov writes:
> d) Above query will start parallel worker(s). When worker(s) finish(es),
> it/they send SIGUSR1 that is caught by debugger. When you dimiss
> the signal message, you find that query continues to run, but really it
> waits (in latch.c or in waiteventset.c depending on co
Hi,
On my windows machine I've found unstable test, it fails very rarely,
but anyway, sometimes it fails.
src/test/recovery/t/009_twophase.pl
# Failed test 'Committed prepared transaction is visible to new
snapshot in standby'
# at t/009_twophase.pl line 360.
# got: '0'
# ex
On Wed, Mar 26, 2025 at 11:41:13AM -0400, Robert Haas wrote:
> What I'm upset about is that it feels to me like Nikolay is trying to
> win the argument by yelling. I don't want that to be the way we do
> things around here. I admit that sometimes it is, and I think that is
> bad, no matter who the
On Wed, Mar 26, 2025 at 10:29 AM Nikolay Shaplov wrote:
> The only thing I am asking for: please keep code consistent. Better keep
> reloption core the way it was, but if it is not possible, then keep it
> consistent then.
>
Consistency at the expense of all else is a debatable position that wil
On Sat, Mar 22, 2025 at 12:10 PM Robert Haas wrote:
> I'm not going
> to insist on shipping this if I'm the ONLY one who would ever get any
> use out of it, but I doubt that's the case.
Hearing no other votes against this, I have committed it, but now I
wonder if that is going to break the buildf
Hi Daniel,
Thank you for your review.
I have incorporated all your changes in v20 patches and ensured that the
review comments
corresponding to 0001 patch are included in that patch and not in 0002.
>
> +MEM_CTX_PUBLISH"Waiting for backend to publish memory information."
> I wonder if this
Hi!
Thank you for the review!
3. Consider updating documentation for doc/src/contrib-spi.sgml, or any
file as appropriate, to reflect the changes.
The changes have now been added to doc/src/contrib-spi.sgml. I also
added a consideration note about interactions with BEFORE triggers.
4. Are
sorry for the noise ,previous response had my editor's formatting,just
resending without that formatting.
./psql postgres
Hi,
On Wed, Mar 26, 2025 at 5:55 PM Andrew Dunstan wrote:
> You can still create a database with these using "CREATE DATABASE" though.
> Shouldn't we should really be preve
Sending a new version that includes the new explain_progressive.c file in
meson.build.
Rafael.
v12-0001-Proposal-for-progressive-explains.patch
Description: Binary data
On Wed, Mar 26, 2025 at 4:59 AM Jakub Wartak
wrote:
> ERROR: unexpected data beyond EOF in block 1472 of relation base/5/16387
> HINT: This has been seen to occur with buggy kernels; consider
> updating your system.
>
> to something more generic and less confusing. It is coming from
> ffae5cc5a6
Peter Eisentraut писал(а) 2025-02-23 21:23:
I have committed the rest of this with the adjustments you suggested.
On 10.02.25 18:44, Dagfinn Ilmari Mannsåker wrote:
Here is a new patch set rebased over that.
Hi
I mentioned this patch in my message
https://www.postgresql.org/message-id/f28
st 26. 3. 2025 v 9:05 odesílatel Daniel Gustafsson napsal:
> > On 26 Mar 2025, at 08:42, Pavel Stehule wrote:
>
> > The reason is probably my LANG=cs_CZ.UTF8. When I switched to LANG=C,
> then tests passed.
> >
> > The main problem is in numeric format. Czech uses the comma instead of
> the dot.
On Wed, Mar 26, 2025 at 8:41 AM Robert Haas wrote:
> Nathan has already had to spend a significant amount of time engaging
with this thread over what I think should be a complete non-event, and
> will probably have to spend more, and all that takes away from time
> that could, for example, be sp
Hello Masao-san and Melanie,
Thank you for your attention to this!
23.03.2025 19:26, Fujii Masao wrote:
With autovacuum = off, all of these fluctuations go away.
So you are suggesting disabling autovacuum during the postgres_fdw regression
test?
No, I'd prefer to have the test stable wit
On Wed, Mar 26, 2025 at 10:17 AM David G. Johnston
wrote:
> The argument being made is that the enum patch adheres to established
> practices; and when adding new code that new code is encouraged to adhere to
> how existing code is written. A vote to keep to such guidelines seems
> reasonable
Hearing no further discussion, I've pushed this.
regards, tom lane
On Wed, Mar 26, 2025 at 9:14 AM Nathan Bossart
wrote:
> FWIW one of the big reasons I didn't proceed with the enum approach
initially is because I worried that I'd end up in a similar discussion
> about how terrible _that_ approach is. When I look at that patch [0], I
> genuinely wonder if folk
On Wed, Mar 26, 2025 at 08:09:53AM -0700, David G. Johnston wrote:
> I'm willing to say "I don't know why this is so very important to Nikolay,
> but I trust him that it is, and since my opinion isn't that strong and this
> isn't a big deal, so I will accommodate the person screaming that adding
>
On Wed, Mar 26, 2025 at 6:00 AM Andrey Borodin wrote:
>
>
>
> > On 26 Mar 2025, at 08:32, Masahiko Sawada wrote:
> >
> > Please review it.
>
> The patch looks good to me except one nit.
> +WITH uuidts AS (
> + SELECT y, ts as ts, lag(ts) OVER (ORDER BY y) AS prev_ts
> + FROM (SELECT y, uu
Hello community,
I recently encountered a deadlock in postgresql while performing concurrent
INSERT statements on the same table in two separate sessions.
The error message explicitly mentions that the deadlock occurred while
inserting an index tuple.
There were no explicit transactions (BEGIN/
Hi,
My colleague Oleksii Kozlov ran into an assertion while testing aborted
UPDATE-commands in sub transactions.
To reproduce this assertion run the SQl in the attached script. I tested
this on 15.10 and 17.4
Running the script will lead to the the assertion:
TRAP: failed Assert("HEAP_XMAX_IS_LOC
> On 26 Mar 2025, at 09:53, vignesh C wrote:
> On Fri, 31 Jan 2025 at 21:05, Daniel Gustafsson wrote:
>>
>>> On 31 Jan 2025, at 16:29, Andres Freund wrote:
>>> This #ifdef ENABLE_GSS probably isn't necessary anymore.
>>
>> Yeah, I only left it for code documentation reasons to keep readers fr
Thanks for all the feedback. Please find attached a version which prints
"[none]" as the default value, "[local]" for a socket, and otherwise
whatever pg_getnameinfo_all spits out. I cleaned up the coding, respected
padding, removed the family checks, and expanded the docs a tiny bit to
give the re
В письме от среда, 26 марта 2025 г. 18:41:13 MSK пользователь Robert Haas
написал:
> What I'm upset about is that it feels to me like Nikolay is trying to
> win the argument by yelling.
I do not think it is fair. When votes are against you (and I did not ask
anybody else's help for it) it turne
I reviewed everything up to and including "[PATCH v2.12 17/28] aio, bufmgr:
Comment fixes", the last patch before write support.
postgr.es/m/20250326001915.bc.nmi...@google.com covered patches 1-9, and this
email covers patches 10-17. All remaining review comments are minor, so I've
marked the com
В письме от среда, 26 марта 2025 г. 21:16:20 MSK пользователь Robert Haas
написал:
> The reason why I felt that way is
> because you were using what seemed to me to be very strong language
> over what seemed to me to be a very minor issue.
Being not native speaker has it's own difficulties. Plus
On Wed, Mar 26, 2025 at 12:32 PM Nikita Malakhov wrote:
> Vladlen, I've checked your example and also got this behavior
> on the current master under Gdb (Ubuntu 22.04 LTS).
>
> On the query above server waits in this state (as shown by gdb):
> Program received signal SIGUSR1, User defined signal
Hi Dmitrii,
Thanks for the quick update!
On 3/26/25 02:45, Dmitrii Bondar wrote:
>> 3. Consider updating documentation for doc/src/contrib-spi.sgml, or any file
as appropriate, to
>> reflect the changes.
>
> The changes have now been added to doc/src/contrib-spi.sgml. I also added a
considerat
On Mon, Mar 03, 2025 at 11:35:15AM -0600, Sami Imseih wrote:
> Thanks for the update. This LGTM! and I will mark as RFC.
Yes, agreed that there is no specific need to be precise about the
attributes that can become inconsistent, as this would also depend on
the addition of more states, or event mo
On Wed, 26 Mar 2025 at 14:04, Michael Paquier wrote:
>
> On Wed, Mar 26, 2025 at 11:56:50AM +1300, David Rowley wrote:
> > Here is the v8 version with the bug fix and performance stuff
> > separated out.
>
> Why not. I assume that you would merge these together?
I think it's better it's two comm
Hi! I started reviewing it and noticed that your code repeated this
cycle maybe it would be better to put it in a separate function, for
example in the form of a name like "analyze_stmts"?
or is it possible to create a macro for them?
@@ -2016,6 +2017,17 @@ exec_bind_message(StringInfo input_m
HI Maxim Orlov Heikki Linnakangas
Thank you for working on it,A few more days is a code freeze.It seems
like things have been quiet for a while, but I believe implementing xid64
is absolutely necessary. For instance, there’s often concern about
performance jitter caused by frequent freezes. If
Hi,
I had another off-list discussion with Fujii-san, and according to the
following manual[1], it seems that a transaction with an overflowed
subtransaction is already considered inconsistent:
Reaching a consistent state can also be delayed in the presence of
both of these conditions:
On Wed, Mar 26, 2025 at 6:34 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
>> I pondered mentioning the 2s interval but the environment variable itself
> doesn't have a default, it's either set or unset which determines whether
> it provides the default or not. IMO, adding this deta
hi.
the attached patch is to implement $subject.
the generation expression will be dropped.
the column value previous was NULL will be materialized
based on generation expression.
It seems fairly straightforward:
drop the generation expression in ATExecDropExpression,
and instruct phase 3 to comp
On Fri, Mar 21, 2025 at 10:21 AM Richard Guo wrote:
> Not quite sure if this is something we need to worry about.
I haven't really dug into this but I bet it's not that serious, in the
sense that we could probably work around it with more logic if we
really need to.
However, I'm a bit concerned
> On 20 Mar 2025, at 10:39, Álvaro Herrera wrote:
> In initialize_SSL(), the test for conn->sslkeylogfile is inside the
> #ifdef for the existance of the SSL function. I think it's better to
> log a message (probably just a warning) that says "this feature is not
> supported with this TLS librar
> Suppose:
> BEGIN;
> SELECT 1;
> SAVEPOINT bob;
> progressively explain something that aborts
> I think in this case we will call AbortSubTransaction(), not
AbortTransaction().
Indeed. We need special treatment for subtransactions. There are 2
scenarios where
AbortSubTransaction() will be called
On Wed, Mar 26, 2025 at 2:11 AM Daniel Gustafsson wrote:
> On 26 Mar 2025, at 04:52, David G. Johnston
> wrote:
> On Tue, Mar 25, 2025 at 8:07 PM Kyotaro Horiguchi
> wrote:
>
>
> I came across the following help message added in commit 1a759c83278:
>>
>> + HELP0(" WATCH_INTERVAL\n"
>> +
Hi Tom,
This recent patch is great but causes a small problem. It mixes designated
and non-designated initializers, specifically in `PG_MODULE_MAGIC_DATA(0)`.
While this is permissible in C, when imported in C++ code (in extern "C"),
it causes GCC to emit an error: `either all initializer clauses
On Thu, Mar 27, 2025 at 12:09:35PM +1300, David Rowley wrote:
> I think it's better it's two commits. They're for different purposes.
Fine for me.
> Ok, I won't protest. I just feel the bug is a relic of the old design
> and I don't believe the tests are testing anything useful in the new
> desig
On Wed, Mar 26, 2025 at 2:09 PM Robert Haas wrote:
> Hearing no other votes against this, I have committed it, but now I
> wonder if that is going to break the buildfarm, because I just noticed
> that the changes I made in v9 seem not to have resolved the problem
> with debug_parallel_query, for r
On Wed, Mar 26, 2025 at 02:09:32PM -0400, Robert Haas wrote:
> On Sat, Mar 22, 2025 at 12:10 PM Robert Haas wrote:
> > I'm not going
> > to insist on shipping this if I'm the ONLY one who would ever get any
> > use out of it, but I doubt that's the case.
>
> Hearing no other votes against this, I
On Fri, Mar 21, 2025 at 11:02 AM Daniel Gustafsson wrote:
> >> How about we provide the current libpq.so without linking to curl and also
> >> a
> >> libpq-oauth.so that has curl support? If we do it right libpq-oauth.so
> >> would
> >> itself link to libpq.so, making libpq-oauth.so a fairly sma
On 2025-Mar-26, Nikolay Shaplov wrote:
> git blame reloptions.c | grep "Robert Haas" | wc -l
> 112
>
> git blame reloptions.c | grep Álvaro | wc -l
> 792
>
> For me Alvary is the keeper of the concept of reloption. And he sees
> difference. If he would said isset_offset is good, I will follow.
On Thu, Mar 27, 2025 at 10:41 AM Andres Freund wrote:
> > > Subject: [PATCH v2.12 13/28] Enable IO concurrency on all systems
> >
> > Consider also updating this comment to stop focusing on prefetch; I think
> > changing that aligns with the patch's other changes:
> >
> > /*
> > * How many buffer
Hello John,
v15 LGTM. Couple of minor comments:
> I'm leaning towards a length limit for v15-0001 so that inlined instructions
> are
> likely to be unrolled. Aside from lack of commit message, I think that one is
> ready
> for commit soon-ish.
+1
> I'm feeling pretty good about 0002, but
On Wed, Mar 26, 2025 at 11:14:47AM -0700, 杨江华 wrote:
> This patch modifies the instr_time.h header to prefer CLOCK_MONOTONIC_COARSE
> when available. By using CLOCK_MONOTONIC_COARSE, we can leverage a lower
> resolution(4ms) but faster alternative for timing operations, which reduces
> the overhead
On Mon, Mar 24, 2025 at 6:46 PM Tom Lane wrote:
> As I said, I'm not necessarily averse to showing these numbers
> somehow. But I don't think they belong in the default output,
> and I'm not even convinced that VERBOSE is the right place.
> pg_overexplain seems like it could be an ideal home for
On Fri, Mar 21, 2025 at 3:23 PM Melanie Plageman
wrote:
>
> I've committed the btree and gist read stream users. I think we can
> come back to the test after feature freeze and make sure it is super
> solid.
I've now committed the spgist vacuum user as well. I'll mark the CF
entry as completed.
I
On Fri, 31 Jan 2025 at 21:05, Daniel Gustafsson wrote:
>
> > On 31 Jan 2025, at 16:29, Andres Freund wrote:
>
> >> #ifdef ENABLE_GSS
> >> -#if defined(HAVE_GSSAPI_H)
> >> -#include
> >> -#else
> >> -#include
> >> -#endif /* HAVE_GSSAPI_H */
> >> +#include "libpq/pg-gssapi.h"
> >> #endif /* ENAB
On Wed, Mar 26, 2025 at 05:17:17PM +0300, Maksim.Melnikov wrote:
> Test check visibility of prepared transactions in standby after a restart
> while primary is down.
> Failed assert check that changes, commited on transaction on primary node,
> were synchronously replicated to standby node.
> In te
On Thu, 27 Mar 2025 at 04:19, Andrei Lepikhov wrote:
> But if we partition on HASH(x,y) it is not working (see
> incorrect-pruning-example.sql):
>
> PREPARE test2 (int,int) AS
> SELECT 1 FROM array_prune
> WHERE id1 = ANY(ARRAY[$1]) AND id2 = ANY(ARRAY[$2]);
> EXPLAIN (COSTS OFF) EXECUTE test2
On Wed, Mar 26, 2025 at 2:34 PM Nikolay Shaplov wrote:
> В письме от среда, 26 марта 2025 г. 21:16:20 MSK пользователь Robert Haas
> написал:
> > The reason why I felt that way is
> > because you were using what seemed to me to be very strong language
> > over what seemed to me to be a very minor
On Mon, Mar 24, 2025 at 7:58 PM Masahiko Sawada wrote:
>
> You're right. I've studied the read stream code and figured out how to
> use it. In the attached patch, we end the read stream at the end of
> phase 1 and start a new read stream, as you suggested.
I've started looking at this patch set s
On Tue, 28 Jan 2025 at 07:49, jian he wrote:
>
> On Mon, Jan 6, 2025 at 5:34 PM jian he wrote:
> >
> > hi.
> >
> > about this issue,
> > last email in 2012 (https://postgr.es/m/8967.1353167...@sss.pgh.pa.us)
> > """
> > Even if it happens to be trivial in the current patch, it's an added
> > func
В письме от среда, 26 марта 2025 г. 21:43:42 MSK пользователь Robert Haas
написал:
> why is it worth arguing about?
I have full model of current reloptions and my patch unrolled in my head. They
have some harmony. (Mine has more harmony, but it is not the case).
isset_offset the way it is intr
It Makes sense, but we can distinguish such code which needs `
CLOCK_MONOTONIC`.
Now I add the configure option `--with-clock-monotonic-coarse`.
Michael Paquier 于2025年3月26日周三 15:34写道：
> On Wed, Mar 26, 2025 at 11:14:47AM -0700, 杨江华 wrote:
> > This patch modifies the instr_time.h header to pref
On Tue, 25 Mar 2025 at 01:18, Andres Freund wrote:
>
> Hi,
>
> Attached v2.12, with the following changes:
I took a quick gander through this just out of curiosity (yes, I know
I'm late), and found these show-stoppers:
v2.12-0015-aio-Add-pg_aios-view.patch:
+ ERROR mean the I/O failed
On Wed, Mar 26, 2025 at 04:33:49PM -0400, Andres Freund wrote:
> On 2025-03-25 17:19:15 -0700, Noah Misch wrote:
> > On Mon, Mar 24, 2025 at 09:18:06PM -0400, Andres Freund wrote:
> > Second, the aio_internal.h comment changes discussed in
> > postgr.es/m/20250325155808.f7.nmi...@google.com and ea
Hi,
On 2025-03-26 11:31:02 -0700, Noah Misch wrote:
> I reviewed everything up to and including "[PATCH v2.12 17/28] aio, bufmgr:
> Comment fixes", the last patch before write support.
Thanks!
> postgr.es/m/20250326001915.bc.nmi...@google.com covered patches 1-9, and this
> email covers patches
Hi,
On 2025-03-26 21:20:47 +, Thom Brown wrote:
> I took a quick gander through this just out of curiosity (yes, I know
> I'm late), and found these show-stoppers:
>
> v2.12-0015-aio-Add-pg_aios-view.patch:
>
> + ERROR mean the I/O failed with an error.
>
> s/mean/means/
>
>
> v2
26.03.2025, 21:06, "Masahiko Sawada" :Agreed. I've done this in the attached patch.Great! The patch looks good to me.Best regards, Andrey Borodin.
On Wed, 26 Mar 2025 at 21:18, Maksim.Melnikov wrote:
>
> So my question is
> can we accept such behavior as bug of postgres codebase, or, on other way, it
> is bug of unstable test?
> P.S.
> For me it is looking strange, that postgres start processing workload before
> full config initializing.
Hi,
On 2025-03-25 17:19:15 -0700, Noah Misch wrote:
> On Mon, Mar 24, 2025 at 09:18:06PM -0400, Andres Freund wrote:
> > @@ -296,7 +299,9 @@ pgaio_io_call_complete_local(PgAioHandle *ioh)
> >
> > /*
> > * Note that we don't save the result in ioh->distilled_result, the
> > local
> > -
I've attached a new set of patches in which I've tried to address John's
feedback. I ran some new benchmarks with these patches. "M3" is an Apple
M3 (my laptop), "G3" is an r7g.4xlarge, and "G4" is an r8g.4xlarge. "no
SVE" means the patches are applied but the function pointer points to the
Neon
On Thu, Mar 27, 2025 at 1:13 PM cca5507 wrote:
>
> Hi,
>
> - IIUC your "fast forward" concern is not related to this particular thread
> but you
> - think it's already an issue on the master branch (outside of the
> BUILDING_SNAPSHOT
> - handling we are discussing here), is that correct? (that's
Robert Haas writes:
> - -> Index Scan using daucus_id_idx on daucus v2_2 (actual
> rows=0.12 loops=8)
> + -> Index Scan using daucus_id_idx on daucus v2_2 (actual
> rows=0.13 loops=8)
Even if this had not failed in the buildfarm, it would certainly
have caused problems for someb
Hello, David!
> I see you opted to only jumble the low-order byte of the pending null
> counter. I used the full 4 bytes as I don't think the extra 3 bytes is
> a problem. Witrh v7 the memcpy to copy the pending_nulls into the
> buffer is inlined into a single instruction. It's semi-conceivable
>
On Wed, 26 Mar 2025 at 12:15, jian he wrote:
>
> hi.
> attached patch for implementing $subject feature.
>
> * internally such index will be transformed into expression index.
> for example, an index on (b int GENERATED ALWAYS AS (a * 2) VIRTUAL) will be
> converted into an expression index on
On Wed, 26 Mar 2025 at 19:31, Richard Guo wrote:
>
> On Wed, Mar 26, 2025 at 3:06 PM Tender Wang wrote:
> > The comment about notnullattnums in struct RangeTblEntry says that:
> > * notnullattnums is zero-based set containing attnums of NOT NULL
> > * columns.
> >
> > But in get_relation_notnull
On Thu, Mar 20, 2025 at 01:33:26PM -0700, Jacob Champion wrote:
> That's more than I'd like, to be perfectly honest. I'm least happy
> about libssh, because we're not using SFTP but we have to pay for it.
> And the Deb-alikes add librtmp, which I'm not thrilled about either.
>
> The rest are, IMO,
Peter Eisentraut writes:
> Committed that, thanks.
Buildfarm member snakefly doesn't like this too much. Since no other
animals have failed, I guess it must be about local conditions on
that machine, but the report is pretty opaque:
# +++ tap check in src/test/modules/test_extensions +++
# F
Hi,
There are 3 threads currently.
The latest patches are v4-0001 and v3-0002 in [2].
[1]https://www.postgresql.org/message-id/flat/tencent_6aaf072a7623a11a85c0b5fd290232467...@qq.com
[2]https://www.postgresql.org/message-id/flat/tencent_8dec9842690a9b6afd52d4659ef0700e9...@qq.com
[3]https://
> On 26 Mar 2025, at 08:32, Masahiko Sawada wrote:
>
> Please review it.
The patch looks good to me except one nit.
+WITH uuidts AS (
+ SELECT y, ts as ts, lag(ts) OVER (ORDER BY y) AS prev_ts
+ FROM (SELECT y, uuid_extract_timestamp(uuidv7((y || ' years')::interval))
AS ts FROM gene
I would like to propose that we tweak the following error message:
ERROR: unexpected data beyond EOF in block 1472 of relation base/5/16387
HINT: This has been seen to occur with buggy kernels; consider
updating your system.
to something more generic and less confusing. It is coming from
ffae5c
On Wed, 26 Mar 2025 at 12:17, Steven Niu wrote:
>
> Hi,
Hi!
> This double scanning can be inefficient, especially for large inputs.
> So I optimized the function to eliminate the need for two scans,
> while preserving correctness and efficiency.
While the argument that processing input once not
1 - 100 of 156 matches
Mail list logo
