On Thu, Nov 28, 2024 at 12:26 AM Michael Paquier wrote:
> I don't mind being more careful here based on your concerns, so I'll
> go remove that in the stable branches.
Sorry about that. I didn't have a strong need for this to be
backpatched and should have made this clearer.
On 28.11.24 04:54, Andreas Karlsson wrote:
On 11/14/24 9:59 AM, Peter Eisentraut wrote:
I'm more concerned that many of these just keep getting copied around
indiscriminately, and this is liable to hide actual type mismatches or
silently discard qualifiers. So I'm arguing in favor of a more
r
Hello hackers, I saw a recent submission: Teach planner how to estimate rows
for timestamp generate_series. I provide a patch for the numeric type here, and
a simple test is as follows:
postgres=# explain SELECT * FROM generate_series(-25.0, -1.0, 2.0);
QUERY PLAN
>
> Any objections against applying it?
>
+1. No objections. It's a great help in communicating meaning.
On Wed, Nov 27, 2024 at 01:45:32PM +0100, Jelte Fennema-Nio wrote:
> I played around quickly with this patch and it works quite well. A few
> things that would be nice improvements I think. Feel free to change
> the command names:
> 1. Add a \flush command that calls PQflush
> 2. Add a \flushreques
On Tue, Oct 22, 2024 at 09:49:10AM +0900, Michael Paquier wrote:
> Note that there were a couple of value checks not part of the queries
> that relied on values from the catalogs for some relpersistences and
> replidents. I've fixed them while on it.
>
> Thoughts or comments are welcome.
So, thi
Hi Japin
> Worth a try.
> However, I don't think we need to based on {vac,anl}_scale_factor when
using
> the sqrt algorithm.
Here a new path, I removed the log2 algorithm and the debug2 log and the
enumeration type is also kept consistent, based on {vac,anl}_scale_factor
when using the sqrt algo
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 27 Nov 2024 19:49:17 +0800,
Junwang Zhao wrote:
> I just gave this another round of benchmarking tests. I'd like to
> share the number,
> since COPY TO has some performance drawbacks, I test only COPY
On Tue, 26 Nov 2024 at 15:39, Nazir Bilal Yavuz wrote:
>
> Hi,
>
> Thank you for working on this!
>
> On Mon, 25 Nov 2024 at 21:17, Kirill Reshke wrote:
> > While reviewing other threads implementing stream API for various core
> > subsystems, I spotted that pgstattuple could also benefit from th
On Thu, 28 Nov 2024 at 17:39, jian he wrote:
> v4 logic is to choose one with the least number of columns.
> if there is more than one with the least number of columns, simply
> choose the first one
> in the matched list.
The new code inside remove_useless_groupby_columns() is still more
complex
Kirill Reshke writes:
> On Wed, 27 Nov 2024 at 23:39, Tom Lane wrote:
>> We've fixed a few utility statements so that they can receive
>> a passed-down ParseState, but not DefineDomain.
> PFA as an independent patch then. Or should we combine these two into one?
No, I don't think this should be
On Wed, 27 Nov 2024 at 15:51, wenhui qiu wrote:
> HI Japin Li
> Thank you for you reply, Do you think that removing the log2 algorithm
> because it will be more frequent,I think sql
> server chose sqrt algorithm after their long-term verification, I think we
> need to retain sqrt algorithm,
On Wed, 27 Nov 2024 at 23:39, Tom Lane wrote:
>
> Kirill Reshke writes:
> > On Wed, 27 Nov 2024 at 08:42, jian he wrote:
> >> CREATE SCHEMA regress_schema_2 AUTHORIZATION CURRENT_ROLE
> >> create domain ss1 as ss
> >> create domain ss as text;
> >> ERROR: type "ss" does not exist
> >>
> >> the
On Thu, Nov 28, 2024 at 6:09 PM Thomas Munro wrote:
> As for why now, I think both fairywren and CI started warning/failing
> about 2 months ago[1][2]
Ohhh... it's because:
commit d700e8d75bc3844d866bf15c8cadbd72d759422d
Author: Andrew Dunstan
Date: Mon Sep 30 11:32:32 2024 -0400
Bump MI
On Tue, Nov 19, 2024 at 12:09 AM Peter Eisentraut wrote:
> The more interesting patch is 495ed0ef2d7, which did
>
> - collversion = psprintf("%d.%d,%d.%d",
> + collversion = psprintf("%ld.%ld,%ld.%ld",
This platform has sizeof(int) == sizeof(long), so it doesn't matter.
> whereas my
On Wed, Nov 27, 2024 at 5:30 PM David Rowley wrote:
>
> On Wed, 27 Nov 2024 at 19:51, jian he wrote:
> > v3 attached. in v3:
>
> 1. I find the following quite strange:
>
> postgres=# create table abcd (a int primary key, b int not null, c int
> not null, d int not null, unique(b));
> CREATE TABLE
>> This is not an AIX-specific issue. It was fixed in commit
>> af21152268317323480caa790c4a6347110f8085, committed October 30th.
Thanks Robert, it worked after applying this change.
Warm regards,
Sriram.
On 11/14/24 9:59 AM, Peter Eisentraut wrote:
I'm more concerned that many of these just keep getting copied around
indiscriminately, and this is liable to hide actual type mismatches or
silently discard qualifiers. So I'm arguing in favor of a more
restrictive style in this matter.
+1 I agre
Thanks to take a look!
On 11/25/24 23:45, Heikki Linnakangas wrote:
On 24/09/2024 08:08, Andrei Lepikhov wrote:
+ * proves the var is unique for this query. However, we'd better
still
+ * believe the null-fraction statistic.
*/
if (vardata->isunique)
stadistinct =
On Wed, Nov 27, 2024 at 4:28 PM Jelte Fennema-Nio wrote:
> On Wed, 27 Nov 2024 at 22:06, Robert Haas wrote:
> > If we had an upper bound on the size of shared_buffers
>
> I think a fairly reliable upper bound is the amount of physical memory
> on the system at time of postmaster start. We could m
On Wed, Nov 27, 2024 at 4:41 PM Andres Freund wrote:
> Strictly speaking we don't actually need to map shared buffers to the same
> location in each process... We do need that for most other uses of shared
> memory, including the buffer mapping table, but not for the buffer data
> itself.
Well, i
Hi, while reviewing another patch I noticed a poorly worded code comment.
Please find the attached trivial fix.
==
Kind Regards,
Peter Smith.
Fujitsu Australia.
v1-0001-Fix-reorderbuffer-code-comment.patch
Description: Binary data
On Thu, Nov 28, 2024 at 07:45:09AM +0900, Tatsuo Ishii wrote:
> Yeah, maybe git apply is not smart enough.
`git apply` is more picky than a simple `patch -p1` as it checks more
context around the patch and is more likely to reject some input.
When the former does not work correctly, I personally j
Hi Nisha. Here are some review comments for patch v51-0002.
==
doc/src/sgml/system-views.sgml
1.
The time when the slot became inactive. NULL if the
-slot is currently being streamed.
+slot is currently being streamed. Once the slot is invalidated, this
+value
I forgot to mention the incremental download
Отправлено из Yahoo Почты на iPhone
Пользователь четверг, ноября 28, 2024, 2:07 AM написал Sergey Prokhorenko
:
It would be useful to add a standard comparative benchmark with several
parameters and use cases to the patch, so that IT departments c
On Wed, Nov 27, 2024 at 04:20:10PM -0500, Bruce Momjian wrote:
> Yeah, I was surprised too, even though the author was clear they wanted
> to backpatch. I couldn't figure out why it was being backpatched, so I
> figured I was missing something.
The set of inconsistencies of how we decide if one c
It would be useful to add a standard comparative benchmark with several
parameters and use cases to the patch, so that IT departments can compare
UUIDv7, ULID, UUIDv4, Snowflake ID and BIGSERIAL for their hardware and
conditions.
I know for a fact that IT departments make such benchmarks of low
>> Sure. The patch for master to v15 look good to me. Unfortunately
>> v5-0001-pgbench-Ensure-previous-progress-message-is-fully-pg13-14.patch
>> applies to v14 but does not apply to v13.
>> $ git checkout REL_13_STABLE
>> Switched to branch 'REL_13_STABLE'
>> Your branch is up to date with 'origi
On Wed, Nov 27, 2024 at 05:09:17PM +, Devulapalli, Raghuveer wrote:
> LGTM.
Committed.
--
nathan
Hi,
On 2024-11-27 16:05:47 -0500, Robert Haas wrote:
> On Wed, Nov 27, 2024 at 3:48 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > My understanding is that clashing of mappings (either at creation time
> > or when resizing) could happen only withing the process address space,
> > and the assu
Hi Nisha, here are my review comments for the patch v51-0001.
==
src/backend/replication/slot.c
ReplicationSlotAcquire:
1.
+ ereport(ERROR,
+ errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
+ errmsg("can no longer get changes from replication slot \"%s\"",
+NameStr(s->data.name)),
+ e
On Wed, 27 Nov 2024 at 22:06, Robert Haas wrote:
> If we had an upper bound on the size of shared_buffers
I think a fairly reliable upper bound is the amount of physical memory
on the system at time of postmaster start. We could make it a GUC to
set the upper bound for the rare cases where people
On Wed, Nov 27, 2024 at 03:54:24PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > I'm very surprised that this was back-patched. I think we should
> > revert it from the back-branches before it gets into a minor release.
> > It seems like a clear definitional change, which has no business in a
>
On Wed, Nov 27, 2024 at 3:48 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> My understanding is that clashing of mappings (either at creation time
> or when resizing) could happen only withing the process address space,
> and the assumption is that by the time we prepare the mapping layout all
>
Robert Haas writes:
> I'm very surprised that this was back-patched. I think we should
> revert it from the back-branches before it gets into a minor release.
> It seems like a clear definitional change, which has no business in a
> minor release.
I was troubled by that too. Maybe this can be pa
On 2024-11-27 15:41:14 -0500, Robert Haas wrote:
> On Tue, Nov 26, 2024 at 7:42 PM Michael Paquier wrote:
> > On Tue, Nov 26, 2024 at 04:24:58PM +0900, Michael Paquier wrote:
> > > Tweaks of the tests across multiple stable branches happen all the
> > > time, and adding one specific to 17~ is no b
> On Wed, Nov 27, 2024 at 10:20:27AM GMT, Robert Haas wrote:
> > >
> > > code, but I'm not sure exactly which points are safe. If we have no
> > > code anywhere that assumes the address of an unpinned buffer can't
> > > change before we pin it, then I guess the check for pins is the only
> > > thin
On Tue, Nov 26, 2024 at 7:42 PM Michael Paquier wrote:
> On Tue, Nov 26, 2024 at 04:24:58PM +0900, Michael Paquier wrote:
> > Tweaks of the tests across multiple stable branches happen all the
> > time, and adding one specific to 17~ is no big issue. I'm in the
> > middle of it but I'm lacking th
> On Tue, Oct 15, 2024 at 12:20:04PM GMT, Yuya Watari wrote:
>
> The previous patches do not apply to the current master, so I have
> attached the rebased version.
Thanks for keeping it up to date.
> v25-0001
> This patch is one of the main parts of my optimization. Traditionally,
> EquivalenceCl
On Wed, Nov 27, 2024 at 01:15:45PM -0500, Corey Huinker wrote:
>
> For people that want to use the old behavior of recomputing _all_
> statistics not just the missing ones, we could add a different switch,
> or an (optional) option to --analyze-in-stages.
>
> The current patchset prov
Kirill Reshke writes:
> On Wed, 27 Nov 2024 at 08:42, jian he wrote:
>> CREATE SCHEMA regress_schema_2 AUTHORIZATION CURRENT_ROLE
>> create domain ss1 as ss
>> create domain ss as text;
>> ERROR: type "ss" does not exist
>>
>> the error message seems not that OK,
>> if we can point out the erro
Hi,
On 2024-11-27 16:33:02 +0300, Nazir Bilal Yavuz wrote:
> I think this is a nice solution and it worked successfully [1]. Now,
> REL_[17 | 16]_* and master branches use the same cache which is
> different from the REL_15_STABLE branch's cache.
>
> In case you want to continue with this, the pa
On Tue, Nov 26, 2024 at 7:11 PM Andrey Borodin wrote:
>
>
>
> > On 27 Nov 2024, at 04:11, Masahiko Sawada wrote:
> >
> > On Tue, Nov 26, 2024 at 1:55 PM Jelte Fennema-Nio
> > wrote:
> >>
> >> On Tue, 26 Nov 2024 at 21:48, Sergey Prokhorenko
> >> wrote:
> >>> gen_uuidv7() is OK
> >>
> >> I'd ve
>
>
> For people that want to use the old behavior of recomputing _all_
> statistics not just the missing ones, we could add a different switch,
> or an (optional) option to --analyze-in-stages.
>
>
The current patchset provides that in the form of the parameter
"--force-analyze", which is a modifi
On Wed, Nov 27, 2024, 17:44 Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2024-Nov-27, Bruce Momjian wrote:
> >> Would there be a default?
>
> > There would be no default. Running with no option given would raise an
> > error. The point is: you want to break scripts currently running
> > --a
On 2024-Nov-27, Tom Lane wrote:
> I do not like the idea of breaking existing upgrade scripts,
> especially not by requiring them to use a parameter that older
> vacuumdb versions will reject. That makes it impossible to have a
> script that is version independent. I really doubt that there is a
John Naylor writes:
> I think you can go ahead and commit 0001-0003. For 0003 I do admit
> being confused why valgrind had a problem with progname...
Pushed, thanks for looking at it!
As for progname, valgrind was unhappy because the local in main()
went out of scope at return, but the malloc bl
Thanks for the updated version, it's really starting to take good shape. A few
small comments on v37 from a a first quick skim-through:
+ if (!strcmp(key, AUTH_KEY))
+ if (*expected_bearer && !strcmp(token, expected_bearer))
Nitpickery but these should be (strcmp(xxx) == 0) to match p
On 2024-10-31 Th 5:10 PM, Jacob Champion wrote:
On Mon, Oct 7, 2024 at 3:45 PM Jacob Champion
wrote:
I've added a 0002 as well.
0002 has since been applied [1] so I'm reattaching v4-0001 to get the
cfbot happy again.
--Jacob
[1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=41b
> Here's what I have staged for commit (except for the commit message, which
> needs some work).
LGTM.
Raghuveer
On Wed, Nov 27, 2024 at 11:44:25AM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2024-Nov-27, Bruce Momjian wrote:
> >> Would there be a default?
>
> > There would be no default. Running with no option given would raise an
> > error. The point is: you want to break scripts currently ru
On Tue, Nov 26, 2024 at 8:38 PM Masahiko Sawada wrote:
> > visibility map: 5 pages set all-visible, 4 pages set all-frozen.
>
> Which means that 5 pages were marked as only all-visible and 4 pages
> were marked as all-frozen (and possibly all-visible too). The total
> number of pages' whose VM sta
On Wed, Nov 27, 2024 at 04:57:35PM +0100, Álvaro Herrera wrote:
> On 2024-Nov-27, Bruce Momjian wrote:
> There would be no default. Running with no option given would raise an
> error. The point is: you want to break scripts currently running
> --analyze-in-stages so that they can make a choice o
> On 21 Nov 2024, at 19:51, Jacob Champion
> wrote:
>
> On Tue, Nov 19, 2024 at 3:05 AM Peter Eisentraut wrote:
>> Personally, I'm not even a fan of the -Dssl/--with-ssl system. I'm more
>> attached to --with-openssl.
In hindsight, --with-ssl was prematurely pulled out from the various TLS
ba
Alvaro Herrera writes:
> On 2024-Nov-27, Bruce Momjian wrote:
>> Would there be a default?
> There would be no default. Running with no option given would raise an
> error. The point is: you want to break scripts currently running
> --analyze-in-stages so that they can make a choice of which of
On Tue, Nov 26, 2024 at 04:47:07PM -0500, Andres Freund wrote:
> LGTM!
Committed.
--
nathan
Hi,
I took a quick look at the patch today. Overall, I think this would be
very useful, I've repeatedly needed to inspect why a backend uses so
much memory, and I ended up triggering MemoryContextStats() from gdb.
This would be more convenient / safer. So +1 to the patch intent.
A couple review
Hi,
On 2024-11-27 14:56:33 +0100, Peter Eisentraut wrote:
> On 26.11.24 17:55, Andres Freund wrote:
> > I think the dump is occasionally useful, so I don't think the best course is
> > to remove it entirely. But I think we could fairly easily improve the
> > situation by emitting all environment v
On Mon, Nov 25, 2024 at 5:52 PM David Rowley wrote:
> OK, thanks. I likely took your neutrality here in a more positive
> light after reading the 4-year-old message at [1]. That probably
> wasn't the right thing to do.
Yeah, I think my view has wavered over time. Probably when I wrote
that messag
On Wed, Nov 27, 2024 at 04:57:35PM +0100, Alvaro Herrera wrote:
> On 2024-Nov-27, Bruce Momjian wrote:
>> Uh, do we have parameters that require a boolean option like this?
>
> I'm not sure what exactly are you asking here.
We do have options like initdb's --sync-method that require specifying o
On Wed, Nov 27, 2024 at 10:28 AM ro b wrote:
> I mean why can't draw the conclusions
> like the case a>1 and a>2 which can be simplified
> to a>2 if the operator > is btree opclass.
This question has already been discussed in some detail on this email
thread. First, we sometimes do detect it, as
On Wed, Sep 11, 2024 at 7:19 AM Nazir Bilal Yavuz wrote:
>
> Currently, in the pg_stat_io view, IOs are counted as blocks. However, there
> are two issues with this approach:
>
> 1- The actual number of IO requests to the kernel is lower because IO
> requests can be merged before sending the fin
On Wed, Nov 27, 2024 at 03:20:19PM +0900, Michael Paquier wrote:
> On Mon, Nov 25, 2024 at 01:29:31PM -0600, Nathan Bossart wrote:
>> Or we could just enforce that you have an active snapshot whenever you
>> modify a catalog with a TOAST table. That's simpler, but it requires extra
>> work in some
Hi!
On 27.11.2024 16:17, Ravi wrote:
Please find the patch attached below for your review.
Thanks & Regards,
Ravi Revathy
Member Technical Staff
ZOHO Corporation
On Wed, 27 Nov 2024 18:41:13 +0530 *Ravi
* wrote ---
Hi Developers,
Currently, PostgreS
Hi,
On Wed, Nov 27, 2024 at 03:33:38PM +0900, Michael Paquier wrote:
> On Mon, Nov 25, 2024 at 03:47:59PM +, Bertrand Drouvot wrote:
> > It also takes care of most of the comments that you have made in [1],
> > meaning
> > that it:
> >
> > - removes the backend type from PgStat_Backend and l
On 2024-Nov-27, Bruce Momjian wrote:
> On Wed, Nov 27, 2024 at 09:18:45AM -0600, Nathan Bossart wrote:
> > > Maybe not remove the option, but add a required parameter:
> > > --analyze-in-stages=all / missing
> > >
> > > That way, if the option is missing, the user can adapt the command line
> >
> On Nov 27, 2024, at 4:57 AM, Peter Eisentraut wrote:
>
> On 26.11.24 15:27, Andrew Dunstan wrote:
>> On 2024-11-19 Tu 6:26 PM, Mark Dilger wrote:
On Nov 16, 2024, at 9:10 AM, Kirill Reshke wrote:
Hi! Can we please have a rebased version of this patch series?
>>> Sorry for th
On Wed, Nov 27, 2024 at 04:33:25PM +0100, Peter Eisentraut wrote:
> On 26.11.24 14:56, Justin Pryzby wrote:
> > Since 811af9786b, the palloc'd idxkey's seem to be leaking/accumulating
> > throughout the command.
> >
> > I noticed this on the master branch while running ANALYZE on partitioned
> > t
On Wed, Nov 27, 2024 at 09:18:45AM -0600, Nathan Bossart wrote:
> On Wed, Nov 27, 2024 at 04:00:02PM +0100, Alvaro Herrera wrote:
> > On 2024-Nov-27, Bruce Momjian wrote:
> >
> >> On Wed, Nov 27, 2024 at 02:44:01PM +0100, Magnus Hagander wrote:
> >> > If you want to avoid both the surprise and con
On Wed, 27 Nov 2024 at 01:42, Michael Paquier wrote:
> I've edited the whole, added this extra test based on \syncpipeline in
> 17~, kept the remaining tests in 14~ where pgbench is able to handle
> them, and backpatched that down to 13. Let's see now what we can do
> with the psql bits.
FYI: it
On 26.11.24 14:56, Justin Pryzby wrote:
Since 811af9786b, the palloc'd idxkey's seem to be leaking/accumulating
throughout the command.
I noticed this on the master branch while running ANALYZE on partitioned
table with 600 attributes, even though only 6 were being analyzed.
LOG: level: 3; Bui
I mean why can't draw the conclusions
like the case a>1 and a>2 which can be simplified
to a>2 if the operator > is btree opclass.
Best regards
From: Robert Haas
Sent: Wednesday, November 27, 2024 22:52
To: ro b
Cc: Peter Geoghegan ; pgsql-hackers
Subject: Re
On Tue, Nov 26, 2024 at 2:18 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> I haven't had a chance to experiment with that on Windows, but I'm
> hoping that in the worst case fallback to a single mapping via proposed
> infrastructure (and the consequent limitations) would be acceptable.
Yeah, i
On Wed, Nov 27, 2024 at 04:00:02PM +0100, Alvaro Herrera wrote:
> On 2024-Nov-27, Bruce Momjian wrote:
>
>> On Wed, Nov 27, 2024 at 02:44:01PM +0100, Magnus Hagander wrote:
>> > If you want to avoid both the surprise and confusion factor mentioned
>> > before,
>> > maybe what's needed is to *remo
Please find the patch attached below for your review.
Thanks & Regards,
Ravi Revathy
Member Technical Staff
ZOHO Corporation
On Wed, 27 Nov 2024 18:41:13 +0530 Ravi wrote ---
Hi Developers,
Currently, PostgreSQL relies on table statistics, extracted within the
examine
Hi,
Newer reviewer here, trying to understand more about the read stream API.
On Tuesday, November 26th, 2024 at 11:07 AM, Nazir Bilal Yavuz
wrote:
> Any feedback would be appreciated.
I've executed the same test of 5 databases with each of them having 1 table of
3GB of size and I've got very
Hi Developers,
Currently, PostgreSQL relies on table statistics, extracted within the
examine_simple_variable function, to estimate join selectivity. However, when
dealing with subqueries that include GROUP BY clauses even for the single
length clauses which result in distinct rows, the pl
Hi,
On Sat, Nov 23, 2024 at 5:14 AM Thomas Munro wrote:
> On Fri, Nov 22, 2024 at 10:55 PM Jakub Wartak
> wrote:
> > but with attached _lseeki64 dirty patch I've got success and resulting
> tarball greater than 2^31 too:
>
>
> For ftruncate(), though you didn't see a problem with that, Jacob
Hello Alvaro,
Tuesday, November 26, 2024, 2:40:39 PM, you wrote:
AH> By the way, how did you find out about this problem? Is this
AH> hypothetical or was there an actual crash? AFAICS (some of?) the
AH> callers get to this code immediately after executing GinInitPage, so
AH> it's not clear to m
Dear PostgreSQL Hackers,
I would like to propose adding support for NOT NULL constraints on
individual fields within composite types, with enforcement *only at rest*
when the composite type is used as a table column. This approach addresses
several key challenges while aligning with PostgreSQL’s e
On Tue, Nov 26, 2024 at 1:58 AM Vallimaharajan G <
vallimaharajan...@zohocorp.com> wrote:
>
> Hi Developers,
> We have discovered a bug in the parallel_vacuum_reset_dead_items
function in PG v17.2. Specifically:
>
> TidStoreDestroy(dead_items) frees the dead_items pointer.
> The pointer is rei
Dear PostgreSQL Development Team,
I’d like to propose a new feature for consideration: schema aliases and
versions
**Problem Statement:**
For migrating old db to new one, one must use an external tool or define a
dedicated migration script where all possible issues could arise
**Proposed Solutio
Hello Alvaro,
Monday, November 25, 2024, 10:51:31 PM, you wrote:
AH> Hmm, I think if we believe this to be really possible, we should have an
AH> 'if/elog' test (or maybe a full ereport with ERRCODE_DATA_CORRUPTED
AH> errcode) rather than an assertion. I think the assertion adds nothing
AH> of v
On 2024-Nov-27, Bruce Momjian wrote:
> On Wed, Nov 27, 2024 at 02:44:01PM +0100, Magnus Hagander wrote:
> > If you want to avoid both the surprise and confusion factor mentioned
> > before,
> > maybe what's needed is to *remove* --analyze-in-stages, and replace it with
> > --analyze-missing-in-st
On Wed, Nov 27, 2024 at 02:44:01PM +0100, Magnus Hagander wrote:
> If you want to avoid both the surprise and confusion factor mentioned before,
> maybe what's needed is to *remove* --analyze-in-stages, and replace it with
> --analyze-missing-in-stages and --analyze-all-in-stages (with the clear
>
On Wed, Nov 27, 2024 at 9:30 AM ro b wrote:
> The path i committed not just test contradictory but also do the
> simplification. The simplification is limited in the BTREE.
> Could you interpret the case in a little more detail.
I am not able to understand this paragraph.
Regretfully,
--
Robe
On 2024-10-17 Th 10:02 PM, Zharkov Roman wrote:
Hello,
Would it be convinient to show the plperl version on the meson setup
summary
screen? Now it displays only 'YES' or 'NO'. This is the expected
behavior of
the meson build system and explains in its source code:
https://github.com/mesonbu
On 2024/11/21 15:43, torikoshia wrote:
Thanks for the update! Agreed.
I think the validator tests related to the on_error option you added are
sufficient.
I've pushed the patch. Thanks!
As for the other file_fdw options, I'm a bit concerned whether it would be
better to add validator tes
Thank you for your advice and guidance.
I didn't know the constraint_exclusion switch existed.
As your advice i need to make what i am doing to be clear.
> There are cases where we don't already draw the necessary conclusions,
> such as a>1 and a>2, which could be simplified to a>2. But those case
On 2024/11/27 18:41, Tatsuo Ishii wrote:
Yes, I will.
But, the patch didn't apply cleanly to some back branches, so I've
created
and attached updated patches for them. Could you review these?
If they look good, I'll proceed with pushing them.
Sure. The patch for master to v15 look good to m
Hi,
Thank you for looking into this!
On Wed, 27 Nov 2024 at 16:50, Matheus Alcantara wrote:
> I've executed the same test of 5 databases with each of them having 1 table of
> 3GB of size and I've got very similar results.
>
> I've also tested using a single database with 4 tables with ~60GB of s
On 26.11.24 17:55, Andres Freund wrote:
I think the dump is occasionally useful, so I don't think the best course is
to remove it entirely. But I think we could fairly easily improve the
situation by emitting all environment variables as a single elog message.
2024-11-26 11:35:58.877 EST [109757
On 2024-Nov-27, Ashutosh Bapat wrote:
> I noticed that. But two reasons why I chose the backend changes
> 1. The comment where we add explicit ADD CONSTRAINT is
> /*
> * Dump additional per-column properties that we can't handle in the
> * main CREATE TABLE command.
> */
> ... snip
>
> /*
> * If
On Wed, 27 Nov 2024 at 14:22, Alena Rybakina wrote:
>
> Sorry it took me so long to answer, I had some minor health complications
>
> On 12.11.2024 23:00, Peter Geoghegan wrote:
>
> On Sun, Nov 10, 2024 at 2:00 PM Alena Rybakina
> wrote:
>
> Or maybe I was affected by fatigue, but I don’t underst
On Tue, Nov 19, 2024 at 1:50 PM Bruce Momjian wrote:
> On Mon, Nov 18, 2024 at 08:42:35PM -0500, Bruce Momjian wrote:
> > On Mon, Nov 18, 2024 at 08:29:10PM -0500, Corey Huinker wrote:
> > > That's not a great surprise for group 6, but I have to believe that
> group is
> > > smaller than group 5,
Hi,
On Fri, 22 Nov 2024 at 20:28, Andres Freund wrote:
> The right approach probably is to include the list of packages in the key. A
> bit annoying to change, because we'd need to move the list of packages to an
> environment variable or file, but doable. I think something like
>
> env:
> MACO
Sorry it took me so long to answer, I had some minor health complications
On 12.11.2024 23:00, Peter Geoghegan wrote:
On Sun, Nov 10, 2024 at 2:00 PM Alena Rybakina
wrote:
Or maybe I was affected by fatigue, but I don’t understand this point, to be
honest. I see from the documentation and yo
On 27.11.2024 15:54, Heikki Linnakangas wrote:
On 27/11/2024 14:46, Ilia Evdokimov wrote:
Hi everyone,
I found typo in comment auto_explain.c line 282 (/* Enable per-node
instrumentation iff log_analyze is required. */).
Not 'iff' but 'if'.
It's short for "if and only if". See
https://e
On 26.11.24 15:27, Andrew Dunstan wrote:
On 2024-11-19 Tu 6:26 PM, Mark Dilger wrote:
On Nov 16, 2024, at 9:10 AM, Kirill Reshke
wrote:
Hi! Can we please have a rebased version of this patch series?
Sorry for the delay, and thanks for your interest. I will try to get
around to rebasing in t
On Wed, 27 Nov 2024 at 13:05, Kirill Reshke wrote:
> ```
> db1=# \startpipeline
> db1=# begin \parse p1
> db1=*#
> ```
> Notice the asterisks that appeared after parse the message. This
> typically indicates we are in the tx block. this is however untrue
> before the bind+exec message for p1 will
1 - 100 of 121 matches
Mail list logo
