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
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
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 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 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, 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 Thu, 6 Feb 2025 at 16:29, Umar Hayat wrote:
>
> Hi,
> Recently the ONLY option is introduced [1] for VACUUM and ANALYZE
> commands. Attach provides improved tab completion for this new option
> for both commands.
>
> Along with this also added starting parenthesis "(" auto-complete as
> multipl
Great! Looks very good. Thanks a lot!
--
Best regards,
Maxim Orlov.
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
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
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 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 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
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
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 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
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
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
>
> +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
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
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 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
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, 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 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
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 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 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 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
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
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:
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
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
>
> 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 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
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
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
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'
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 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 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
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
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.
> +
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
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 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
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
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
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/
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
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 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
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 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,
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 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
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
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)
>
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
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.
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
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, 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
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
> > > >
>
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, 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
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
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
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,
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
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 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
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 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
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
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 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 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 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 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
> > >
> > > Probably some ifdefs are missing. The sanity-check task configures with
> > > m
Alvaro Herrera writes:
> On 2025-Feb-22, Alvaro Herrera wrote:
>
>> Also, there's a bunch of "(char *)" casts that are 100% due to
>> printTableAddCell() taking a char * instead of const char * for the cell
>> value. That seems a bit silly, we should change that.
>
> Ah, but the problem is that
On Mon, Feb 24, 2025 at 2:22 PM Andrei Lepikhov wrote:
>
> On 24/2/2025 11:57, Alexander Korotkov wrote:
> > Hi, Andrei!
> >
> > Thank you for your feedback.
> >
> > On Mon, Feb 24, 2025 at 12:12 AM Andrei Lepikhov wrote:
> >> On 23/2/2025 22:15, Alexander Korotkov wrote:
> >>> There is my attemp
On Mon, Feb 24, 2025 at 12:57 PM Alexander Korotkov
wrote:
> On Mon, Feb 24, 2025 at 12:12 AM Andrei Lepikhov wrote:
> > On 23/2/2025 22:15, Alexander Korotkov wrote:
> > > There is my attempt to implement this approach. Getting rid of local
> > > variable (and computation of the same value othe
Hi,
Commit f41d846 [1] introduced a race condition that allows a process
to acquire and continue using an invalidated replication slot, leading
to unexpected behavior.
Example Scenario:
Suppose there is an orphaned logical slot that will be invalidated on
the next checkpoint. Consider the followi
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, 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
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 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.
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
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
Richard Guo 于2025年2月26日周三 17:46写道：
> On Tue, Feb 25, 2025 at 1:30 AM Robert Haas wrote:
> > On Mon, Feb 24, 2025 at 8:08 AM wenhui qiu
> wrote:
> > > Actually ,Many fork postgresql databases have already implemented
> ,For example, if the relevant field has a non-null constraint ，Many
> dat
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
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.
>
>
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
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-25 09:33:36 -0500, Andres Freund wrote:
> I am working on writing some tests for temporary tables. One of the tests is
> that we correctly handle running out of buffer pins. That's a bit more
> annoying than it needs to because the minimum for temp_buffers is 100.
>
> It seems rath
1 - 100 of 113 matches
Mail list logo
