On Thu, Feb 27, 2025 at 3:53 AM Devulapalli, Raghuveer
wrote:
> > I'm not a fan of exposing these architecture-specific details to places
> > that consult
> > the capabilities. That requires things like
> >
> > +#define PGCPUCAP_CRC32C pg_cpu_have(PG_CPU_FEATURE_SSE42)
> > [...]
> > +#define PGC
On Wed, 26 Feb 2025 at 23:21, Sadeq Dousti wrote:
>
> Thanks a lot Greg!
>
> > Changes look good to me, thanks. Can you make a new patch that applies a
> > single set of changes to HEAD?
>
> Please find attached the diff to Head in a single file.
Currently we are supporting only PG13 and higher
On Tue, Feb 25, 2025 at 08:54:31AM -0300, Ranier Vilela wrote:
> @@ -455,7 +455,9 @@ set_locale_and_encoding(void)
> locale->db_locale,
> strlen(locale->db_locale));
> else
> - datlocale_literal = pg_strdup("NULL");
> + datlocale_literal = PQescapeLiteral(conn_new_template1,
> + "NULL",
> + s
Hi,
On Wed, Feb 26, 2025 at 05:08:17AM -0500, Andres Freund wrote:
> Hi,
>
> On 2025-02-26 15:37:10 +0900, Michael Paquier wrote:
> > That's bad, worse for a logical WAL sender, because it means that we
> > have no idea what kind of I/O happens in this process until it exits,
> > and logical WAL
Hi,
On Wed, Feb 26, 2025 at 01:45:39PM -0500, Melanie Plageman wrote:
> Thanks for the continued review!
>
> On Wed, Feb 26, 2025 at 2:41 AM Bertrand Drouvot
> wrote:
> >
> > On Wed, Feb 26, 2025 at 01:46:19PM +0900, Fujii Masao wrote:
> > >
> > > With the current patch, when log_connections is
On 04/02/2025 19:14, Guillaume Lelarge wrote:
On 04/02/2025 17:59, Tom Lane wrote:
Guillaume Lelarge writes:
v2 is attached.
This seems pretty much entirely useless to me. The password
has already been leaked to the log (*and* the network, if
session is unencrypted), so what's the point of
Hi,
On Thu, Feb 27, 2025 at 12:02:51PM +0900, Michael Paquier wrote:
> 0001 was OK, so done.
Thanks!
> In 0002, couldn't it be better to have the pg_stat_get_backend_stats()
> static in pgstatfuncs.c? In 0003, pg_stat_get_backend_wal() is also
> in pgstatfuncs.c, meaning that all the callers of
Dear Amit,
> Shouldn't such a check be present in the CheckSlotPermissions() kind
> of function to perform it in the central place?
OK. I checked whether we can reuse pre-existing functions, but it seems not
appropriate.
CheckSlotPermissions() is called even by pg_drop_replication_slot(), and
Ch
Thank you for the clarification, and the well-worded paragraph. Please find
the latest patch files attached.
Best regards,
Andy Alsup
On Tue, Feb 25, 2025 at 12:41 PM Laurenz Albe
wrote:
> On Mon, 2025-02-24 at 21:04 -0500, Andy Alsup wrote:
> > Please find the attached patch, which only addres
On Wed, Feb 26, 2025 at 07:04:25PM +0530, vignesh C wrote:
> On Tue, 18 Feb 2025 at 18:18, Ranier Vilela wrote:
>> Similar to commit 5b94e27 [1]
>> The correct function when freeing memory in the frontend,
>> using the function PQescapeIdentifier, must be
>> PQfreemem.
>>
>> Trivial patch attached
On Mon, Feb 03, 2025 at 12:22:52PM +0100, Peter Eisentraut wrote:
> CF 2025-01 has just ended, so I suggest that everyone try this now. We can
> check in perhaps two weeks whether this results in lots of stuff falling
> through the cracks or still too much stuff with unclear status being moved
> f
On Tue, Feb 25, 2025 at 7:33 PM Amit Kapila wrote:
>
> On Tue, Feb 25, 2025 at 11:21 PM Masahiko Sawada
> wrote:
> >
> > On Tue, Feb 25, 2025 at 2:36 AM Amit Kapila wrote:
> > >
> > > >
> > > > Scenario-3: the source gets invalidated after creating the copied slot
> > > > (i.e. after create_log
Hi, all
When I read the code of pqcomm.c, I find we don't use anything from
after commit cba5b994c99. Maybe we should remove the include instruction.
diff --git a/src/backend/libpq/pqcomm.c b/src/backend/libpq/pqcomm.c
index e5171467de1..744699ec35a 100644
--- a/src/backend/libpq/pqcomm.c
+++
On 2025/02/21 10:28, Fujii Masao wrote:
On 2025/02/20 15:27, Yuki Seino wrote:
On 2025/02/19 1:08, Fujii Masao wrote:
Just an idea, but how about updating ConditionalXactLockTableWait()
to do the followings?
- Use LockAcquireExtended() instead of LockAcquire() to retrieve the
LOCALLOCK va
Hi,
I would like to share a script that determines code coverage of
functions that are directly accessible from SQL.
To use the script you have to build a code coverage report first, as usual:
```
git clean -dfx
meson setup --buildtype debug -DPG_TEST_EXTRA="kerberos ldap ssl"
-Db_coverage=true
On 26/02/2025 08:41, Bertrand Drouvot wrote:
Hi,
On Wed, Feb 26, 2025 at 01:46:19PM +0900, Fujii Masao wrote:
On 2025/02/26 6:36, Melanie Plageman wrote:
On Tue, Feb 25, 2025 at 3:23 PM Melanie Plageman
wrote:
Thanks for doing this! I have implemented your suggestion in attached v3.
Tha
On 18.02.25 09:34, Jelte Fennema-Nio wrote:
On Thu, 27 Jun 2024 at 12:43, Jelte Fennema-Nio wrote:
Attached is a rebased patchset of my previous proposal, including a
few changes that Michael preferred:
Rebased again. (got notified because of the new commitfest rebase emails)
The first patch
On Wed, Feb 26, 2025 at 11:17:06AM -0500, Robert Treat wrote:
> It strikes me as a bit odd to have this extra wording in the pg_class
> documentation:
>
> + Every all-frozen page must also be marked
> + all-visible in the visibility map, so
> + relallfrozen should be less than or equal
Thanks a lot Greg!
> Changes look good to me, thanks. Can you make a new patch that applies a
single set of changes to HEAD?
Please find attached the diff to Head in a single file.
Best Regards,
Sadeq Dousti
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index cedcc
On Wed, 2025-02-26 at 13:06 -0500, Tom Lane wrote:
> Jeff Davis writes:
> > I ran a quick measurement and it appears within the noise of the
> > numbers I posted here:
> > https://www.postgresql.org/message-id/6af48508a32499a8be3398cafffd29fb6188c44b.ca...@j-davis.com
>
> Thanks for doing that.
Thanks for the continued review!
On Wed, Feb 26, 2025 at 2:41 AM Bertrand Drouvot
wrote:
>
> On Wed, Feb 26, 2025 at 01:46:19PM +0900, Fujii Masao wrote:
> >
> > With the current patch, when log_connections is enabled, the connection
> > time is always
> > captured, and which might introduce per
Hi,
Thanks for working on this patch!
I looked at the patch from and I have several comments. There are
some others, but wanted to start with the most important I found, in order
of importance.
1/ The use of NOTICE to propagate the explain plan.
I see the message content is checked, but this doe
On Fri, Feb 21, 2025 at 5:09 PM Robert Haas wrote:
>
> On Fri, Feb 21, 2025 at 7:04 PM Tom Lane wrote:
> > A very significant fraction of the buildfarm is now pink.
> > If you don't have a fix pretty nearly ready, please revert.
>
> When we're going to do a release, you want no commits for at lea
Hi!
I am (still) very unsure if the code change I mentioned will make sense,
but documentation chage could perhaps look like something along these lines?
Best regards, Dmytro
On Tue, Feb 25, 2025 at 9:14 PM Dmytro Astapov wrote:
> Hi!
>
> I've been investigating why postgres does not do Bit
On Wed, Feb 26, 2025 at 4:46 AM Richard Guo wrote:
> I agree that it'd be beneficial to make some improvements to NOT IN
> subqueries. From what I can see, we may have two potential options:
>
> * As Tom mentioned, we can prove that the subquery's output never
> contains NULL values and then conv
hI
I can confirm 60% speedup for execution of function fx and fx3 - both
functions are very primitive, so for real code the benefit can be higher
Unfortunately, there is about 5% slowdown for inlined code, and for just
plpgsql code too.
I tested fx4
create or replace function fx4(int) returns i
On Wed, Feb 26, 2025 at 1:45 PM Melanie Plageman
wrote:
>
> Thanks for the continued review!
>
> On Wed, Feb 26, 2025 at 2:41 AM Bertrand Drouvot
> wrote:
>
> > Add a few words in the log_connections GUC doc? (anyway we will have to if
> > Fujii-san idea above about the timing is implemented)
>
>
On Tue, Feb 25, 2025 at 6:41 PM Corey Huinker wrote:
>
> 0003 - converting some of the deleted pg_set* tests into pg_restore* tests to
> keep the error coverage that they had.
I haven't really followed this thread and am not sure where the right
place is to drop this question, so I'll just do it
Tom Lane wrote:
> > I got nerd-sniped by this question and spent some time looking into
> > it.
Thank you for the patch! LGTM.
Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
Changes look good to me, thanks. Can you make a new patch that applies a
single set of changes to HEAD?
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
On Tue, 18 Feb 2025 at 18:18, Ranier Vilela wrote:
>
> Hi.
>
> Similar to commit 5b94e27 [1]
> The correct function when freeing memory in the frontend,
> using the function PQescapeIdentifier, must be
> PQfreemem.
>
> Trivial patch attached.
Thanks, this change looks good to me.
Regards,
Vignes
On Wed, Feb 26, 2025 at 5:40 PM Nisha Moond wrote:
>
> Attached the patch v1 fixing this issue.
>
> Issue reported by: Hou Zhijie.
>
Thanks for the report and patch. I'll look into it.
--
With Regards,
Amit Kapila.
On 2025/02/26 13:09, Sagar Shedge wrote:
However, if PGconn is NULL, it seems like postgres_fdw_get_connections()
wouldn't include that connection in the result. If the connection status
is not CONNECTION_OK, it looks like the connection would be closed by
pgfdw_reset_xact_state() before the l
Peter Eisentraut writes:
> I think the additions to typedefs.list are useless. Since nothing
> actually uses these types, the collection on the buildfarm won't find
> any uses of them and thus won't include it in its list, and then the
> next update from the buildfarm will overwrite your chang
On Wed, Feb 26, 2025 at 12:31 AM Srinath Reddy
wrote:
> i was actually trying to recreate power outage scenario using
>>> node->kill9(),node->start() in a custom tap test,then i found this crash.
>>
>>
LOL ,that's not a power outage test, that's a kill -9 postgres test. A true
power outage would
Corey Huinker writes:
> 0001 - Add attnum support to attribute_statistics_update
> * Basically what Tom posted earlier, minus the pg_set_attribute_stats
> stuff, obviously.
> 0002 - Add attnum support to pg_dump.
> * Removed att_stats_arginfo
> * Folds appendRelStatsImport and appendAttStatsImport
On Wed, 2025-02-26 at 11:13 -0500, Tom Lane wrote:
> Cool. Jeff, are you taking these, or shall I?
Please go ahead.
I think you had mentioned upthread something about getting rid of the
table-driven logic, which is fine with me. Did you mean for that to
happen in this patch as well?
Regards,
On Tue, Feb 25, 2025 at 4:29 PM Melanie Plageman
wrote:
>
> On Tue, Feb 25, 2025 at 11:36 AM Greg Sabino Mullane
> wrote:
> >
> > On Tue, Feb 25, 2025 at 11:03 AM Melanie Plageman
> > wrote:
> >>
> >> Because users can now manually update these values in pg_class, there
> >> wouldn't be a way
Jeff Davis writes:
> I think you had mentioned upthread something about getting rid of the
> table-driven logic, which is fine with me. Did you mean for that to
> happen in this patch as well?
Per Corey's description of the patch (I didn't read it yet), some
of that already happened. I want to g
Hi John,
Thanks for reviewing.
It seems at a minimum this one-line patch is sufficient for the correction:
- storage occupied by multixacts members exceeds 2GB, aggressive vacuum
+ storage occupied by multixacts members exceeds about 10GB,
aggressive vacuum
Commit c552e171d16e removed
On Wed, 2025-02-26 at 04:25 -0500, Corey Huinker wrote:
> 0001 - Add attnum support to attribute_statistics_update
>
> * Basically what Tom posted earlier, minus the pg_set_attribute_stats
> stuff, obviously.
Should have a couple simple tests.
And I would use two different error message wordings
Jeff Davis writes:
> I ran a quick measurement and it appears within the noise of the
> numbers I posted here:
> https://www.postgresql.org/message-id/6af48508a32499a8be3398cafffd29fb6188c44b.ca...@j-davis.com
Thanks for doing that. I agree with your other comments and
will incorporate them.
Hi,
This small doc change patch is following up on a past discussion about
discrepancies between state and wait_event in pg_stat_activity:
https://www.postgresql.org/message-id/flat/ab1c0a7d-e789-5ef5-1180-42708ac6fe2d%40postgrespro.ru
As this kind of question is raised by PG users from time
Hi,
On Wed, Feb 26, 2025 at 02:05:59PM +0100, Jakub Wartak wrote:
> On Wed, Feb 26, 2025 at 10:58 AM Andres Freund wrote:
> >
> > Hi,
> >
> > On 2025-02-26 09:38:20 +0100, Jakub Wartak wrote:
> > > > FWIW, what you posted fails on CI:
> > > > https://cirrus-ci.com/task/5114213770723328
> > > >
>
On Wed, Feb 26, 2025 at 11:23 AM Tom Lane wrote:
> Jeff Davis writes:
> > I think you had mentioned upthread something about getting rid of the
> > table-driven logic, which is fine with me. Did you mean for that to
> > happen in this patch as well?
>
> Per Corey's description of the patch (I di
Thanks for the review!
On Tue, Feb 25, 2025 at 11:46 PM Fujii Masao
wrote:
>
> On 2025/02/26 6:36, Melanie Plageman wrote:
> > On Tue, Feb 25, 2025 at 3:23 PM Melanie Plageman
> > wrote:
>
> + /* Capture time Postmaster initiates fork for logging */
> + if (child_type == B_BACKEND)
>
On Wed, Feb 12, 2025 at 5:14 PM ahmedashour wrote:
>
> Thank you for your feedback and review! I have addressed the comments and
> updated the patch accordingly. Below are the details of the changes:
>
> Please review the updated patch and let me know if there are any further
> issues or suggest
I am not sure if the wait_event vs state relationship needs to
be documented specifically. I can think of another discrepancy
such as query_id = NULL and state = active, which occurs when
the query is still being parsed and jumbled and a query_id is not yet
available. There are probably other ephe
On Mon, Feb 24, 2025 at 3:36 PM Andres Freund wrote:
> I suspect that this is a *really* bad idea. It's very very hard to get inplace
> updates right. We have several unfixed correctness bugs that are related to
> the use of inplace updates. I really don't think it's wise to add additional
> inte
While working on the progress reporting, I've been looking into the
performance results, particularly why the parallelism doesn't help much
for some indexes - e.g. the index on the headers JSONB column.
CREATE INDEX headers_jsonb_idx
ON messages USING gin (msg_headers);
In this case the paral
On Wed, 2025-02-26 at 15:15 -0500, Robert Haas wrote:
> I strongly agree. I think shipping this feature in any form that uses
> in-place updates is a bad idea.
Removed already in commit f3dae2ae58.
The reason they were added was mostly for consistency with ANALYZE, and
(at least for me) secondari
On Wed, Feb 26, 2025 at 3:37 PM Jeff Davis wrote:
> On Wed, 2025-02-26 at 15:15 -0500, Robert Haas wrote:
> > I strongly agree. I think shipping this feature in any form that uses
> > in-place updates is a bad idea.
>
> Removed already in commit f3dae2ae58.
Cool.
> The reason they were added was
On 26/02/2025 22:00, Sami Imseih wrote:
If we do need to document anything, which I am not convinced we should,
it should be more generic.
Thanks for the feedback, I've attached a v2 patch which has wording that's a bit
more generic.
It's also worth noting that pg_locks already has a full pa
Hi
And here is a proposed code change, alternative to the doc change.
I hope that it is ok to relax the restriction like so, as
`cost_bitmap_node_and` is already resigned to inputs not being independent:
* We estimate AND selectivity on the assumption that the inputs are
* independent. This is p
Attached v10 with minor changes based on the feedback.
> Thanks, I think this is a good direction. Some comments:
>
> #if defined(HAVE__GET_CPUID)
> __get_cpuid(1, &exx[0], &exx[1], &exx[2], &exx[3]); #elif defined(HAVE__CPUID)
> __cpuid(exx, 1); #endif
Oh yeah good catch. Fixed in v10.
> +
On Tue, Feb 25, 2025 at 9:33 AM Andres Freund wrote:
> Does anybody see a reason we shouldn't lower temp_buffers to match
> shared_buffers?
I do not see any such reason. I'd say go for it.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, 2025-02-26 at 15:57 -0500, Robert Haas wrote:
> If you feel it can be done without breaking anything else,
> or you have a way to repair the breakage, I'd definitely be
> interested
> in hearing more about that.
That would be a separate thread, but it's good to know that there is a
general
On Wed, Feb 26, 2025 at 12:25 PM Nathan Bossart
wrote:
>
> On Wed, Feb 26, 2025 at 11:17:06AM -0500, Robert Treat wrote:
> > It strikes me as a bit odd to have this extra wording in the pg_class
> > documentation:
> >
> > + Every all-frozen page must also be marked
> > + all-visible in the v
Jeff Davis writes:
> That would be a separate thread, but it's good to know that there is a
> general consensus that we don't want to use in-place updates for non-
> critical things like stats (and perhaps eliminate them entirely). In
> other words, the inconcistency likely won't last forever.
I'
Melanie Plageman writes:
> I have a patch that is getting thwacked around by the churn in
> stats_import.sql, and it occurred to me that I don't see why all the
> negative tests for pg_restore_relation_stats() need to have all the
> parameters provided. For example, in both of these tests, you ar
On Tue, Feb 25, 2025 at 9:28 AM Jelte Fennema-Nio wrote:
> So to be clear: the current patchset *does not* change any client
> defaults. libpq will still connect to a server using the protocol
> version 3.0 by default. It will only connect with 3.2 unless
> instructed explicitly in the connection
Robert Haas writes:
> I'm not quite sure, either. I think that the first option (proving
> that there can be no NULL values) is probably more similar to
> thingswe've done elsewhere in the planner, so I think I have been
> assuming that if we did something about this, it would be that.
Yeah. The
Hi,
I have noticed one of my buildfarm machines - widowbird - did not report
any results since February 17. And it seems to be stuck somewhere in
amcheck:
$ ps ax | grep postgres
1180067 ?Ss 0:02
/mnt/data/buildfarm/buildroot/HEAD/inst/bin/postgres -D data-C
1180069 ?Ss 0:
>
> I have a patch that is getting thwacked around by the churn in
> stats_import.sql, and it occurred to me that I don't see why all the
> negative tests for pg_restore_relation_stats() need to have all the
> parameters provided. For example, in both of these tests, you are
> testing the relation
On Wed, Feb 26, 2025 at 4:46 PM Tom Lane wrote:
> Melanie Plageman writes:
> > I have a patch that is getting thwacked around by the churn in
> > stats_import.sql, and it occurred to me that I don't see why all the
> > negative tests for pg_restore_relation_stats() need to have all the
> > para
On Wed, Feb 26, 2025 at 10:55 PM Andres Freund wrote:
> I was working on expanding tests for AIO and as part of that wrote a test for
> temp tables -- our coverage is fairly awful, there were many times during AIO
> development where I knew I had trivially reachable temp table specific bugs
> but
On Wed, Feb 26, 2025 at 5:16 PM Tomas Vondra wrote:
> Oh, I forgot about that. I guess if the theory is the commit might be
> causing this, and it's been already reverted, I should just restart the
> instance, so that it tests with the revert.
According to the revert commit's commit message there
On Wed, Feb 26, 2025 at 5:09 PM Tomas Vondra wrote:
> So, it's stuck in AdvanceXLInsertBuffer ... interesting. Another
> interesting fact is it's testing 75dfde13639, which is just a couple
> commits after 6a2275b895:
> which reworked AdvanceXLInsertBuffer() quite a bit, it seems. OTOH the
> last
On 2/26/25 23:13, Peter Geoghegan wrote:
> On Wed, Feb 26, 2025 at 5:09 PM Tomas Vondra wrote:
>> So, it's stuck in AdvanceXLInsertBuffer ... interesting. Another
>> interesting fact is it's testing 75dfde13639, which is just a couple
>> commits after 6a2275b895:
>
>> which reworked AdvanceXLInse
Hi all,
I’m a beginner contributor reviewing patch 5381 from Commitfest 52.
Here’s my feedback:
- Applied the patch to the master branch (as of Feb 26, 2025) using
`patch -p1 < 5381.patch`.
- It updates doc/src/sgml/pgstattuple.sgml, adding a paragraph about
`leaf_fragmentation`.
- Built the HTML
On Wed, Feb 26, 2025 at 05:23:51PM -0500, Peter Geoghegan wrote:
> According to the revert commit's commit message there was also
> problems on batta at the time. Might have been the same issue that you
> saw on widowbird. Alexander?
This problem has already been discussed, and I saw the same back
On Wed, 2025-02-26 at 13:27 -0800, James Hunter wrote:
> Attaching a new refactoring, which splits the code changes into
> patches by functionality. This refactoring yields 5 patches, each of
> which is relatively localized. I hope that the result will be more
> focused and more feasible to review.
On Wed, Feb 26, 2025 at 12:33:16PM +0300, Maxim Orlov wrote:
> Done. Except for a new name for "logit" variable. Unfortunately, I can't
> think of anything sane. As an example I looked at sequence.c. The same name
> is used there. I will gladly change this name to whatever you want if it
> still lo
On Wed, Feb 26, 2025 at 4:58 PM Tom Lane wrote:
> Yeah. The key problem blocking doing something about it in the
> planner is that at the time we want to do join tree restructuring,
> we haven't yet collected the per-relation data that would allow
> us to know about NOT NULL constraints, nor run
Robert Haas writes:
> On Wed, Feb 26, 2025 at 4:58 PM Tom Lane wrote:
>> Yeah. The key problem blocking doing something about it in the
>> planner is that at the time we want to do join tree restructuring,
>> we haven't yet collected the per-relation data that would allow
>> us to know about NOT
On Thu, 27 Feb 2025 at 14:55, Tom Lane wrote:
> But I think having NOT NULL info available earlier might allow
> removal of some nasty kluges (I'm looking at you,
> restriction_is_always_true).
Can you elaborate on the gripe here, or point to the thread where you have?
David
>
> +1, let's shorten those queries. The coast is probably pretty
>> clear now if you want to go do that.
>
>
> On it.
>
The earlier conversion of pg_set_attribute_stats (which once had many
not-null params) to pg_restore_* tests (where only the columns that
identify the stat row are actually req
David Rowley writes:
> On Thu, 27 Feb 2025 at 14:55, Tom Lane wrote:
>> But I think having NOT NULL info available earlier might allow
>> removal of some nasty kluges (I'm looking at you,
>> restriction_is_always_true).
> Can you elaborate on the gripe here, or point to the thread where you have
On Wed, Feb 26, 2025 at 10:59:11AM +, Bertrand Drouvot wrote:
> Yup. That's what we've done in pg_stat_io_build_tuples() too (ff7c40d7fd6).
> Without this we'd get "2000-01-01 00:00:00+00" in the stats_reset field of
> pg_stat_get_backend_wal() and pg_stat_get_backend_io().
Right, forgot about
On Wed, Feb 26, 2025 at 05:08:17AM -0500, Andres Freund wrote:
> I think it's also bad that we don't have a solution for 1), even just for
> normal connections. If a backend causes a lot of IO we might want to know
> about that long before the longrunning transaction commits.
>
> I suspect the rig
Michael, thanks a lot for the detailed explanation.
> On 26 Feb 2025, at 11:57, Maxim Orlov wrote:
>
> Indeed. PFA the correct one.
>
>
I’d suggest to give some more descriptive name to “logit” and expand comment
“/* sanity check */“. This comment was easier to understand when elog() was
ne
Hi,
On Wed, Feb 26, 2025 at 04:52:13PM +0900, Michael Paquier wrote:
> On Tue, Feb 25, 2025 at 03:00:35PM +, Bertrand Drouvot wrote:
> > That makes fully sense. Done in 0004 attached. Somehow related to that, I've
> > a patch in progress to address some of Rahila's comments ([1]) (the one
> >
On 20.02.2025 03:32, Sami Imseih wrote:
As you can see, the query has not been normalized. Is it a bug, expected or
undefined behavior?
No, this behavior is expected. The ability to normalize a statement is
only available
during post_parse_analyze (pgss_post_parse_analyze), as this is when
we
On Wed, 2025-02-26 at 18:08 +0800, Tender Wang wrote:
> Recently, I found Greenplum implement pull-up NOT IN subquery.
> They have the below comments in their codes:
>
> We normalize NOT subqueries using the following axioms:
> *
> * val NOT IN (subq) => val <> ALL (subq)
That is true, but I
On Wed, 26 Feb 2025 at 11:54, Andres Freund wrote:
>
> 4) Do compaction incrementally, instead of doing it for all requests at
> once.
Yeah, good idea! I completely forgot about that. Thanks!
--
Best regards,
Maxim Orlov.
Masahiko Sawada writes:
> On Tue, Feb 25, 2025 at 3:03 PM Dagfinn Ilmari Mannsåker
> wrote:
>>
>> Hi,
>>
>> While working on another round of the long option and fat comma style
>> cleanup, I noticed that the test for pg_upgrade --set-char-signedess
>> doesn't test what it's supposed to:
>>
>> M
On Wed, 26 Feb 2025 at 14:35, Amit Kapila wrote:
>
> How about changing it slightly as follows to make it clear: "If
> -doption is not provided, the database name will be
> obtained from -P. If the database name is not
> specified in either the -d option or
> -P, an error will be reported."?
Look
Hi, Michael!
On Wed, Feb 26, 2025 at 3:04 AM Michael Paquier wrote:
>
> On Tue, Feb 25, 2025 at 05:19:29PM +0200, Alexander Korotkov wrote:
> > It seems that I managed to reproduce the issue on my Raspberry PI 4.
> > After running our test suite in a loop for 2 days I found one timeout.
>
> Hmm.
On Wed, Feb 26, 2025 at 12:05 AM Tom Lane wrote:
> Corey Huinker writes:
> > Just to confirm, we ARE able to assume dense packing of attributes in an
> > index, and thus we can infer the attnum from the position of the attname
> in
> > the aggregated array, and there's no need to do a parallel a
On Tue, 25 Feb 2025 at 22:44, Ekaterina Sokolova
wrote:
> Hi, hackers!
>
> Historically, the checkpointer process use palloc() into
> AbsorbSyncRequests() function. Therefore, the checkpointer does not
> expect to receive a request larger than 1 GB.
Yeah. And the most unpleasant thing is it won
On Mon, Feb 24, 2025 at 5:11 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Mon, Feb 24, 2025 at 09:06:20AM -0500, Andres Freund wrote:
> > Does the issue with "new" backends seeing pages as not present exist both
> > with
> > and without huge pages?
>
> That's a good point and from what I can see it'
> On 25 Feb 2025, at 20:19, Alexander Korotkov wrote:
>
>
Hi!
One little piece of code looks suspicious to me. But I was not raising concern
because I see similar code everywhere in the codebase. But know Kirill asked to
me explain what is going on and I cannot.
This seems to be relevan
Hi,
On 2025-02-26 11:46:45 +0300, Maxim Orlov wrote:
> On Tue, 25 Feb 2025 at 22:44, Ekaterina Sokolova
> wrote:
>
> > Hi, hackers!
> >
> > Historically, the checkpointer process use palloc() into
> > AbsorbSyncRequests() function. Therefore, the checkpointer does not
> > expect to receive a req
On Mon, Feb 24, 2025 at 2:51 PM Shubham Khanna
wrote:
>
> The attached patch contains the suggested changes.
>
Pushed with minor changes. In the latest patch, you have incorrectly
copied one of the checks from the previous version patch which I have
fixed before pushing the patch.
--
With Regar
On Wed, Feb 26, 2025 at 11:34 AM vignesh C wrote:
>
> Currently, pg_createsubscriber converts streaming replication to
> logical replication using the specified database name. If the database
> name is not provided, it is obtained from the --publisher-server
> option. If the database name is not s
On Wed, 26 Feb 2025 at 11:26, Andrey Borodin wrote:
>
> I’d suggest to give some more descriptive name to “logit” and expand
> comment “/* sanity check */“. This comment was easier to understand when
> elog() was near, but now IMO we can have few words about what is going on.
Done. Except for a
Hi,
On 2025-02-17 17:55:09 +1300, Thomas Munro wrote:
> 0004-Respect-pin-limits-accurately-in-read_stream.c.patch
>
> The current coding only computes the remaining "fair share" of the
> buffer pool for this backend at stream initialisation. It's hard, but
> not impossible, to get one backend to
Hi,
On 2025-02-26 09:38:20 +0100, Jakub Wartak wrote:
> > FWIW, what you posted fails on CI:
> > https://cirrus-ci.com/task/5114213770723328
> >
> > Probably some ifdefs are missing. The sanity-check task configures with
> > minimal dependencies, which is why you're seeing this even on linux.
>
>
On Wed, Feb 26, 2025 at 9:21 AM Shlok Kyal wrote:
>
> I have done the performance testing for cases where we distribute a
> small amount of invalidation messages to many concurrently decoded
> transactions.
> Here are results:
>
> Concurrent Txn |Head (sec)|Patch (sec) | Degradati
Hi,
On 2025-02-26 15:37:10 +0900, Michael Paquier wrote:
> That's bad, worse for a logical WAL sender, because it means that we
> have no idea what kind of I/O happens in this process until it exits,
> and logical WAL senders could loop forever, since v16 where we've
> begun tracking I/O.
FWIW, I
1 - 100 of 113 matches
Mail list logo
