Dear Peter,
> Yes, this was previously reported [0] but nothing was done about it. We
> just need to find some place to "do nothing" in bootstrap mode to avoid
> the crash. Your patch seems ok to me for that.
Thanks for giving the old discussion. I couldn't find it. According to the post
[1],
On 2025-01-07 06:27, Robert Treat wrote:
On Mon, Jan 6, 2025 at 3:18 AM Masahiro Ikeda
wrote:
On 2025-01-03 01:25, Robert Treat wrote:
> On Tue, Dec 3, 2024 at 3:13 AM Masahiro Ikeda
> wrote:
>>
>> Hi,
>>
>> The documentation seems to overlook the rewrite condition
>> when executing ALTER TAB
On Mon, Jan 06, 2025 at 06:36:43PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> My first instinct was just to set it to the lowest default we'd consider
>> during the max_connections tests (which I'm assuming is 3 due to the
>> current default for autovacuum_max_workers). That way, the max_
On 6 Jan 2025, at 09:46, Zhou, Zhiguo wrote:Hi Yura and Wenhui,Thanks for kindly reviewing this work!On 1/3/2025 9:01 PM, wenhui qiu wrote:Hi Thank you for your path，NUM_XLOGINSERT_LOCKS increase to 128，I think it will be challenged，do we make it guc ？I noticed there have been some discussions
Nathan Bossart writes:
> On Mon, Jan 06, 2025 at 05:36:17PM -0500, Tom Lane wrote:
>> You'd have to think about how
>> it should interact with initdb's probes for workable values of
>> max_connections. My first thought about that is to have initdb
>> set autovacuum_worker_slots to max_connections
On Sat, 4 Jan 2025 at 02:00, Matthias van de Meent
wrote:
>
> On Tue, 3 Dec 2024 at 17:21, Peter Geoghegan wrote:
> >
> > On Mon, Dec 2, 2024 at 8:18 PM Peter Geoghegan wrote:
> > > Attached is a refined version of a test case I posted earlier on [2],
> > > decisively proving that GiST index-onl
David Steele writes:
> On 1/4/25 11:07, Thomas Munro wrote:
>> As for CIFS, there are lots of reports of this sort of thing from
>> Linux CIFS clients.
> There may be users running Postgres on CIFS but my guess is that is rare
> -- at least I have never seen anyone doing it.
It'd be news to me
I was reviewing all the vacuum related GUCs, and I noticed that they
fall into three main subsections of Chapter 19 (Server Configuration)
in the docs [1]: Automatic Vacuuming [2], Resource Consumption [3],
and Client Connection Defaults [4]. The last one I find pretty
confusing.
vacuum_freeze_min
Hi Rahila,
Thanks for the updated and rebased patch. I've tried the pgbench test
again, to see if it gets stuck somewhere, and I'm observing this on a
new / idle cluster:
$ pgbench -n -f test.sql -P 1 test -T 60
pgbench (18devel)
progress: 1.0 s, 1647.9 tps, lat 0.604 ms stddev 0.438, 0 failed
pr
Committed.
--
nathan
On Jan 2, 2025, at 9:21 PM, Tomas Vondra wrote:
>
>> That said, I do think a workload manager would be more effective than
>> trying to limit total connections.
>
> The "workload management" concept is so abstract I find it very
> difficult to discuss without much more detail about how would it
Hello,
Le lun. 16 déc. 2024 à 22:00, Melanie Plageman
a écrit :
> Hi,
>
> Users wishing to debug slow connection establishment have little
> visibility into which steps take the most time. We don't expose any
> stats and none of the logging includes durations.
>
> The attached patch logs duratio
Hi,
On January 6, 2025 5:15:25 PM EST, Nathan Bossart
wrote:
>On Mon, Jan 06, 2025 at 03:50:24PM -0600, Nathan Bossart wrote:
>> I'm obviously biased, but I think it would be unfortunate to block features
>> like this one because of low settings that would otherwise be unsuitable
>> for any rea
Robert Haas writes:
> To be honest, that pushdown feels really uncomfortable to me. To me,
> the natural syntax for associating an alias with a VALUES clause would
> be something like "VALUES (...) myalias" or, if you also wanted column
> aliasing, "VALUES (...) myalias(a,b,c)". That would feel ju
On Tue, Jan 7, 2025 at 5:23 AM Andrew Dunstan wrote:
> Do you have a plan for moving ahead with this?
I think that all looks good, and I'll go ahead and commit it in the
next day or two. Sorry for the delay.
On Mon, Jan 06, 2025 at 04:29:37PM -0500, Tom Lane wrote:
> Unsurprisingly, this has completely broken buildfarm member sawshark:
> you added 13 new semaphores to the system's default requirements,
> and we only had headroom for about 4 (cf. 38da05346).
Oh wow, I missed that the defaults were so l
On 2024-12-20 19:31:01 +0200, Heikki Linnakangas wrote:
> On 16/12/2024 23:56, Nathan Bossart wrote:
> > On Mon, Dec 16, 2024 at 12:06:33PM +0200, Heikki Linnakangas wrote:
> > > While working on the CSN snapshot patch, I got sidetracked looking closer
> > > into the snapshot tracking in snapmgr.c.
I spent time reviewing v36 today and I have some comments.
Overall I think it's in better shape and the value of being
able to get this information from a single command meta-command
is really useful.
But I have some comments. Sorry if I am re-hashing things
that have already been discussed.
1/ I
On 1/6/25 22:07, Jim Nasby wrote:
> On Jan 2, 2025, at 9:21 PM, Tomas Vondra wrote:
>>
>>> That said, I do think a workload manager would be more effective than
>>> trying to limit total connections.
>>
>> The "workload management" concept is so abstract I find it very
>> difficult to discuss with
Melanie Plageman writes:
> I was reviewing all the vacuum related GUCs, and I noticed that they
> fall into three main subsections of Chapter 19 (Server Configuration)
> in the docs [1]: Automatic Vacuuming [2], Resource Consumption [3],
> and Client Connection Defaults [4]. The last one I find pr
On Fri, Jan 3, 2025 at 11:09 PM Ilia Evdokimov
wrote:
> I've attached a small patch that remove unused parameter 'rel' from
> the static function lookup_var_attr_stats() in extended_stats.c
LGTM. It's a static function, and we can easily add this parameter
back if it's ever needed.
Thanks
Richa
Hi Sawada-San.
Here are some review comments for the patch v12-0001.
==
.../replication/logical/reorderbuffer.c
ReorderBufferCheckAndTruncateAbortedTXN:
1.
+/*
+ * Check the transaction status by looking CLOG and discard all changes if
+ * the transaction is aborted. The transaction status
On Sat, 4 Jan 2025 at 17:58, Tomas Vondra wrote:
>
> On 11/24/24 19:04, Kirill Reshke wrote:
> > On Tue, 8 Oct 2024 at 17:06, Tomas Vondra wrote:
> >>
> >> On 10/8/24 04:03, Michael Paquier wrote:
> >>>
> >>> _gin_parallel_build_main() is introduced in 0001. Please make sure to
> >>> pass down a
Patches 1 and 2 are still Ready for Committer.
On Tue, Dec 31, 2024 at 11:03:33PM -0500, Andres Freund wrote:
> - The README has been extended with an overview of the API. I think it gives a
> good overview of how the API fits together. I'd be very good to get
> feedback from folks that aren'
On Mon, Jan 06, 2025 at 10:57:23AM +0900, Tatsuo Ishii wrote:
>> I'm also curious if this change has much of a meaningful impact in the
>> size of the compiled binary. The macro idea isn't quite how I'd have
>> done it as it does mean passing an extra parameter for every current
>> callsite. If I w
On Tue, Nov 12, 2024 at 05:30:30PM +0900, Michael Paquier wrote:
> 0004 for pg_freespace is fine regarding that for example as we have
> calls of pg_freespace(regclass) in its sql/. I've applied it to begin
> with something.
That commit (3f323eb) contains a generate_series(int, bigint) call. Fol
On Mon, Jan 06, 2025 at 05:36:17PM -0500, Tom Lane wrote:
> Andres Freund writes:
>> How about trying the higher setting first in initdb? On any sane system
>> that won't cost anything because it'll succeed with the higher value.
>
> That might be a good compromise.
+1, I like the idea.
> You'd
Maybe we could leave the NUM_XLOGINSERT_LOCKS unchanged in this patch,
as it is not a hard dependency of the lock-free algorithm. And when this
patch has been fully accepted, we could then investigate the more proper
way of increasing NUM_XLOGINSERT_LOCKS. WDYT?
On 1/6/2025 4:35 PM, wenhui qiu
Hello hackers,
At present, in postgres_fdw, if a query which is using a parallel plan is
fired from the remote end fails to use the parallel plan locally because of
the presence of CURSORS. Consider the following example,
Local server,
Table:
create table t ( i int, j int, k text);
insert into t v
On 2025/01/06 16:17, Masahiro Ikeda wrote:
On 2024-12-20 02:57, Fujii Masao wrote:
On 2024/12/05 16:48, Masahiro Ikeda wrote:
On 2024-12-05 16:23, Yugo NAGATA wrote:
- Prints a progress report as each table is clustered.
+ Prints a progress report as each table is clustered,
+
On Thu, 2025-01-02 at 13:38 +1300, David Rowley wrote:
> On Thu, 2 Jan 2025 at 13:33, Tom Lane wrote:
> >
> > David Rowley writes:
> > > I think what would be more interesting is seeing if we can store
> > > the
> > > TupleHashEntryData.firstTuple in a bump context.
> >
> > Are you saying the s
On Sat, 2025-01-04 at 09:24 +0700, John Naylor wrote:
> FYI, there is a proposal for that at
> https://www.postgresql.org/message-id/817d244237878cebdff0bc363718feaf49a1ea7d.ca...@j-davis.com
I had intended to commit some of those patches soon, so if someone sees
a conflict with the ideas in this
Robert Haas writes:
> On Thu, Jan 2, 2025 at 4:41 PM Tom Lane wrote:
>> (Or we could decide to simplify
>> things at the cost of breaking such SQL code, since there probably
>> is none in the field. It's still not clear to me which choice is
>> better.)
> This part I don't understand.
Sorry, n
On Mon, Dec 30, 2024 at 03:45:03PM -0500, Bruce Momjian wrote:
> On Mon, Dec 30, 2024 at 12:02:47PM -0800, Jeff Davis wrote:
>> I suggest that we make a new thread about the vacuumdb changes and
>> focus this thread and patch series on the pg_dump changes (and minor
>> flag adjustments to pg_upgrad
On Mon, Jan 6, 2025 at 3:18 AM Masahiro Ikeda wrote:
>
> On 2025-01-03 01:25, Robert Treat wrote:
> > On Tue, Dec 3, 2024 at 3:13 AM Masahiro Ikeda
> > wrote:
> >>
> >> Hi,
> >>
> >> The documentation seems to overlook the rewrite condition
> >> when executing ALTER TABLE ADD COLUMN.
> >>
> >> Th
Nathan Bossart writes:
> Committed.
Unsurprisingly, this has completely broken buildfarm member sawshark:
you added 13 new semaphores to the system's default requirements,
and we only had headroom for about 4 (cf. 38da05346).
Now maybe we should just abandon the notion that we ought to be
able t
On Mon, Jan 6, 2025 at 3:45 PM Tom Lane wrote:
> SELECT ... FROM (VALUES (...) ORDER BY a) v(a,b,c)
>
> If it'd been like that all along, nobody would blink at it I think,
> even though you could argue that it's action-at-a-distance to let
> an outer alias affect what happens inside the im
Hi,
On 2025-01-06 10:52:20 -0800, Noah Misch wrote:
> Patches 1 and 2 are still Ready for Committer.
I feel somewhat weird about pushing 0002 without a user, but I guess it's
still exercised, so it's probably fine...
> On Tue, Dec 31, 2024 at 11:03:33PM -0500, Andres Freund wrote:
> > - The REA
On 1/6/25 19:50, Robert Haas wrote:
> On Mon, Jan 6, 2025 at 11:51 AM Tomas Vondra wrote:
>> I wonder if maybe a better solution would be to allow BufFiles with
>> smaller buffers, not just hard-coded 8kB. OTOH I'm not sure how much
>> that helps, before the buffering stops being effective as t
On 1/6/25 19:08, Tom Lane wrote:
David Steele writes:
On 1/4/25 11:07, Thomas Munro wrote:
As for CIFS, there are lots of reports of this sort of thing from
Linux CIFS clients.
There may be users running Postgres on CIFS but my guess is that is rare
-- at least I have never seen anyone doin
On Mon, Jan 6, 2025 at 11:51 AM Tomas Vondra wrote:
> I wonder if maybe a better solution would be to allow BufFiles with
> smaller buffers, not just hard-coded 8kB. OTOH I'm not sure how much
> that helps, before the buffering stops being effective as the buffer
> gets smaller. I mean, we only ha
When I compiled with -ftrivial-auto-var-init=pattern, ECPG's dec_test reported
a diff. Nothing else reported a diff. dec_test calls informix.c numeric
functions like decadd() and decmul(). One test operand, decarr[14], is
risnull(). When these informix.c functions get an risnull() input, they j
On Wed, Dec 25, 2024 at 01:15:53PM +0800, Japin Li wrote:
> It seems that the v11 cannot apply on master since 7f97b4734, and rebase is
> needed.
>
> $ git am ~/v11-0001-Add-passwordcheck.min_password_length.patch
> Applying: Add passwordcheck.min_password_length.
> error: patch failed: contrib/p
On Mon Jan 6, 2025 at 10:49 AM CET, torikoshia wrote:
On Tue, Dec 31, 2024 at 7:57 AM Jelte Fennema-Nio
Updated the PoC patch to calculate them by KB:
=# EXPLAIN (ANALYZE, STORAGEIO) SELECT * FROM pgbench_accounts;
QUERY PLAN
Hi.
I found meson fails to detect 64 GCC atomics. Looks like check was drafted but
never synced with “configure”.
Patch that syncs meson check to configure’s one attached. It fixes the issue at
least on my computer (Mac M1).
——
regards
Yura Sokolov aka funny-falcon
meson-build.diff
Descripti
Andres Freund writes:
> How about trying the higher setting first in initdb? On any sane system that
> won't cost anything because it'll succeed with the higher value.
That might be a good compromise. You'd have to think about how
it should interact with initdb's probes for workable values of
m
On Mon, Jan 06, 2025 at 03:50:24PM -0600, Nathan Bossart wrote:
> I'm obviously biased, but I think it would be unfortunate to block features
> like this one because of low settings that would otherwise be unsuitable
> for any reasonable production workload. If we do want to at least support
> che
BTW, it suddenly strikes me that if anyone actually is using this
syntax in the field, they're most likely doing it like this:
regression=# create view v as
regression-# select * from (values (1),(2),(3) order by 1) v(x);
CREATE VIEW
which nicely sidesteps the question of what column aliases appl
Nathan Bossart writes:
> On Mon, Jan 06, 2025 at 06:36:43PM -0500, Tom Lane wrote:
>> We already changed the max_connections default for affected systems
>> as a consequence of 38da05346, so I don't think the argument about not
>> changing it holds much water.
> I see. Here's a version that uses
On Mon, Jan 6, 2025 at 10:51 PM Andrey M. Borodin wrote:
>
> > On 6 Jan 2025, at 15:54, John Naylor wrote:
> > argument. Like some other patches in this series, this does have the
> > side effect of removing the ability to skip quinique(), so that should
> > be benchmarked (I can do that this we
On Mon, Jan 6, 2025 at 4:52 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Friday, January 3, 2025 2:36 PM Masahiko Sawada
> wrote:
>
> Hi,
>
> >
> > I have one comment on the 0001 patch:
>
> Thanks for the comments!
>
> >
> > + /*
> > +* The changes made by this and later transactions are
On Tue, Jan 7, 2025 at 12:47 AM Nathan Bossart wrote:
>
> On Mon, Jan 06, 2025 at 05:54:29PM +0700, John Naylor wrote:
> > Those functions from common/int.h are probably not good when inlined
> > (see comment there).
>
> +1. In fact, I think this comment was added because of the ST_MED3()
> funct
Hi Tomas,
Thanks for working on this. I haven't studied this problem recently,
but here are some ideas that occur to me:
1. Try to reduce the per-batch overhead.
2. Stop increasing the number of batches when the per-batch overhead
exceeds a small percentage of work_mem (10%? 5%? 1%?).
If you've
> On 6 Jan 2025, at 15:54, John Naylor wrote:
>>
>> I thought about it, but decided to rename the routine.
>> Here's a version 7 with compASC().
>
> I had the right idea, but the wrong function -- HEAD already had a
> suitable comp function, and one that works well with inlined
> specialized
On Fri, Dec 20, 2024 at 01:46:20PM -0600, Nathan Bossart wrote:
> I think I've been saying I would commit this since August, but now I am
> planning to do so first thing in the new year. In v11 of the patch, I
> moved the initial startup WARNING to autovac_init() to avoid repeatedly
> logging when
On 2025/01/06 22:16, Rahila Syed wrote:
PFA the patch with above updates.
Thanks for updating the patch! I like this feature.
I tested this feature and encountered two issues:
Issue 1: Error with pg_get_process_memory_contexts()
When I used pg_get_process_memory_contexts() on the PID of a
On Thu, Jan 2, 2025 at 4:41 PM Tom Lane wrote:
> I'm not seeing where there's a correctness issue here? The parser
> is charged with assigning aliases to RTEs that lack one, and with
> this patch that's still true. It's just assigning a different alias
> than it did before. There is no question
HI Zhiguo
Thank you for your reply ,Then you'll have to prove that 128 is the
optimal value, otherwise they'll have a hard time agreeing with you on this
patch.
Thanks
On Mon, Jan 6, 2025 at 2:46 PM Zhou, Zhiguo wrote:
> Hi Yura and Wenhui,
>
> Thanks for kindly reviewing this work!
>
> On
Hi
ne 5. 1. 2025 v 5:52 odesílatel jian he
napsal:
> diff --git a/src/include/nodes/primnodes.h b/src/include/nodes/primnodes.h
> index 9c2957eb546..624858db301 100644
> --- a/src/include/nodes/primnodes.h
> +++ b/src/include/nodes/primnodes.h
> @@ -361,6 +361,9 @@ typedef struct Const
> * of
hi.
about this issue,
last email in 2012 (https://postgr.es/m/8967.1353167...@sss.pgh.pa.us)
"""
Even if it happens to be trivial in the current patch, it's an added
functional requirement that we might later regret having cavalierly
signed up for. And, as noted upthread, relations that support on
On Sat, Jan 4, 2025 at 3:15 AM Tom Lane wrote:
> To expand on that: I've now found that Linux, macOS, NetBSD, OpenBSD,
> and illumos/OpenIndiana[1] pass that test. I don't believe that Windows
> does NFS. That means that FreeBSD is the only one of our supported
> platforms that fails. I think w
On 06.01.25 14:14, Hayato Kuroda (Fujitsu) wrote:
While working on another thread I found $subject. I've tested only on master,
but I doubt this could happen even on PG16 and 17. You can reproduce by:
```
$ initdb -D data -c "track_commit_timestamp=on"
...
child process was terminated by signal 6
"=?UTF-8?B?6LW15a6H6bmPKOWuh+W9rSk=?=" writes:
> I have discovered a peculiar issue: after creating a temporary view, if the
> backend process exits abnormally, the temporary view is not cleaned up.
> However,
> if a temporary table is created and the backend process exits abnormally, the
> tempo
On 03.01.25 21:51, Dagfinn Ilmari Mannsåker wrote:
Peter Eisentraut writes:
I suggest we define pg_noreturn as
1. If C11 is supported, then _Noreturn, else
2. If GCC-compatible, then __attribute__((noreturn)), else
Would it be worth also checking __has_attribute(noreturn)? Or do all
compil
On 1/6/25 16:42, Robert Haas wrote:
> Hi Tomas,
>
> Thanks for working on this. I haven't studied this problem recently,
> but here are some ideas that occur to me:
>
> 1. Try to reduce the per-batch overhead.
>
Yeah. The "use files without buffering" approach may be seen as an
extreme versi
Robert Haas writes:
> Yeah, that seems like very strong evidence against FreeBSD, but I
> think Thomas Munro's point about CIFS is worth considering. That is
> rather widely used, and if the same workarounds would help both that
> and FreeBSD's NFS, we might want to adopt it even if it's not a
> c
On 2024-12-07 Sa 2:42 AM, Davinder Singh wrote:
On Fri, Dec 6, 2024 at 11:31 AM Thomas Munro
wrote:
Some better new:
1. _chsize_s does in fact seem to work in an msvcrt.dll build.
Thanks to Andres for testing that for me on Windows with a standalone
2 line program on ucrt
Hi,
On 2024-12-19 17:29:12 -0500, Andres Freund wrote:
> > Not about patch itself, but questions about related stack functionality:
> >
> >
> >
> > 7. Is pg_stat_aios still on the table or not ? (A
On 1/4/25 11:07, Thomas Munro wrote:
On Sat, Jan 4, 2025 at 5:48 AM David Steele wrote:
We had one issue reported [1] involving Alpine Linux and CIFS and
Not directly relevant for pgbackrest probably, but I noticed that
Alpine comes up in a few reports of failing rm -r on CIFS. I think it
mi
> On 6 Jan 2025, at 15:50, Ilia Evdokimov wrote:
>
> Any suggestions for improvements?
The patch looks good to me, just a few nits.
0. Perhaps, we could have a test for edge values of 0 and 1. I do not insist,
just an idea to think about.
1. This code seems a little different from your pat
On Thu, Jan 02, 2025 at 02:05:13AM +0530, Mahendra Singh Thalor wrote:
> Here, I am attaching an updated patch. I fixed some bugs of v01 patch and
> did some code cleanup also.
Thank you for picking this up! I started to review it, but the
documentation changes didn't build, and a few tests in ch
On Mon, Jan 06, 2025 at 05:54:29PM +0700, John Naylor wrote:
> Those functions from common/int.h are probably not good when inlined
> (see comment there).
+1. In fact, I think this comment was added because of the ST_MED3()
function in sort_template.h [0]. IIRC clang handles this just fine, but
Hi,
I was looking at this patch, and I was specifically curious about
how this works with prepared statements. The way the patch
works now is that it determines if the statement is to be sampled
at post_parse_analyze time which could lead to unexpected
behavior.
Let's take an example below in whi
On Mon, Jan 6, 2025 at 3:20 AM Ashutosh Bapat
wrote:
>
> On Sat, Jan 4, 2025 at 6:03 AM Masahiko Sawada wrote:
> >
> > On Fri, Jan 3, 2025 at 6:31 AM Euler Taveira wrote:
> > >
> > > On Fri, Jan 3, 2025, at 10:14 AM, Bertrand Drouvot wrote:
> > >
> > > If we don't want to force wal_level = logic
Hello,
Thank you for your response.
We encountered a scenario where orphaned temporary views are preventing DDL
operations on a table, such as "ALTER TABLE xxx ALTER COLUMN xxx TYPE xxx." The
corresponding error message is "ERROR: cannot alter type of a column used by a
view or rule."
In this case
On Tuesday, January 7, 2025 2:00 PM Masahiko Sawada
wrote:
Hi,
>
> On Mon, Jan 6, 2025 at 3:22 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Friday, January 3, 2025 2:36 PM Masahiko Sawada
> wrote:
> >
> > >
> > > I have one comment on the 0001 patch:
> >
> > Thanks for the comments!
> >
> > >
On Thu, 2 Jan 2025 12:46:04 -0800
Lukas Fittl wrote:
> this proposed patch set adds:
>
> 1. An updated in-core facility to optionally track Plan IDs based on
> hashing the plan nodes during the existing treewalk in setrefs.c -
> controlled by the new "compute_plan_id" GUC
> 2. An example user of
On 02.12.24 09:51, Peter Eisentraut wrote:
This patch changes PL/Python to use the Python "limited API". This API
has stronger ABI stability guarantees.[0] This means, you can build PL/
Python against any Python 3.x version and use any other Python 3.x
version at run time.
This is especially
On Mon, Jan 6, 2025 at 10:40 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Tuesday, January 7, 2025 2:00 PM Masahiko Sawada
> wrote:
>
> Hi,
>
> >
> > On Mon, Jan 6, 2025 at 3:22 AM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > On Friday, January 3, 2025 2:36 PM Masahiko Sawada
> > wrote:
> > >
> > > >
On Mon, Jan 6, 2025 at 3:22 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Friday, January 3, 2025 2:36 PM Masahiko Sawada
> wrote:
>
> Hi,
>
> >
> > I have one comment on the 0001 patch:
>
> Thanks for the comments!
>
> >
> > + /*
> > +* The changes made by this and later transactions are
> On 7 Jan 2025, at 09:43, John Naylor wrote:
>
>> With the same setup as in the first message of this thread we can do:
>>
>> postgres=# SELECT _int_contains(arr,ARRAY[1]) FROM arrays_to_sort;
>>
>> before patch patch
>> Time: 567.928 ms
>> after patch
>> Time: 890.297 ms
>> timing of this
Hi Nathan,
Thanks for looking into the patch.
>> I have tried with this direction. See attached v2 patch. In the asm
>> code I don't see "call makeStringInfoExt" as expected. But I see
>> "call initStringInfoExt". I assume this is an expected behavior.
>
> Wouldn't that mean that initStringInf
On 10.12.2024 17:35, Ilia Evdokimov wrote:
Hi everyone,
I attached previous sampling patch for pg_stat_statements (v4).
Suggestions like sampling based on execution time remain unfeasible,
as pg_stat_statements can track query during query planning, not
execution.
To evaluate the implement
On Sun, Jan 5, 2025 at 1:15 AM Andrey M. Borodin wrote:
>
> > On 4 Jan 2025, at 10:24, John Naylor wrote:
> >
> > v6-0001:
> >
> > +static int
> > +unique_cmp(const void *a, const void *b)
> > +{
> > + int32 aval = *((const int32 *) a);
> > + int32 bval = *((const int32 *) b);
> > +
> > + return
HI Zhiguo
> Maybe we could leave the NUM_XLOGINSERT_LOCKS unchanged in this patch,
> as it is not a hard dependency of the lock-free algorithm. And when this
> patch has been fully accepted, we could then investigate the more proper
> way of increasing NUM_XLOGINSERT_LOCKS. WDYT?
If the value is no
Hello,
I have discovered a peculiar issue: after creating a temporary view, if the
backend process exits abnormally, the temporary view is not cleaned up. However,
if a temporary table is created and the backend process exits abnormally, the
temporary table is cleaned up.
After reviewing the code,
On Tue, Dec 31, 2024 at 1:39 AM Tom Lane wrote:
Bruce Momjian writes:
I certainly would love to see storage I/O numbers as distinct from
kernel read I/O numbers.
Me too, but I think it is 100% wishful thinking to imagine that
page fault counts match up with that. Maybe there are filesyste
Hi,
> I think in the phrase:
> "add the directory where the .pc file resides to PKG_CONFIG_PATH."
> better to add wording, that PKG_CONFIG_PATH is the list of directories
> separated by PATH separator ( ; in Windows, : in POSIX). Otherwise the
> reader has to search additional information about
On 2025-01-03 01:25, Robert Treat wrote:
On Tue, Dec 3, 2024 at 3:13 AM Masahiro Ikeda
wrote:
Hi,
The documentation seems to overlook the rewrite condition
when executing ALTER TABLE ADD COLUMN.
The current document states that a volatile DEFAULT will
trigger a rewrite of the table and its i
Hi,
On Mon, Jan 06, 2025 at 06:49:06PM +0900, torikoshia wrote:
>
> > **However, I think the general direction has merit**: Changing this
> > patch to
> > use `ru_inblock`/`ru_oublock` gives very useful insights. `ru_inblock`
> > is 0 when everything is in page cache, and it is very high when stuf
ne 5. 1. 2025 v 17:11 odesílatel jian he
napsal:
> + /*
> + * The arguments of EXECUTE are evaluated by a direct expression
> + * executor call. This mode doesn't support session variables yet.
> + * It will be enabled later.
> + */
> + if (pstate->p_hasSessionVariables)
> + elog(ERROR, "session
On Friday, January 3, 2025 2:36 PM Masahiko Sawada
wrote:
Hi,
>
> I have one comment on the 0001 patch:
Thanks for the comments!
>
> + /*
> +* The changes made by this and later transactions are still
> non-removable
> +* to allow for the detection of update_deleted co
On Sat, Jan 4, 2025 at 6:03 AM Masahiko Sawada wrote:
>
> On Fri, Jan 3, 2025 at 6:31 AM Euler Taveira wrote:
> >
> > On Fri, Jan 3, 2025, at 10:14 AM, Bertrand Drouvot wrote:
> >
> > If we don't want to force wal_level = logical to enable logical decoding
> > (your
> > second idea) then I think
On 03.01.2025 18:42, Fabrízio de Royes Mello wrote:
On Fri, Jan 3, 2025 at 11:09 AM Ilia Evdokimov
wrote:
Hi hackers,
I've attached a small patch that remove unused parameter 'rel' from
the static function lookup_var_attr_stats() in extended_stats.c
While exploring src/bac
Hi hackers,
While working on another thread I found $subject. I've tested only on master,
but I doubt this could happen even on PG16 and 17. You can reproduce by:
```
$ initdb -D data -c "track_commit_timestamp=on"
...
child process was terminated by signal 6: Aborted
initdb: removing data directo
Hi Torikoshia,
Thank you for the review.
>
>
>=# select path FROM pg_get_process_memory_contexts('20271', false);
>path
>---
> {0}
> {0,1}
> {0,2}
> ..
>
> =# select path from pg_backend_memory_contexts;
> path
>---
> {1}
> {1,2}
> {1,3}
>
On Sat, 21 Dec 2024 at 00:41, Amit Langote wrote:
> To address (1), I tried assigning specialized functions to
> PlanState.ExecProcNode in ExecInitSeqScan() based on whether qual or
> projInfo are NULL. Inspired by David Rowley’s suggestion to look at
> ExecHashJoinImpl(), I wrote variants like Ex
Hi,
> For the record, Michael and I had a brief discussion about this
> offlist and decided to abandon the idea of adding TAP tests, relying
> only on buildfarm. Also I will check if we have a clear error message
> in case when a user forgot to run pg_upgrade and running new slru.c
> with old file
98 matches
Mail list logo
