On Thu, Mar 6, 2025 at 3:50 PM Nathan Bossart wrote:
> That being said, I do think in-database parallelism would be useful in some
> cases. I frequently hear about problems with huge numbers of large objects
> on a cluster with one big database. But that's probably less likely than
> the many da
On Thu, Mar 6, 2025 at 3:15 PM Michael Paquier wrote:
> I have applied the simplest patch for now, to silence the failures in
> the CI, and included your suggestion to add a check on the
> backend_type for the extra safety it offers.
Thanks! Initial CI run looks green, so that's a good start.
I'
Hi,
On 2025-03-06 14:51:26 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2025-03-06 13:47:34 -0500, Tom Lane wrote:
> >> ... I wonder if we could just rip out pg_upgrade's support
> >> for DB-level parallelism, which is not terribly pretty anyway, and
> >> simply pass the -j switch straig
On Thu, Mar 6, 2025 at 4:18 PM Alena Rybakina wrote:
> To be honest, I initially took it as the total number of tuples and
> couldn't figure out for myself how to interpret the result - 0 tuples or
> 1 tuple in the end. Maybe it wasn't quite correct to perceive it that
> way, but Matthias's explan
On Thu, Mar 6, 2025 at 2:10 PM Andres Freund wrote:
>
> I think it'd be better to use absolute times and store them as such in
> ConnectionTimes or whatever. That way we have information about when a
> connection was established for some future SQL functions and for debugging
> problems.
Attached
On Thu, 6 Mar 2025 at 18:39, Jelte Fennema-Nio wrote:
>
> On Thu, 6 Mar 2025 at 18:10, Tom Lane wrote:
> > Please see if you can make it use patch(1). IME git is too
> > stiff-necked about slightly stale patches no matter which
> > subcommand you use.
>
> It was using patch(1) in the past for th
On Thu, Mar 6, 2025 at 5:12 PM Julien Rouhaud wrote:\
> I indeed don't want to keep lapwing up unless there is any value. Note that
> it
> started to fail on 2 branches after the last buildfarm client update for
> reasons I don't understand. Since everyone is complaining about lapwing
> already
On Thu, Mar 06, 2025 at 02:25:07PM -0800, Jacob Champion wrote:
> On Wed, Mar 5, 2025 at 8:08 PM Michael Paquier wrote:
>> + WHERE state = 'starting' and wait_event = 'init-pre-auth';});
>
> Did you have thoughts on expanding the check to backend_type [1]?
>
>> + # Give up. The output of the l
On Wed, Mar 5, 2025, at 1:40 PM, Andrew Dunstan wrote:
> Just bikeshedding a bit ...
>
> I'm not mad keen on this design. I think the value should be either a single
> setting like "WARNING" or a set of type:setting pairs. I agree that "all" is
> a bad name, but I think "default" would make sens
On Thu, Mar 06, 2025 at 06:25:29PM -0500, Robert Haas wrote:
> On Thu, Mar 6, 2025 at 5:12 PM Julien Rouhaud wrote:\
> > I indeed don't want to keep lapwing up unless there is any value. Note
> > that it
> > started to fail on 2 branches after the last buildfarm client update for
> > reasons I d
On Tue, 25 Feb 2025 at 02:11, Michael Paquier wrote:
> Initial digestion has gone well.
One thing I've noticed is that \startpipeline throws warnings when
copy pasting multiple lines. It seems to still execute everything as
expected though. As an example you can copy paste this tiny script:
\sta
Andres Freund writes:
>And in contrast to analyzing the database in parallel, the pg_dump/restore
>work to restore stats afaict happens single-threaded for each database.
In principle we should be able to do stats dump/restore parallelized
just as we do for data. There are some stumbling
Hayato Kuroda kindly rebased the patch.
v2-0001-WIP-track-wal-segments.patch
Description: application/mbox
On Wed, Mar 5, 2025 at 12:06 PM Alex Friedman wrote:
>
> Good points, thank you. I'm good with going ahead as you've suggested.
Pushed, thanks for the patch!
--
John Naylor
Amazon Web Services
Hi Sawada-San. Here are some review comments for patch v10-0002.
==
src/backend/access/heap/heapam_handler.c
1.
.scan_bitmap_next_block = heapam_scan_bitmap_next_block,
.scan_bitmap_next_tuple = heapam_scan_bitmap_next_tuple,
.scan_sample_next_block = heapam_scan_sample_next_block,
- .s
On 2025/03/07 8:16, Melanie Plageman wrote:
On Thu, Mar 6, 2025 at 2:10 PM Andres Freund wrote:
I think it'd be better to use absolute times and store them as such in
ConnectionTimes or whatever. That way we have information about when a
connection was established for some future SQL functi
Erik Wienhold writes:
> On 2025-03-07 04:05 +0100, Tom Lane wrote:
>> I think the idea of the original coding was to keep those values in
>> registers in the inner loop rather than re-fetching them each time.
> Could be. But the main reason was to hold the output column type as the
> inner loop
>
>
> Patch attached. This patch does NOT change the default; stats are still
> opt-out. But it makes it easier for users to start specifying what they
> want or not explicitly, or to rely on the defaults if they prefer.
>
> Note that the patch would mean we go from 2 options in v17:
> --{schema|
On 2025-03-06 21:56 +0100, Tom Lane wrote:
> jian he writes:
> > if we print out NameStr(att->attname) then error becomes:
> > +DETAIL: Returned type unknown does not match expected type character
> > varying in column "f2" (position 2).
>
> > In this case, printing out {column \"%s\"} is not h
On Thu, 2025-03-06 at 11:15 -0500, Robert Haas wrote:
> To be honest, I am a bit surprised that we decided to enable this by
> default. It's not obvious to me that statistics should be regarded as
> part of the database in the same way that table definitions or table
> data are. That said, I'm not
hi.
rebase only.
From ce0ce6438094cad553e509db65b7fd27de2b9af6 Mon Sep 17 00:00:00 2001
From: jian he
Date: Fri, 7 Mar 2025 11:43:51 +0800
Subject: [PATCH v12 1/1] COPY (on_error set_to_null)
Extent "on_error action", introduce new option: on_error set_to_null.
Current grammar makes us unable to
On Thu, Mar 6, 2025 at 12:57 PM Jacob Champion
wrote:
> Problem 1 is a simple patch. I am working on a fix for Problem 2, but
> I got stuck trying to get a "perfect" solution working yesterday...
> Since this is a partial(?) blocker for getting NetBSD going, I'm going
> to pivot to an ugly-but-sim
On 26/2/2025 13:14, Alexander Korotkov wrote:
On Mon, Feb 24, 2025 at 2:22 PM Andrei Lepikhov wrote:
On 24/2/2025 11:57, Alexander Korotkov wrote:
Could you, please, elaborate more on what you mean by "new technique
of query tree reduction"?
I mean any transformations and optimisations that r
Hi,
On 2025-03-06 10:07:43 -0800, Jeff Davis wrote:
> On Thu, 2025-03-06 at 12:16 -0500, Andres Freund wrote:
> > I don't follow. We already have the tablenames, schemanames and oids
> > of the
> > to-be-dumped tables/indexes collected in pg_dump, all that's needed
> > is to send
> > a list of tho
On Fri, Mar 7, 2025 at 9:57 AM Jacob Champion
wrote:
> 2) macOS's EVFILT_TIMER implementation seems to be different from the
> other BSDs. On Mac, when you re-add a timer to a kqueue, any existing
> timer-fired events for it are not cleared out and the kqueue might
> remain readable. This breaks a
Hi Sawada-San.
FYI. I am observing the following test behaviour:
I apply patch v10-0001, do a clean rebuild and run 'make check', and
all tests are OK.
Then, after I apply just patch v10-0002 on top of 0001, do a clean
rebuild and run 'make check' there are many test fails.
==
Kind Regards,
HI Nathan Bossart Melanie Plageman
Firstly, congratulations on the submission of this path:
https://commitfest.postgresql.org/patch/5320/
vacthresh = (float4) vac_base_thresh + vac_scale_factor * reltuples;
anlthresh = (float4) anl_base_thresh + anl_scale_factor * reltuples;
vacinsthresh = (float
> Interesting. I do see different assembly with the 2 and 4 register
> versions, but I didn't get to testing it on a machine with SVE support
> today.
> Besides some additional benchmarking, I might make some small adjustments
> to the patch. But overall, it seems to be in decent shape.
Sounds
Some minor review comments for patch v10-0001.
==
src/include/access/tableam.h
1.
struct IndexInfo;
+struct ParallelVacuumState;
+struct ParallelContext;
+struct ParallelWorkerContext;
struct SampleScanState;
Use alphabetical order for consistency with existing code.
~~~
2.
+ /*
+ * Esti
Hi,
It seems like there are multiple threads on this topic. This is the
original [0], but I suggest continuing the discussion in this thread
since it includes the examples and patches.
Regarding the issue itself, query jumbling behavior is often subjective,
making it difficult to classify as a bu
Jelte Fennema-Nio writes:
> Okay, I went for the approach of just trying everything until one
> works. Starting with "git am", then patch(1), and as a final attempt
> "git apply".
+1, thanks!
regards, tom lane
Erik Wienhold writes:
> But I don't see the point in keeping variables atttypid and atttypmod
> around when those values are now available via outatt. Removing these
> two variables makes the code easier to read IMO. Done so in the
> attached v4.
I think the idea of the original coding was to k
Hi,
On Wed, Mar 05, 2025 at 11:28:23PM -0800, Masahiko Sawada wrote:
> On Wed, Mar 5, 2025 at 3:10 PM Tom Lane wrote:
> >
> > Bertrand Drouvot writes:
> > > yeah makes sense. Done in the attached, and bonus point I realized that
> > > the
> > > test could be simplified (so, removing useless ste
Hi,
Bertrand Drouvot 于2025年3月5日周三 21:03写道：
> Hi,
>
> On Wed, Mar 05, 2025 at 05:45:57PM +0800, Xuneng Zhou wrote:
> > Subject: Clarification Needed on WAL Pending Checks in Patchset
> >
> > Hi,
> >
> > Thank you for the patchset. I’ve spent some time learning and reviewing
> it
> > and have 2 co
Hi, Alena!
On Sat, Mar 1, 2025 at 1:39 PM Alena Rybakina wrote:
> On 09.02.2025 18:38, Alexander Korotkov wrote:
>>
>> Also, aren't we too restrictive while requiring is_simple_values_sequence()?
>> For instance, I believe cases like this (containing Var) could be
>> transformed too.
>>
>> selec
On Wed, Mar 5, 2025 at 2:35 PM Hayato Kuroda (Fujitsu)
wrote:
>
> I did a performance testing with HEAD and v2-0001, and confirmed that it could
> improve performance around 20% in the typical case.
>
> Workload
> ==
> I emulated a scenario that there are many tables to be published and only o
Hi,
On Wed, Mar 05, 2025 at 05:26:40PM +, Bertrand Drouvot wrote:
> So yeah, back to the issue, we have to pay more attention for the WAL stats
> because pgWalUsage is "incremented" without any check with
> pgstat_tracks_backend_bktype()
> (that's not the case for the IO stats where the count
On 03.03.2025 18:57, Ilia Evdokimov wrote:
hi hackers,
When estimating the selectivity of an OR clause without extended
statistics, we assume that the conditions are independent. However, it
is quite common to see queries like (a = 1 OR a = 2). In such cases,
the assumption of independence
Hi,
On Thu, Mar 06, 2025 at 10:12:37AM +0900, Michael Paquier wrote:
> On Wed, Mar 05, 2025 at 08:04:44AM +, Bertrand Drouvot wrote:
> > On Wed, Mar 05, 2025 at 12:35:26PM +0900, Michael Paquier wrote:
> >> Perhaps there's a point in backpatching a portion of what's in the
> >> attached patch
On Wed, Feb 26, 2025 at 3:01 PM ego alter wrote:
>
> Hi, I’ve had a chance to review the patch. As I am still getting familiar
> with executor part, questions and feedbacks could be relatively trivial.
>
> There are two minor issues i want to discuss:
> 1. The way of caching constraint-checking
Hi,
On 2025-03-05 23:04:29 -0500, Corey Huinker wrote:
> > > I'm uncertain how we'd do that with (schemaname,tablename) pairs. Are you
> > > suggesting we back the joins from pg_stats to pg_namespace and pg_class
> > and
> > > then filter by oids?
> >
> > I was thinking of one query per schema or
On Tue, Mar 4, 2025 at 2:00 PM Andres Freund wrote:
> - pg_stat_aios currently has the IO Handle flags as dedicated columns. Not
> sure that's great?
I don't like the name. Pluralization abbreviations is weird, and it's
even weirder when the abbreviation is not one that is universally
known. Ma
On Fri, 31 Jan 2025 at 19:54, Jelte Fennema-Nio wrote:
>
> At the FOSDEM dev meeting we discussed potential improvements to the
> commitfest app and how to handle deploying future changes with minimal
> disruption to existing workflows. We're going to try a new approach:
> announcing a new commitf
Further to my previous patch to update the licence preamble (
https://www.postgresql.org/message-id/CA%2BOCxoy1Z05qDb1BfZZaVzT%3D6BrEW6u3wxprBkc7pewThJMoCA%40mail.gmail.com),
the attached patch updates the history doc page to properly reflect the use
of the name "Postgres".
Text by Jonathan Katz,
On Wed, Mar 5, 2025 at 12:13 AM Nathan Bossart wrote:
>
> On Tue, Mar 04, 2025 at 01:05:17PM +0700, John Naylor wrote:
> > On Mon, Mar 3, 2025 at 11:21 PM Nathan Bossart
> > wrote:
> >> I did that in v3. I also tried to break up this comment into bullet points
> >> for better separation and log
Hi,
In case of NestLoop with parameterised inner semi-join for each outer
tuple requires only a single tuple from its inner relation to produce a
result. It seems that the same principle applies to an anti-join. This
approach could effectively allow the Memoize node to enhance the
performance
On Thu, 6 Mar 2025 at 12:19, Daniel Gustafsson wrote:
> > On 6 Mar 2025, at 12:05, Dave Page wrote:
> >
> > Further to my previous patch to update the licence preamble (
> https://www.postgresql.org/message-id/CA%2BOCxoy1Z05qDb1BfZZaVzT%3D6BrEW6u3wxprBkc7pewThJMoCA%40mail.gmail.com),
> the attac
On Wed, Mar 5, 2025, at 11:53 PM, Fujii Masao wrote:
> On 2025/03/05 9:33, Euler Taveira wrote:
> >> > +Valid BACKENDTYPE values are
> >> > ARCHIVER,
> >> > +AUTOVACUUM, BACKEND,
> >> > +BGWORKER, BGWRITER,
> >> > +CHECKPOINTER, LOGGER,
> >> > +SLOTSYNCWORKE
Hi,
>
> On 2025-03-04 Tu 7:33 PM, Euler Taveira wrote:
>>> I think it should be acceptable to configure one global setting with
>>> exceptions for particular backend types:
>>>
>>> log_min_messages = WARNING, autovacuum:DEBUG1
>>>
>>> Right now I think the code only accepts the unadorned log level
Here is
0001-Query-ID-Calculation-Fix-Variant-A.patch
and
0001-Query-ID-Calculation-Fix-Variant-B.patch
0001-Query-ID-Calculation-Fix-Variant-B.patch
Description: 0001-Query-ID-Calculation-Fix-Variant-B.patch
0001-Query-ID-Calculation-Fix-Variant-A.patch
Description: 0001-Query-ID-Calculation
On Thu, Mar 6, 2025, at 6:55 AM, Amit Kapila wrote:
> On Wed, Mar 5, 2025 at 4:38 PM Peter Eisentraut wrote:
> >
> > On 11.02.25 21:25, Euler Taveira wrote:
> > > Here is another patch that only changes the GUC name to
> > > max_replication_origin_sessions.
> >
> > I think the naming and descripti
Hi,
On Wed, Mar 05, 2025 at 06:40:10PM -0500, Melanie Plageman wrote:
> On Wed, Mar 5, 2025 at 10:46 AM Melanie Plageman
> wrote:
> >
> > As such, I wonder if my PGC_SET idea is not worth the effort and I
> > should revise the earlier patch version which specified the stages but
> > allow for on,
On Thu, 6 Mar 2025 at 14:18, Alena Rybakina wrote:
>
> Hi! I got a query plan with a strange number of rows. Could you please
> help me understand it?
>
> To be honest I can't understand why 0.50 number of rows here?
Because the scan matched only ~(500 rows over 999 iterations = 500/999
~=) 0.50
Hi,
On 2025-03-04 21:33:39 -0300, Euler Taveira wrote:
> +/*
> + * This must match enum BackendType! It should be static, but
> + * commands/variable.c needs to get at this.
> + */
> +int log_min_messages[] = {
> + [B_INVALID] = WARNING,
> + [B_BACKEND] = WARNING,
> +
> I'm happy with this now, so barring objections or complaints from CI,
> I plan to commit it soon.
Great, thank you!
Hi,
Attached is the v2 patch with the following updates:
1) Added detailed comments atop check_drop_role_dependency() to
clarify role dependencies, addressing Nathan's comment.
2) Fixed a race condition where the dependency check could pass, but a
new dependency might be added before the role dr
On 11/22/23 2:29 AM, Noah Misch wrote:
Something as simple as the following doesn't respond to cancellation. In
v15+, any DROP DATABASE will hang as long as it's running:
Hi,
One of our customers ran into this bug when upgrading from PostgreSQL 14
to PostgreSQL 16. Your commit[1] fixed this
06.03.2025 08:32, Nikhil Kumar Veldanda пишет:
> Hi all,
>
> The ZStandard compression algorithm [1][2], though not currently used for
> TOAST compression in PostgreSQL, offers significantly improved compression
> ratios compared to lz4/pglz in both dictionary-based and non-dictionary
> modes. Att
Hi,
Thanks for developing the good feature.
I've attached a small patch for the documentation of the json_strip_nulls
function. The data type of the 'target' parameter is different between the
implementation and the documentation. The implementation is json_stripe_nulls
(target JSON, ...), but t
> On Mar 5, 2025, at 6:39 PM, Matthias van de Meent
> wrote:
>
> On Wed, 5 Mar 2025 at 18:21, Burd, Greg wrote:
>>
>> Hello,
>>
>> I've rebased and updated the patch a bit. The biggest change is that the
>> performance penalty measured with v1 of this patch is essentially gone in
>> v10.
On 03.03.25 19:45, Matheus Alcantara wrote:
Hi, attached a new v5 with some minor improvements on TAP tests:
- Add a proper test name for all test cases
- Add CREATE EXTENSION command execution
- Change the assert on pg_available_extensions and
pg_available_extension_versions to validate the
Hi,
On 2025-03-05 16:28:21 -0500, Andres Freund wrote:
> Some time recently valgrind suppressions in the older backbranches stopped
> fully working. E.g.
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2025-03-04%2022%3A31%3A25
> failed on 14, with:
>
> [...]
>
> An embarass
Hi,
On 2025-03-06 12:36:43 +0100, Jakub Wartak wrote:
> On Tue, Mar 4, 2025 at 8:00 PM Andres Freund wrote:
> > Questions:
> >
> > - My current thinking is that we'd set io_method = worker initially - so we
> > actually get some coverage - and then decide whether to switch to
> > io_method=sy
On Thu, Mar 6, 2025 at 11:04 AM jian he wrote:
>
> hi.
>
> rearrange the patch.
> v3-0001 and v3-0002 is preparare patches.
> v3-0001 add function: ExecPrepareExprSafe and ExecInitExprSafe.
> v3-0002 add function: DomainHaveVolatileConstraints
>
i actually do need DomainHaveVolatileConstraints
fo
On Wed, Mar 5, 2025 at 9:49 PM Julien Rouhaud wrote:
> FWIW I installed the client version 19.1 this morning and forced a run on HEAD
> and lapwing is back to green.
Thanks, appreciate it.
By the way, is there a particular reason why we're keeping Debian 7
coverage in the buildfarm? I don't want
On Wed, 5 Mar 2025 at 16:50, Jim Jones wrote:
>
> Hi Vignesh
>
> On 05.03.25 10:22, vignesh C wrote:
> > The following "Ready for committer" patches needs rebase
> > ---
> > Truncate logs by max_log_size - Kirill Gavrilov
> >
> > Patch owners, please provide a r
vignesh C writes:
> On Wed, 5 Mar 2025 at 16:50, Jim Jones wrote:
>> Is there something wrong with the commitfest app? This patch applies
>> cleanly and passes all tests
> I verified that it applies neatly and passes the tests for me too, I
> have reported this issue at [1]. I don't know the rea
Hi,
Thank you for the review.
cfbot found a few compiler warnings:
>
> https://cirrus-ci.com/task/6526903542087680
> [16:47:46.964] make -s -j${BUILD_JOBS} clean
> [16:47:47.452] time make -s -j${BUILD_JOBS} world-bin
> [16:49:10.496] lwlock.c: In function ‘CreateLWLocks’:
> [16:49:10.496] lwloc
> On 5 Mar 2025, at 19:32, Álvaro Herrera wrote:
>
> On 2025-Mar-05, Daniel Gustafsson wrote:
>
>> I would avoid using Google for finding content on the wiki, the search
>> function
>> on the wiki itself is generally more reliable. Searching for FOSDEM 2025
>> returns the following as the top
Hi.
Tom Lane писал(а) 2025-02-27 23:40:
Alexander Pyhalov writes:
Now sql functions plans are actually saved. The most of it is a
simplified version of plpgsql plan cache. Perhaps, I've missed
something.
A couple of thoughts about v6:
* I don't think it's okay to just summarily do this:
Hi,
> Overall idea is great.
>
> I just want to mention LZ4 also have API to use dictionary. Its dictionary
> will be as simple as "virtually prepended" text (in contrast to complex
> ZStd dictionary format).
>
> I mean, it would be great if "dictionary" will be common property for
> different alg
Hi,
On 2025-03-05 20:49:33 -0800, Noah Misch wrote:
> > This behaviour makes it really hard to debug problems. It'd have been a lot
> > easier to understand the problem if we'd seen psql's stderr before the test
> > died.
> >
> > I guess that mean at the very least we'd need to put an eval {} aro
On 05/03/2025 01:23, Michael Paquier wrote:
On Tue, Mar 04, 2025 at 05:58:42PM -0500, Andres Freund wrote:
On 2024-12-10 12:00:12 +0200, Heikki Linnakangas wrote:
2. Move the pgstat_bestart() call earlier in the startup sequence, so that a
backend shows up in pg_stat_activity before it acquires
On Wed, Mar 5, 2025 at 4:38 PM Tom Lane wrote:
> v4 has addressed most of my nitpicks, but you still have typedefs
> for ExplainState in both header files. My bet is that at least
> one buildfarm animal will complain about that. I could be wrong
> though, maybe all such compilers are in disuse n
On 11.02.25 00:19, Jacob Champion wrote:
These don't seem right to me. SCRAM passthrough should be considered
as_part_ of the connstr/security checks, but I think it should not
_bypass_ those checks. We have to enforce the use of the SCRAM
credentials on the remote for safety, similarly to GSS de
On Thu, Mar 6, 2025 at 8:30 AM Matthias van de Meent
wrote:
> On Thu, 6 Mar 2025 at 14:18, Alena Rybakina wrote:
> >
> > Hi! I got a query plan with a strange number of rows. Could you please
> > help me understand it?
> >
> > To be honest I can't understand why 0.50 number of rows here?
>
> Beca
[ sorry about having let this thread fall off my radar ]
jian he writes:
> if we print out NameStr(att->attname) then error becomes:
> +DETAIL: Returned type unknown does not match expected type character
> varying in column "f2" (position 2).
> In this case, printing out {column \"%s\"} is no
Hi Robert,
> I think that solving the problems around using a dictionary is going
> to be really hard. Can we see some evidence that the results will be
> worth it?
With the latest patch I've shared,
Using a Kaggle dataset of Nintendo-related tweets[1], we leveraged
PostgreSQL's acquire_sample_r
On 2025-03-06 Th 2:28 PM, Andres Freund wrote:
Hi,
On 2025-03-06 14:13:40 -0500, Tom Lane wrote:
Robert Haas writes:
On Thu, Mar 6, 2025 at 1:07 PM Tom Lane wrote:
Maybe invent a build-farm.conf option like "newest_branch_to_build"?
Yes, that would be nice. I also think we should mandate
On Wed, Mar 5, 2025 at 4:05 AM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Wed, Mar 05, 2025 at 02:42:15PM +0530, Amit Kapila wrote:
> > On Wed, Mar 5, 2025 at 12:47 PM Bertrand Drouvot
> > wrote:
> > >
> > > Agree, PFA a patch doing so.
> > >
> >
> > It would be better if you could add a few comments
On Thu, Mar 6, 2025 at 12:33 PM Peter Eisentraut wrote:
> AFAICT, in pgfdw_security_check(), if SCRAM has been used for the
> outgoing server connection, then PQconnectionUsedPassword() is true, and
> then this check should fail if no "password" parameter was given. That
> check should be expande
On Thu, Mar 6, 2025 at 4:54 PM Melanie Plageman
wrote:
> One thing I've been wishing for recently is access to the discussion
> and lore around individual buildfarm animals in a consolidated place.
> As a new committer, I haven't been part of all of these discussions
> over the last N years and so
On 06.03.2025 17:13, Robert Haas wrote:
On Thu, Mar 6, 2025 at 8:30 AM Matthias van de Meent
wrote:
On Thu, 6 Mar 2025 at 14:18, Alena Rybakina wrote:
Hi! I got a query plan with a strange number of rows. Could you please
help me understand it?
To be honest I can't understand why 0.50 number
Robert Haas writes:
> On Thu, Mar 6, 2025 at 2:13 PM Tom Lane wrote:
>> It's hard to "mandate" anything in a distributed project like this.
>> I don't really see a need to either, at least for cases where an
>> old animal isn't causing us extra work.
> I don't know, to me it feels like we have t
Hi
On Thu, Mar 6, 2025 at 5:35 AM Aleksander Alekseev
wrote:
>
> Hi Nikhil,
>
> Many thanks for working on this. I proposed a similar patch some time
> ago [1] but the overall feedback was somewhat mixed so I choose to
> focus on something else. Thanks for peeking this up.
>
> > test=# select bui
Patch is attached.
0001-Fix-comment-of-tsquerysend.patch
Description: Binary data
Hi,
I've spent some time learning more about jit in the last few weeks and I
think that this patch could be very useful, thanks for working on this!
I'm new on this subject but I would like to share some thoughts about
it.
> 1. Changes in jit-code generation.
>
> a) the load of the absolute addre
On Thu, Mar 06, 2025 at 02:28:20PM -0500, Andres Freund wrote:
> Hi,
>
> On 2025-03-06 14:13:40 -0500, Tom Lane wrote:
> > Robert Haas writes:
> > > On Thu, Mar 6, 2025 at 1:07 PM Tom Lane wrote:
> > >> Maybe invent a build-farm.conf option like "newest_branch_to_build"?
> >
> > > Yes, that would
On Thu, Mar 06, 2025 at 01:04:55PM -0500, Andres Freund wrote:
> To be clear, I think this is a very important improvement that most people
> should use.
+1
> I just don't think it's quite there yet.
I agree that we should continue working on the performance/memory stuff.
> 1) It's a difference
Hi Tom,
On Thu, Mar 6, 2025 at 11:33 AM Tom Lane wrote:
>
> Robert Haas writes:
> > On Thu, Mar 6, 2025 at 12:43 AM Nikhil Kumar Veldanda
> > wrote:
> >> Notably, this is the first compression algorithm for Postgres that can
> >> make use of a dictionary to provide higher levels of compression
On Wed, Mar 5, 2025 at 4:38 PM Peter Eisentraut wrote:
>
> On 11.02.25 21:25, Euler Taveira wrote:
> > Here is another patch that only changes the GUC name to
> > max_replication_origin_sessions.
>
> I think the naming and description of this is still confusing.
>
...
...
>
> I agree that the orig
Hi,
while running check-world on 64-bit arm (rpi5 with Debian 12.9), I got a
couple reports like this:
==64550== Use of uninitialised value of size 8
==64550==at 0xA62FE0: wrapper_handler (pqsignal.c:107)
==64550==by 0x580BB9E7: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==64550=
On 06.03.25 11:55, Shay Rojansky wrote:
For whatever it's worth, I'll note that SQL Server's OPENJSON does do
this (so when a JSON string property is extracted as a binary type,
base64 encoding is assumed). Other databases also have very specific
documented conversion rules for JSON_VALUE RETUR
On Thu, Mar 6, 2025 at 9:29 AM Andres Freund wrote:
> But TBH, I do wonder how much the current memory usage of the statistics
> dump/restore support is going to bite us. In some cases this will dramatically
> increase pg_dump/pg_upgrade's memory usage, my tests were with tiny amounts of
> data an
Thanks for the continued review!
Attached v11 has a test added (passes locally but fails in CI, so I
have to fix that).
I still need to do some more manual testing and validation.
On Thu, Mar 6, 2025 at 9:56 AM Bertrand Drouvot
wrote:
>
<-- snip -->
> what do you think about also doing?
>
>
On 2025-03-06 Th 10:45 AM, Robert Haas wrote:
On Wed, Mar 5, 2025 at 9:49 PM Julien Rouhaud wrote:
FWIW I installed the client version 19.1 this morning and forced a run on HEAD
and lapwing is back to green.
Thanks, appreciate it.
By the way, is there a particular reason why we're keeping D
Hi,
On 2025-03-06 12:04:25 -0500, Corey Huinker wrote:
> > > If there's value in freeing them, why isn't it being done already? What
> > > other thing would consume this freed memory?
> >
> > I'm not saying that they can be freed, they can't right now. My point is
> > just
> > that we *already* ke
Re: To PostgreSQL Hackers
> I cannot reproduce the problem on the Debian mipsel porter box, and
> the (working) test does not leave the base.tar.zst mentioned about
> behind.
Since I don't have access to the machine where it is failing, I
uploaded a new version that base64-encodes the "bad" base.t
On Thu, Mar 6, 2025 at 1:07 PM Tom Lane wrote:
> If there were some trivial way to do that, it'd be more acceptable.
> Maybe invent a build-farm.conf option like "newest_branch_to_build"?
> branches_to_build covers some adjacent territory, but its filtering
> options go the wrong way (only branche
On Thu, Mar 6, 2025 at 1:17 PM Peter Geoghegan wrote:
> The immediate problem is that when the parallel leader doesn't
> participate, there is no valid IndexScanDescData in planstate to work
> off of. There isn't an obvious way to get to shared memory from the
> leader process, since that all goes
1 - 100 of 136 matches
Mail list logo
