On 27.03.2025 01:13, Michael Paquier wrote:
Tracking if the configuration has been properly loaded in
WalSndCtlData makes sense here, but I am confused by the patch: you
have defined SYNCSTANDBYSDEFINED but sync_standbys_defined never sets
it. It may be simpler to use a separate boolean flag fo
On Fri, 28 Mar 2025 at 09:31, Michael Paquier wrote:
>
> On Tue, Feb 25, 2025 at 04:25:37PM +0900, Michael Paquier wrote:
> > Rebased.
>
> Conflict in pg_class.h. Rebased.
> --
> Michael
Looks like we entered a rebase loop here. I'm really interested in
moving this forward; furthermore, I am inc
Andy Fan писал(а) 2024-10-17 03:33:
Bruce Momjian writes:
Is this still being considered?
I'd +1 on this feature. I guess this would be more useful on parallel
case, where the Sort can be pushed down to parallel worker, and in the
distributed database case, where the Sort can be pushed down
On Fri, Mar 28, 2025 at 7:07 AM Michael Paquier wrote:
>
> On Thu, Mar 27, 2025 at 06:15:06PM +0100, Alvaro Herrera wrote:
> > BTW another idea to shorten this tests's runtime might be to try and
> > identify which of parallel_schedule tests leave objects behind and
> > create a shorter schedule w
-Filip-
po 17. 3. 2025 v 23:13 odesílatel Tomas Vondra napsal:
> On 3/15/25 11:40, Alexander Korotkov wrote:
> > On Sun, Jan 5, 2025 at 1:43 AM Filip Janus wrote:
> >>
> >> I apologize for multiple messages, but I found a small bug in the
> previous version.
> >>
> >> -Filip-
> >
> > G
Bug fixed in 2025b:
https://lists.iana.org/hyperkitty/list/tz-annou...@iana.org/thread/6JVHNHLB6I2WAYTQ75L6KEPEQHFXAJK3/
Mailing list:
https://lists.iana.org/hyperkitty/list/t...@iana.org/thread/7MKA4UXVUUGXXMDCTPQ5VOLD4KKN3LQR/
06.02.2025 21:00, Tom Lane пишет:
Evgeniy Gorbanyov writes:
Ifyo
On Fri, Mar 28, 2025 at 3:25 AM Alvaro Herrera wrote:
>
> On 2025-Mar-24, jian he wrote:
>
> > hi.
> > you may like the attached. it's based on your idea: attnotnullvalid.
>
> This is quite close to what I was thinking, yeah. I noticed a couple of
> bugs however, and ended up cleaning up the whol
Dear Amit,
>
> Right, I think this is a better idea. I have a few comments:
> 1.
> + /*
> + * In 035_standby_logical_decoding.pl, RUNNING_XACTS could move slots's
> + * xmin forward and cause random failures.
>
> No need to use test file name in code comments.
Fixed.
> 2. The comments atop wai
On Mon, 24 Mar 2025 at 21:17, Álvaro Herrera wrote:
>
> One thing that bothers me a bit about this is that there's no single
> code comment where this restriction it documented in full; in fact it
> doesn't seem documented anywhere, only in the commit message.
>
> I think check_foreign_tables() is
On Wed, 19 Mar 2025 at 18:12, David Rowley wrote:
>
> On Wed, 19 Mar 2025 at 23:22, Ilia Evdokimov
> wrote:
> > Everything seems fine with the ANALYZE command autocompletion. Regarding
> > VACUUM, I'm not entirely convinced we should provide autocompletion in
> > every case. I'd prefer to keep
The S flag is "universal" enough and can be combined with a wide variety of
commands to show system views. Examples include \d, \dn, \dp, \dL, and so
on. In contrast, the N I'm introducing can only be combined with \d, so I
wouldn't treat it the same as S.
All things that combine with \d (t, i, m,
On 3/28/25 00:18, Alexander Korotkov wrote:
The attached patch changes the reordering algorithm of
group_similar_or_args() in the following way. We reorder each group
of similar clauses so that the first item of the group stays in place,
but all the other items are moved after it. So, if there
On Fri, 28 Mar 2025 at 01:37, Mahendra Singh Thalor
wrote:
>
> On Thu, 27 Mar 2025 at 18:33, Álvaro Herrera
wrote:
> >
> > On 2025-Mar-27, Andrew Dunstan wrote:
> >
> > > I don't think we can backpatch this. It's a behaviour change.
> >
> > I agree, we can't.
> >
> > Also, if we're going to enfor
On Fri, Mar 28, 2025 at 1:32 PM Andrei Lepikhov wrote:
> On 3/28/25 00:18, Alexander Korotkov wrote:
> > The attached patch changes the reordering algorithm of
> > group_similar_or_args() in the following way. We reorder each group
> > of similar clauses so that the first item of the group stays
On 3/28/25 12:59, Alexander Korotkov wrote:
On Fri, Mar 28, 2025 at 1:32 PM Andrei Lepikhov wrote:
I don't think this is going to be CPU-consuming. I don't think this
is going to be measurable. This patch introduces one additional pass
over array of OrArgIndexMatch'es, and qsort of them. I th
On 28.03.2025 02:18, Alexander Korotkov wrote:
Hi!
On Mon, Mar 24, 2025 at 2:46 PM Alena Rybakina
wrote:
I agree with Andrey's changes and think we should fix this, because otherwise
it might be inconvenient.
For example, without this changes we will have to have different test output
files
Then we need to decide clearly what exactly to display in EXPLAIN for
the Memoize node: absolute values (estimated distinct keys and estimated
cache capacity) or ratios (hit_ratio and evict_ratio). Ratios have the
advantage of quickly reflecting the overall effectiveness of Memoize.
However, ab
On 28.03.2025 15:23, Alena Rybakina wrote:
I agree with your code in general, but to be honest, double qsort
confused me a little.
I understood why it is needed - we need to sort the elements so that
they stand next to each other if they can be assigned to the same
group, and then sort the
Hi Tomas,
1) alignment
>
> There was a comment with a question whether we need to MAXALIGN the
> chunks in dynahash.c, which were originally allocated by ShmemAlloc, but
> now it's part of one large allocation, which is then cut into pieces
> (using pointer arithmetics).
>
> I was not sure whethe
On Fri, Mar 28, 2025 at 12:20 PM Ashutosh Bapat
wrote:
>
> On Fri, Mar 28, 2025 at 7:07 AM Michael Paquier wrote:
> >
> > On Thu, Mar 27, 2025 at 06:15:06PM +0100, Alvaro Herrera wrote:
> > > BTW another idea to shorten this tests's runtime might be to try and
> > > identify which of parallel_sch
Dear Fujii-san,
> Thanks for the patch! It looks good to me.
>
> I'm considering whether to back-patch these changes to older versions.
> Since pg_recvlogical --drop-slot worked without --dbname in 9.4
> but started failing unintentionally in 9.5, it could be considered a bug.
> However, this beh
On Fri, 28 Mar 2025 at 21:26, Tomas Vondra wrote:
>
> Here's a polished version of the patches. If you have any
> comments/objections, please speak now.
> --
> Tomas Vondra
Hi, no objections, lgtm
--
Best regards,
Kirill Reshke
On Thu, Mar 27, 2025 at 12:37:53PM -0400, Robert Haas wrote:
> A recursive CTE effectively takes two queries that will be run as
> arguments. For some reason, instead of choosing syntax like WITH
> RECURSIVE t1 AS BASE_CASE (initial_query) RECURSIVE_CASE
> (iterated_query), somebody chose WITH RECU
Hello Michael,
11.03.2025 02:06, Michael Paquier wrote:
And I guess that we're OK here, so applied. That should be the last
one.
Please try the following query:
BEGIN;
SET LOCAL stats_fetch_consistency = snapshot;
SELECT * FROM pg_stat_get_backend_wal(pg_backend_pid());
with sanitizers (or u
On Fri, Mar 28, 2025 at 12:09 PM Rafael Thofehrn Castro
wrote:
> As you said, visibility on the non instrumented query plan is already a
> feature
> of auto_explain.
True, although thinking about it more, they're not being sent to the
same place. auto_explain goes to the log, and this goes to a
Alvaro Herrera writes:
> Hmm, I didn't mean that we'd maintain a separate schedule. I meant that
> we'd take the existing schedule, then apply some Perl magic to it that
> grep-outs the tests that we know to contribute nothing, and generate a
> new schedule file dynamically. We don't need to mai
Committed.
On Fri, Mar 28, 2025 at 10:25:26AM -0500, Nathan Bossart wrote:
> On Thu, Mar 27, 2025 at 03:31:27PM +0700, John Naylor wrote:
>> On Thu, Mar 27, 2025 at 10:38 AM Nathan Bossart
>> wrote:
>>> I also noticed a silly mistake in 0003 that would cause us to potentially
>>> skip part of the
On Fri, Mar 28, 2025 at 3:59 PM Rafael Thofehrn Castro
wrote:
> > True, although thinking about it more, they're not being sent to the
> > same place. auto_explain goes to the log, and this goes to a view.
> > What about something like this:
> > progressive_explain = on | off
> > progressive_expla
> I still have trouble understanding what that means. Is the interval
> irrelevant except when progressive_explain = analyze?
That is correct. Interval currently is only used when instrumentation
is enabled through progressive_explain = analyze.
> That is correct. Interval currently is only used when instrumentation
> is enabled through progressive_explain = analyze.
I guess there would still be a point in printing the plan on a regular
interval
when instrumentation is disabled. In that case the only thing we would see
changing in the pla
On Thu, Mar 27, 2025 at 6:03 PM Alena Rybakina
wrote:
> I replied an example like this:
This example shows costs that are dominated by heap access costs. Both
the sequential scan and the bitmap heap scan must access 637 heap
blocks. So I don't think that this is such a great example -- the heap
a
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hi Aleksander,
I have reviewed your patch. It looks good to
On 02.03.25 22:08, Thomas Munro wrote:
And one more thing like that: in a couple of places we see warnings on
macOS CI that I'd missed: when printing the result of i64abs() as
PRId64, because it happens to use labs() and it happens to define
int64_t as long long, [...]. I
suppose we should cast
On Mon, Mar 24, 2025 at 10:27 AM Nikolay Shaplov wrote:
> В письме от понедельник, 24 марта 2025 г. 20:09:23 MSK пользователь Nathan
> Bossart написал:
>
> > > You've just changed the whole engine, for what is seems to be an
> > > exceptional case, that can be solved via existing means.
> > I hav
On Fri, 28 Mar 2025 at 09:47, jian he wrote:
>
> hi.
>
> in plancat.c, function: get_relation_constraints
>
> ```
> for (i = 0; i < num_check; i++)
> {
> Node *cexpr;
> /*
> * If this constraint hasn't been fully validated yet, we must
> * ignore it here. Also ignore if
> But having said that, I'm not quite sure I understand why you're
> proposing (A) and (B1) as separate alternatives. Changing
> progressive_explain to be a Boolean doesn't seem like it solves the
> problem of needing to wrap ExecProcNode from a signal handler. The
> only thing that seems to solve
On 28.03.25 17:14, Masahiko Sawada wrote:
On Fri, Mar 28, 2025 at 8:30 AM Peter Eisentraut wrote:
On 09.02.25 08:32, Peter Eisentraut wrote:
Checking the status of this thread ...
The patches that removed the configure checks for _configthreadlocale(),
and related cleanup, have been committe
On Fri, 28 Mar 2025 at 15:19, Richard Guo wrote:
>
> On Fri, Mar 28, 2025 at 4:53 PM Kirill Reshke wrote:
> > On Fri, 28 Mar 2025 at 09:47, jian he wrote:
> > > The first "Also ignore if NO INHERIT and we weren't told that that's
> > > safe." is duplicated,
> > > also it's in the wrong place?
>
On Fri, Mar 28, 2025 at 1:14 AM Tom Lane wrote:
>
> Well, we extend the spec in lots of places. I'd be okay with removing
> this restriction if I were sure there were no bad consequences, but
> it seems likely that there are some. College math was way too long
> ago for me to be sure about the "
On 2025-Mar-28, jian he wrote:
> i think your patch messed up with pg_constraint.conislocal.
> for example:
>
> CREATE TABLE parted (id bigint default 1,id_abc bigint) PARTITION BY LIST
> (id);
> alter TABLE parted add CONSTRAINT dummy_constr not null id not valid;
> CREATE TABLE parted_1 (id bi
On 28.03.25 17:32, Peter Eisentraut wrote:
On 28.03.25 17:14, Masahiko Sawada wrote:
On Fri, Mar 28, 2025 at 8:30 AM Peter Eisentraut
wrote:
On 09.02.25 08:32, Peter Eisentraut wrote:
Checking the status of this thread ...
The patches that removed the configure checks for
_configthreadloca
Hi All,
We would like to share a proposal for optimizations with simd enabled sort.
Sorting is a common task in Postgres, for example, for sorting tuples (e.g.,
for queries requiring ordered, grouped, or unique rows) or arrays of elements
(e.g., list_sort). We propose integrating SIMD-based sort
On Fri, 28 Mar 2025 at 08:39, jian he wrote:
>
> hi.
>
> I made a mistake.
> The regress test sql file should have a new line at the end of the file.
Couple of suggestions:
1) Can you add some comments here, this is the only code that is
different from the regular table handling code:
+
On Fri, Mar 28, 2025 at 12:13 AM Man Zeng wrote:
> // PG_MODULE_MAGIC;
> PG_MODULE_MAGIC_EXT(
> .name = "pg_overexplain",
> .version = PG_VERSION
> );
Good catch, committed.
--
Robert Haas
EDB: http://www.enterprise
On Thu, Mar 27, 2025 at 9:38 PM Rafael Thofehrn Castro
wrote:
> > Calling ProgressiveExplainTrigger() directly from
> > ProgressiveExplainStartupTimeoutHandler() seems extremely scary --
>
> Agreed. In that other similar patch to log query plans after a signal is sent
> from another session there
=?UTF-8?B?0JXQstCz0LXQvdC40Lkg0JPQvtGA0LHQsNC90LXQsg==?=
writes:
> Bug fixed in 2025b:
> https://lists.iana.org/hyperkitty/list/tz-annou...@iana.org/thread/6JVHNHLB6I2WAYTQ75L6KEPEQHFXAJK3/
We'll get around to syncing to tzcode 2025b or later at some point.
This particular issue does not strike
On 24.03.25 04:26, jian he wrote:
rebase, and some minor code comments change.
I have committed this.
I did a bit more editing on the naming of various things. In terms of
functionality, in ExecConstraints() notnull_virtual_attrs and
virtual_notnull_check were redundant, so I simplified tha
Hi,
On 2025-03-27 20:22:23 -0700, Noah Misch wrote:
> On Thu, Mar 27, 2025 at 04:58:11PM -0400, Andres Freund wrote:
> > Don't report the error in the completion callback. The obvious place would
> > be
> > to do it where we we'll raise the warning/error in the issuing process. The
> > big disa
On Fri, Mar 28, 2025 at 5:39 AM Pavel Luzanov wrote:
> One more suggestion to improve the documentation.
> It lacks installations actions, something like in auto_explain:
>
> To use pg_overexplain, simply load it into the server.
> You can load it into an individual session:
>
> LOAD 'pg_overexpla
Tom Lane писал(а) 2025-03-14 23:52:
I spent some time today going through the actual code in this patch.
I realized that there's no longer any point in 0001: the later patches
don't move or repeatedly-call that bit of code, so it can be left
as-is.
What I think we could stand to split out, tho
Here's a polished version of the patches. If you have any
comments/objections, please speak now. I don't plan to push 0006 (the
stress test), of course.
Changes I did:
1) update / write proper commit messages, hopefully explaining the
purpose of each patch well enough
2) update the lists of revi
On Fri, Mar 28, 2025 at 8:30 AM Peter Eisentraut wrote:
>
> On 09.02.25 08:32, Peter Eisentraut wrote:
> > Checking the status of this thread ...
> >
> > The patches that removed the configure checks for _configthreadlocale(),
> > and related cleanup, have been committed.
> >
> > The original patc
On Fri, Mar 28, 2025 at 09:00:00PM +0200, Alexander Lakhin wrote:
> Please try the following query:
> BEGIN;
> SET LOCAL stats_fetch_consistency = snapshot;
> SELECT * FROM pg_stat_get_backend_wal(pg_backend_pid());
>
> with sanitizers (or under Valgrind). When I run it, I get:
> 2025-03-28 18:38:
On Fri, Mar 28, 2025 at 4:12 PM Rafael Thofehrn Castro
wrote:
> > That is correct. Interval currently is only used when instrumentation
> > is enabled through progressive_explain = analyze.
>
> I guess there would still be a point in printing the plan on a regular
> interval
> when instrumentatio
Hi,
I'm wondering if the following sentence about time resolution is still true. It
is still like that since the initial wal writer commit [1].
If this value is specified without units, it is taken as milliseconds.
The default value is 200 milliseconds (200ms). Note that
on some syst
On Fri, 2025-03-28 at 21:11 -0400, Corey Huinker wrote:
> A rebase and a reordering of the commits to put the really-really-
> must-have relallfrozen ahead of the really-must-have stats batching
> and both of them head of the error->warning step-downs.
v11-0001 has a couple issues:
The first is t
On Sat, 29 Mar 2025 at 03:50, Andrew Dunstan wrote:
>
>
> On 2025-03-27 Th 5:15 PM, Andrew Dunstan wrote:
> >
> > On 2025-03-19 We 2:41 AM, Mahendra Singh Thalor wrote:
> >> On Wed, 12 Mar 2025 at 21:18, Andrew Dunstan
> >> wrote:
> >>>
> >>> On 2025-03-12 We 3:03 AM, jian he wrote:
> On Wed
On Thu, Mar 27, 2025 at 2:47 PM cca5507 wrote:
>
> Hi,
>
> According to the comment above DecodeTXNNeedSkip(), transactions committed
> before SNAPBUILD_CONSISTENT state won't be decoded. It's important for
> initial table data synchronization because the table sync workers use the
> consistent
On Thu, Mar 27, 2025 at 03:31:27PM +0700, John Naylor wrote:
> On Thu, Mar 27, 2025 at 10:38 AM Nathan Bossart
> wrote:
>> I also noticed a silly mistake in 0003 that would cause us to potentially
>> skip part of the tail. That should be fixed now.
>
> I'm not sure whether that meant it could re
On 09.02.25 08:32, Peter Eisentraut wrote:
Checking the status of this thread ...
The patches that removed the configure checks for _configthreadlocale(),
and related cleanup, have been committed.
The original patch to "Tidy up locale thread safety in ECPG library" is
still outstanding.
At
On 3/28/25 12:10, Rahila Syed wrote:
> Hi Tomas,
>
>
> 1) alignment
>
> There was a comment with a question whether we need to MAXALIGN the
> chunks in dynahash.c, which were originally allocated by ShmemAlloc, but
> now it's part of one large allocation, which is then cut int
Hi,
On 2025-03-28 08:54:42 -0400, Andres Freund wrote:
> One simplification that we could make is to only ever report one checksum
> failure for each IO, even if N buffers failed - after all that's what HEAD
> does (by virtue of throwing an error after the first). Then we'd not track the
> number
On 3/26/25 22:57, Rafael Thofehrn Castro wrote:
So implementation was done based on transaction nested level. Cleanup is
only
performed when AbortSubTransaction() is called in the same transaction
nested
level as the one where the query is running. This covers both PL/pgSQL
exception
blocks an
On 2025-Mar-28, Tom Lane wrote:
> I think instead of going this direction, we really need to create a
> separately-purposed script that simply creates "one of everything"
> without doing anything else (except maybe loading a little data).
> I believe it'd be a lot easier to remember to add to that
On 27/03/2025 07:00, Alexander Lakhin wrote:
I've discovered that the following script:
export PGOPTIONS='-c lock_timeout=1s'
createdb regression
for i in {1..100}; do
echo "ITERATION: $i"
psql -c "CREATE TABLE t(i int);"
cat << 'EOF' | psql &
DO $$
DECLARE
i int;
BEGIN
FOR i IN 1 .. 500
On Fri, Mar 28, 2025 at 9:32 AM Peter Eisentraut wrote:
>
> On 28.03.25 17:14, Masahiko Sawada wrote:
> > On Fri, Mar 28, 2025 at 8:30 AM Peter Eisentraut
> > wrote:
> >>
> >> On 09.02.25 08:32, Peter Eisentraut wrote:
> >>> Checking the status of this thread ...
> >>>
> >>> The patches that rem
On 2025-Mar-28, David Rowley wrote:
> I experimented by applying your v4 along with 0001-0003 of Yuya's v35
> patchset from [2]. See the attached bz2 for my results run on an AMD
> Zen2 machine. The CREATE TABLE statement is in the attached script.
Eyeballing these results, unless I am misreadin
On Fri, 2025-03-28 at 14:53 +0530, Ashutosh Bapat wrote:
> When I applied v1 it didn't pass.
I applied v1 on top of master as of March 15 (771ba90298), and then
took your two changes adding the tests, and it passed.
Version v2j is just rebased forward, which involved a trivial merge
conflict.
>
On Fri, Mar 28, 2025 at 9:03 PM vignesh C wrote:
>
> On Fri, 28 Mar 2025 at 08:39, jian he wrote:
> >
> > hi.
> >
> > I made a mistake.
> > The regress test sql file should have a new line at the end of the file.
>
> Couple of suggestions:
> 1) Can you add some comments here, this is the only cod
A rebase and a reordering of the commits to put the really-really-must-have
relallfrozen ahead of the really-must-have stats batching and both of them
head of the error->warning step-downs.
From 96b10b1eb955c5619d23cadf7de8b12d2db638a9 Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Sat, 15 Mar
Hello list,
I'm submitting a patch for improving an almost 1h long pause at the start
of parallel pg_restore of a big archive. Related discussion has taken
place at pgsql-performance mailing list at:
https://www.postgresql.org/message-id/flat/6bd16bdb-aa5e-0512-739d-b84100596035%40gmx.net
I thi
Hi,
On 2025-03-28 08:54:42 -0400, Andres Freund wrote:
> On 2025-03-27 20:22:23 -0700, Noah Misch wrote:
> > On Thu, Mar 27, 2025 at 04:58:11PM -0400, Andres Freund wrote:
> > > - We need to register a local callback for shared buffer reads, which
> > > don't
> > > need them today . That's a sm
On Thu, Mar 27, 2025 at 3:04 AM Kirill Reshke wrote:
> >
> > hi.
> > patch attached.
> > also cc to Tom,
> > since at that time, you are against the idea of ``COPY matview TO``.
>
> Hi! With this patch it is possible to COPY matview TO, but not regular
> view, which is surprising. Let's fix that?
On Thu, Mar 27, 2025 at 6:25 PM Amul Sul wrote:
>
> I am not sure how to make such tests stable enough since the trigger
> name involves OIDs. In count check, I tried adjusting the join
> condition to ensure that I get the exact same type of constraint
> w.r.t. trigger relation and the constraint
One more suggestion to improve the documentation.
It lacks installations actions, something like in auto_explain:
To use pg_overexplain, simply load it into the server.
You can load it into an individual session:
LOAD 'pg_overexplain';
(You must be superuser to do that.)
Another way is to prelo
On 27.03.25 11:16, Peter Eisentraut wrote:
Patch 0002 also looks okay, except that the error handling could be
unified with existing code, as I had previously pointed out. Patch
0005 fixes that.
I plan to commit this one next, after the above had a bit of time to stew.
also done
About pat
On Fri, Mar 28, 2025 at 4:53 PM Kirill Reshke wrote:
> On Fri, 28 Mar 2025 at 09:47, jian he wrote:
> > The first "Also ignore if NO INHERIT and we weren't told that that's
> > safe." is duplicated,
> > also it's in the wrong place?
> > The second one is fine.
> Hi! Indeed. Looks like an oversig
Also, I think IsA is a better choice for checking the node type.
Agree, IsA is better. Fixed in the patch.
On Fri, Mar 28, 2025 at 6:05 PM Richard Guo wrote:
Hmm, I wonder if we should allow the use of the 'is_not_null' keyword
in xmltable. According to the doc, it seems that users should d
On 2025-Mar-28, Shlok Kyal wrote:
> On Mon, 24 Mar 2025 at 21:17, Álvaro Herrera wrote:
> > Also, surely we should document this restriction in the SGML docs
> > somewhere.
>
> I have added comment in create_publication.sgml
Hmm, okay, but "We cannot" is not the style used in the documentation.
On 2025-Mar-28, Ashutosh Bapat wrote:
> No, that's losing some information like default installation and the
> same version.
You don't need to preserve such information. This is just a test name.
People looking for more details can grep for the name and they will find
the comments.
--
Álvaro H
Hi,
On Fri, 28 Mar 2025 at 01:53, Aidar Imamov wrote:
>
> Hi!
>
> I've been looking at the patches v3 and there are a few things I want to
> talk
> about.
Thank you for looking into this!
> EvictUnpinnedBuffer():
> I think we should change the paragraph with "flushed" of the comment to
> someth
Hi, Alexander!
d4378c0005e61b1bb7
On Fri, 28 Mar 2025 at 03:18, Alexander Korotkov wrote:
>
> Hi!
>
> On Mon, Mar 24, 2025 at 2:46 PM Alena Rybakina
> wrote:
> > I agree with Andrey's changes and think we should fix this, because
> > otherwise it might be inconvenient.
> > For example, without
On Fri, Mar 28, 2025 at 4:05 PM Alvaro Herrera wrote:
>
> On 2025-Mar-28, Ashutosh Bapat wrote:
>
> > No, that's losing some information like default installation and the
> > same version.
>
> You don't need to preserve such information. This is just a test name.
> People looking for more details
Hello.
Got an assert failure when fuzzing the raw_parser function.
The query to reproduce:
SELECT xmltable.* FROM xmltest2, LATERAL xmltable('/d/r' PASSING x
COLUMNS a int PATH '' || lower(_path) is_not_null|| 'c');
If I understand correctly, is_not_null is considered as a valid keyword
in xm
On Fri, Mar 28, 2025 at 10:46 AM Hayato Kuroda (Fujitsu)
wrote:
>
> > The problem here is that after ALTER SUBSCRIPTION tap_sub SET
> > PUBLICATION ..., we didn't wait for the new walsender on publisher to
> > start. We must use wait_for_subscription_sync both after the "CREATE
> > SUBSCRIPTION ..
On Fri, Mar 28, 2025 at 4:40 PM Евгений Горбанев wrote:
> Got an assert failure when fuzzing the raw_parser function.
> The query to reproduce:
> SELECT xmltable.* FROM xmltest2, LATERAL xmltable('/d/r' PASSING x
> COLUMNS a int PATH '' || lower(_path) is_not_null|| 'c');
>
> If I understand corre
On Thu, Mar 27, 2025 at 1:35 PM Shubham Khanna
wrote:
>
> The attached patches contain the suggested changes. They also address
> the comments provided by Kuroda-san (at [1]).
>
Pushed after some cosmetic changes.
--
With Regards,
Amit Kapila.
On Fri, Mar 28, 2025 at 10:41 AM Jeff Davis wrote:
>
> On Thu, 2025-03-27 at 17:07 +0530, Ashutosh Bapat wrote:
> > Pulled the latest sources but the test is still failing with the same
> > differences.
>
> The attached set of patches (your 0001 and 0002, combined with my patch
> v2j-0003) applied
Vignesh and Alvaro
On Fri, Mar 28, 2025 at 12:02 PM Ashutosh Bapat
wrote:
> >
> > Maybe
> > fail("roundtrip dump/restore of the regression database")
>
> No, that's losing some information like default installation and the
> same version.
How about "dump and restore across servers with same Post
On Fri, Mar 28, 2025 at 6:05 PM Richard Guo wrote:
> Nice catch. Yeah, is_not_null is a valid column option in xmltable.
> In you example, the value of the is_not_null option is "|| 'c'", which
> is interpreted as an A_Expr.
>
> I wonder if the value's type should be checked earlier, rather than
On Thu, Mar 27, 2025 at 5:34 PM Andrei Lepikhov wrote:
> I’m afraid to sound like a bore, but I think pg_overexplain should
> include a call into the hook call chain (see attachment). Who knows,
> maybe this extension will be used someday in production?
Oh, bother, that was a silly mistake on my
On Fri, Mar 28, 2025 at 05:08:26PM +0530, Mahendra Singh Thalor wrote:
> Here, I am attaching updated patches for review.
>
> v04_001* has the changes for CREATE DATABASE/ROLE/USER and
> v04_002* has the changes into pg_upgrade to give ALERTS for invalid names.
In general, +1 for these changes.
Hi,
Attached is a fix for the issue.
I looked around and didn't find extensions using PageIsVerified[Extended]() in
codesearch.debian.org, so I got rid of the compat macro and renamed
PageIsVerifiedExtended back to PageIsVerified().
Normally I'd commit tests as part of a fix like this, but since
93 matches
Mail list logo
