Hi
út 19. 11. 2024 v 20:14 odesílatel Pavel Stehule
napsal:
> Hi
>
> I wrote POC of VARIABLE(varname) syntax support
>
> here is a copy from regress test
>
> SET session_variables_ambiguity_warning TO on;
> SET session_variables_use_fence_warning_guard TO on;
> SET search_path TO 'public';
> CRE
On Tue, 2025-05-20 at 17:06 -0400, Bruce Momjian wrote:
> f no committer intends to pick it up and commit it, I think the proper
> > action would be to step up and reject the patch set, not complain about the
> > insistence of the author.
>
> Are you saying I should not complain until we have offi
> On 21 May 2025, at 04:48, Michael Paquier wrote:
>
> On Wed, May 21, 2025 at 11:41:18AM +0900, Fujii Masao wrote:
>> Since pg_regress uses log_line_prefix = '%m %b[%p] %q%a ',
>> isn't it better to use the same setting in TAP tests as well?
>
> Oh, right, good point. I've managed to miss this
On 2025/05/20 11:40, Euler Taveira wrote:
On Fri, May 16, 2025, at 12:06 PM, Fujii Masao wrote:
The pgoutput plugin options are documented in the logical streaming
replication protocol, but their default values are not mentioned.
This can be inconvenient for users - for example, when using pg_
On Wed, Apr 30, 2025 at 02:35:40PM +0900, Michael Paquier wrote:
> This is v19 work, so I am adding that to the next commit fest.
Rebased, to fix a conflict I've introduced with a different commit.
--
Michael
From f84213eab2fc324f0e92ca7c55e164da6b2a74ee Mon Sep 17 00:00:00 2001
From: Michael Paqu
> On 21 May 2025, at 11:20, Michael Paquier wrote:
>
> Rebased, to fix a conflict I've introduced with a different commit.
I've looked into the patch set and have some more questions:
1. What if we flush many times? Is it supposed to overwrite
injection_points.data?
2. What if we restart man
On 2025/05/20 13:09, Amit Kapila wrote:
+ Option to enable streaming of in-progress transactions. Valid values are
+ off (the default), on and
+ parallel. The setting parallel
+ enables sending extra information with some messages to be used for
+ parallelization.
Hello PostgreSQL Hackers,
I propose an enhancement to psql \dn+ to display default schema privileges when
nspacl is NULL, by using COALESCE with pg_catalog.acldefault('n', n.nspowner).
Currently, \dn+ shows NULL for "Access privileges" if a schema's ACLs haven't
been explicitly altered. This ca
On Tue, 2025-05-20 at 16:58 -0400, Scott Mead wrote:
> On Wed, May 14, 2025, at 4:06 AM, Laurenz Albe wrote:
> > On Tue, 2025-05-13 at 17:53 -0400, Scott Mead wrote:
> > > On Tue, May 13, 2025, at 5:07 PM, Greg Sabino Mullane wrote:
> > > > On Tue, May 13, 2025 at 4:37 PM Scott Mead wrote:
> > > >
On Wed, 2025-05-21 at 15:33 +0900, 노명석 wrote:
> I propose an enhancement to psql \dn+ to display default schema
> privileges when nspacl is NULL, by using COALESCE with
> pg_catalog.acldefault('n', n.nspowner).
>
> Currently, \dn+ shows NULL for "Access privileges" if a schema's
> ACLs haven't bee
On 2025/05/14 15:54, Alexander Kukushkin wrote:
Hi Fujii,
On Tue, 13 May 2025 at 13:13, Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
In this case, doesn't the flush LSN typically catch up to the write LSN on
node2
after a few seconds? Even if the walreceiver exits while
> On 13 May 2025, at 14:13, Fujii Masao wrote:
>
>
>
> On 2025/05/13 0:47, Andrey Borodin wrote:
>> Moved off from "Small fixes needed by high-availability tools"
>>> On 12 May 2025, at 01:33, Amit Kapila wrote:
>>>
>>> On Fri, May 2, 2025 at 6:30 PM Andrey Borodin wrote:
3. Al
On Wed, May 21, 2025 at 12:38 AM Tom Lane wrote:
> Amit Langote writes:
> > Thanks for pointing out the hole in the current handling of
> > CachedPlan->stmt_list. You're right that the approach of preserving
> > the list structure while replacing its contents in-place doesn’t hold
> > up when the
On Wed, May 21, 2025 at 3:44 AM Tomas Vondra wrote:
> On 5/20/25 05:06, Tom Lane wrote:
> > Amit Langote writes:
> >> Pushed after some tweaks to comments and the test case.
> >
> > My attention was drawn to commit 525392d57 after observing that
> > Valgrind complained about a memory leak in some
Dear Laurenz,
First of all, thank you for agreeing with my point about reducing confusion for
users.
I hadn't noticed that the documentation already clarifies the meaning of an
empty "Access privileges" column.
You've raised valid concerns about hiding information (the actual NULL status
of ns
On Tue, May 20, 2025 at 11:13 AM Peter Smith wrote:
>
> > Test-scenario:
> > --Created 250 sequences on both pub and sub.
> > --There were 10 sequences mismatched.
> > --Sequence replication worked as expected. Logs look better now:
> >
> > LOG: Logical replication sequence synchronization for su
hi.
attached patch is for $subject implementation
per https://www.postgresql.org/docs/current/sql-alterdomain.html
"""
Although ALTER DOMAIN ADD CONSTRAINT attempts to verify that existing stored
data satisfies the new constraint, this check is not bulletproof, because the
command cannot “see” ta
Hi,
On 2025-05-19 15:45:01 -0400, Peter Geoghegan wrote:
> On Mon, May 19, 2025 at 3:37 PM Andres Freund wrote:
> > I think we can do better - something like
> >
> > #ifdef PG_HAVE_8BYTE_SINGLE_COPY_ATOMICITY
> > lsn = PageGetLSN(page);
> > #else
> > buf_state = LockBufHdr(bufHdr);
> >
On Wed, May 21, 2025 at 12:03 PM Maciek Sakrejda wrote:
> That may be due to your extensive experience with Postgres and EXPLAIN plans.
Yes, that is very possible. All things being equal, it helps to have
done something a lot of times.
> Fair enough, although the people trying to make sense of E
Thank you for the review! I think we covered everything here at the
PgConf.dev Advanced Patch Feedback session, but for the sake of the
list I'll reply to the specifics. I'll send a longer email summarizing
more from that session later, probably in a few days.
On Fri, May 9, 2025 at 2:50 PM Robert
On Wed, May 21, 2025 at 7:29 AM Robert Haas wrote:
>
> On Tue, May 20, 2025 at 3:09 PM Maciek Sakrejda wrote:
> > +1, this seems like it could be very useful. A somewhat related issue
> > is being able to tie plan nodes back to the query text: it can be hard
> > to understand the planner's decisi
On 2025/05/20 18:13, vignesh C wrote:
If we set the wal_receiver_timeout configuration using ALTER ROLE for
the subscription owner's role, the apply worker will start with that
value. However, any changes made via ALTER ROLE ... SET
wal_receiver_timeout will not take effect for an already runn
Here's a v2 patchset that reaches the goal of zero reported leaks
in the core regression tests, with some caveats:
* Rather than completely fixing the function-cache and
TS-dictionary-cache issues, I just added suppression rules to
hide them. I am not convinced it is worth working harder than tha
On Tue, May 20, 2025 at 6:59 PM Masahiko Sawada
wrote:
> While I haven't identified how exactly read stream is related to this
> issue, what I've observed through debugging this issue is, during a
> single read_stream_next_buffer() call, I observed that
> heap_vac_scan_next_block() is invoked mul
On Mon, May 19, 2025 at 7:11 PM Jim Jones wrote:
> Not quite yet -- unless there is an expiration date that I am not aware
> of :). If we decide we don't need XMLCast on Postgres after all, I'd
> suggest to delete it from the todo list on the wiki [1] - I've already
> added a link to this thread t
On Wed, 2025-05-21 at 12:55 -0400, Robert Haas wrote:
> > ...like generate_partition_qual() taking a lock on the parent or
> > CheckAttributeType() taking a lock on the typrelid...
>
> To me, relation_open() feels like the kind of operation that I would
> expect to take a lock. If I open something
On 2025/05/21 17:35, Andrey Borodin wrote:
Well, we implemented this and made tests that do a lot of failovers. These tests observed
data loss in some infrequent cases due to wrong new primary selection. Because "few
seconds" is actually unknown random time.
I see your point. But doesn't a
On Tue, May 20, 2025 at 3:09 PM Maciek Sakrejda wrote:
> +1, this seems like it could be very useful. A somewhat related issue
> is being able to tie plan nodes back to the query text: it can be hard
> to understand the planner's decisions if it's not even clear what part
> of the query it's makin
On Tue, 20 May 2025 at 09:54, shveta malik wrote:
>
> On Tue, May 20, 2025 at 8:35 AM Nisha Moond wrote:
> >
> > >
> > > Thanks for the comments, these are handled in the attached v20250516
> > > version patch.
> > >
> >
> > Thanks for the patches. Here are my review comments -
> >
> > Patch-0004
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: tested, failed
Documentation:tested, failed
Hi Hackers,
it might be better to list tasks in alphabetical order,
On Wed, May 21, 2025 at 1:18 PM Jeff Davis wrote:
> Of course relation_open() takes a lock, but sometimes relation_open()
> is hidden in the call stack below other functions where it's not so
> obvious.
Probably true, although some of those are probably code that could
stand to be improved.
> >
On Wed, 2025-05-21 at 17:26 +0900, 노명석 wrote:
> You've raised valid concerns about hiding information (the actual NULL
> status of nspacl) and the potential for a (small) compatibility break
> if psql were to display default ACLs when nspacl is NULL. This leads
> me to think: if there's an informat
On Wed, May 21, 2025, at 3:50 AM, Laurenz Albe wrote:
> On Tue, 2025-05-20 at 16:58 -0400, Scott Mead wrote:
> > On Wed, May 14, 2025, at 4:06 AM, Laurenz Albe wrote:
> > > On Tue, 2025-05-13 at 17:53 -0400, Scott Mead wrote:
> > > > On Tue, May 13, 2025, at 5:07 PM, Greg Sabino Mullane wrote:
>
On Wed, May 21, 2025 at 8:30 PM Dmitry Koval wrote:
>
> Hi!
>
> >per https://www.postgresql.org/docs/current/sql-altertable.html
> >"You must own the table to use ALTER TABLE."
> >That means the current user must own the to be SPLITed partition.
>
> Last statement may be incorrect (if the logic
On 20.05.25 08:38, Michael Paquier wrote:
On Tue, May 20, 2025 at 05:51:51PM +1200, David Rowley wrote:
Given the planId stuff is new and has the same issue, I think that
pushes me towards thinking now is better than later for fixing both.
I'm happy to adjust my patch unless you've started work
> On Tue, May 20, 2025 at 04:50:12PM GMT, Sami Imseih wrote:
> > At the same time AFAICT there isn't much more code paths
> > to worry about in case of a LocationExpr as a node
>
> I can imagine there are others like value expressions,
> row expressions, json array expressions, etc. that we may
> w
On Tue, May 20, 2025 at 5:12 PM Jeff Davis wrote:
> But relation_open() is sort of an exception. There are lots of places
> where that takes a lock because we happen to want something out of the
> relcache, like generate_partition_qual() taking a lock on the parent or
> CheckAttributeType() taking
for example:
...
If in both examples you replace
create role bob;
with
create role bob SUPERUSER;
and in the second example add "set role bob;" before "alter table ..."
query, then no error will be occur.
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
On 5/20/25 21:28, Michael Paquier wrote:
The fix has been applied now on HEAD. I've also checked the state of
pgaudit on branch dev-pg18, with the regression getting fixed. Things
look clear now, at least from my side.
Just retested and it looks good from my side, too. Thanks again!
-David
I wrote:
> Oh, scratch that: I'd gotten confused about which branch I was
> working in. It does change the output as you say.
After poking at that for awhile, I decided we need a small tweak
in EXPLAIN itself to make the output consistent. See attached.
I'm now leaning against back-patching, as
On Tue, May 20, 2025 at 10:32:39AM -0700, Hari Krishna Sunder wrote:
> Ah ya, forgot that reltuples are not always accurate. This sounds
> reasonable to me.
Cool. Here is what I have staged for commit, which I am planning to do
shortly.
--
nathan
>From e68770a6089500e6b4d02bcb3009ec12da392d5f M
Hi!
>per https://www.postgresql.org/docs/current/sql-altertable.html
>"You must own the table to use ALTER TABLE."
>That means the current user must own the to be SPLITed partition.
Last statement may be incorrect (if the logic is different).
Current user can attach another user's partition. If
On Wed, May 21, 2025 at 09:34:02AM +0900, Michael Paquier wrote:
> On Tue, May 20, 2025 at 11:28:17PM +1200, David Rowley wrote:
> > Certainly, a bit late, yes. It basically requires implementing
> > unsigned types on the SQL level. I believe there are a few sunken
> > ships along that coastline, a
On May 21, 2025, at 14:06, Robert Haas wrote:
> No, that wouldn't be too much work, but the issue is that people will
> keep using the _tz versions and when we eventually try to remove them
> those people will complain no matter how prominent we make the
> deprecation notice. If we want to go thi
Hi Robert
On 21.05.25 19:10, Robert Haas wrote:
> Yeah. Just to be clear, I can't really think of committing a patch in
> this area because I don't know the topic well enough. I can make some
> general comments on what I see as issues with this patch but serious
> review would really need to come
"David E. Wheeler" writes:
> On May 21, 2025, at 14:06, Robert Haas wrote:
>> If we want to go this route, maybe we should do
>> something like:
>> ...
>> 5. Still get complaints.
> Complainers gonna complain.
Yeah. I do not see the point of that amount of effort.
> Any idea how widespread th
On Tue, May 20, 2025 at 2:45 PM Tomas Vondra wrote:
> Thanks for the overview. I don't have any immediate feedback, but it
> sounds like it might be related to the "making planner decisions clear"
> session from the unconference ...
>
> The basic premise of that session was about how to give users
Hi,
In [1] I added some verification to projection building, to check if the
tupleslot passed to ExecBuildProjectionInfo() is compatible with the target
list. One query in merge.sql [2] got flagged.
Trying to debug that issue, I found another problem. This leaves us with:
1) w/ inheritance INSE
> On 21 May 2025, at 15:03, Fujii Masao wrote:
>
>
>
> On 2025/05/21 17:35, Andrey Borodin wrote:
>> Well, we implemented this and made tests that do a lot of failovers. These
>> tests observed data loss in some infrequent cases due to wrong new primary
>> selection. Because "few seconds"
On Tue, May 13, 2025 at 11:00 PM David E. Wheeler wrote:
> On May 13, 2025, at 16:24, Florents Tselai wrote:
> > As Robert said—and I agree—renaming the existing _tz family would be more
> > trouble than it’s worth, given the need for deprecations, migration paths,
> > etc. If we were designing
On Tue, May 20, 2025 at 11:16 AM Melanie Plageman
wrote:
>
> In earlier versions of my patch, I played around with replacing these
> references in the docs. I ended up not doing it because I wasn't sure we had
> consensus on deprecating the "on", "true", "yes" options and that we would
> contin
The relationship between patch 0001 and 0002 is unclear to me. Are
these incremental or alternatives? The description doesn't make this clear.
Some of the changes in patch 0002 just appear to move code and comments
around without changing anything substantial. It's not clear why that
is don
On Wed, May 21, 2025 at 12:29 PM Andres Freund wrote:
> > The relevant nbtree code seems more elegant if we avoid calling
> > BufferGetLSNAtomic() unless and until its return value might actually
> > be useful. It's quite a lot easier to understand the true purpose of
> > so->currPos.lsn with this
On Wed, May 21, 2025 at 09:24:26AM +0200, Daniel Gustafsson wrote:
> Agreed, and +1 on the change in general.
Another point perhaps worth considering after a second look: how about
pg_ci_base.conf? We have the following line there, exposing this
configuration with TEMP_CONFIG:
src/tools/ci/pg_ci_
Jim Jones writes:
> On 21.05.25 22:20, Tom Lane wrote:
>> It turns out that xmlDocSetRootElement() doesn't
>> merely install the given root node: it unlinks the document's old
>> root node and returns it to you. If you don't free it, it's leaked
>> (for the session, since this is a malloc not pal
On Wed, 2025-05-21 at 16:29 -0500, Nathan Bossart wrote:
> I don't know precisely where that line might be, but in this case,
> the
> dumped stats have no hope of restoring into anything older than
> v18... But I see no particular benefit from moving the complexity
> to the
> import side here.
Tha
Michael Paquier writes:
> On Wed, May 21, 2025 at 09:24:26AM +0200, Daniel Gustafsson wrote:
>> Agreed, and +1 on the change in general.
> Another point perhaps worth considering after a second look: how about
> pg_ci_base.conf? We have the following line there, exposing this
> configuration wit
On Wed, May 21, 2025 at 03:43:01PM -0400, Robert Haas wrote:
> Since this was Andres's commit, I think it would have been a good idea
> to give at least 24 hours, or better yet a couple of days, for him to
> comment before committing something.
Thanks for the poke, sorry about that. I'll be more
> > > At the same time AFAICT there isn't much more code paths
> > > to worry about in case of a LocationExpr as a node
> >
> > I can imagine there are others like value expressions,
> > row expressions, json array expressions, etc. that we may
> > want to also normalize.
> Exactly. When using a n
On Fri, May 09, 2025 at 02:08:26PM +0900, Michael Paquier wrote:
> One extra thing that I have mentioned is that we could replace the
> CLOG safeguards based on what we know from the checkpoint record based
> on the oldest XID horizon of the checkpoint record and its next XID:
> - If we have a 2PC
> ISTM that vacuum_xid_failsafe_check() should really be doing something
> similar. For example, it could prorate using
> vacuum_multixact_failsafe_age, calculating a member-space-wise
> threshold to trigger the failsafe at, independent of
> mxid_age(relminmxid) itself.
+1. For the case mentioned
On Mon, Mar 31, 2025 at 7:22 PM Yugo Nagata wrote:
>
> On Mon, 31 Mar 2025 20:00:57 +0900
> Yugo Nagata wrote:
>
> > Hi,
> >
> > I found that multiple sessions concurrently execute CREATE OR REPLACE
> > FUNCTION
> > for a same function, the error "tuple concurrently updated" is raised. This
> >
On Thu, 22 May 2025 at 02:58, Peter Eisentraut wrote:
>
> On 20.05.25 08:38, Michael Paquier wrote:
> > On Tue, May 20, 2025 at 05:51:51PM +1200, David Rowley wrote:
> >> Given the planId stuff is new and has the same issue, I think that
> >> pushes me towards thinking now is better than later for
On Wed, May 21, 2025 at 12:54 PM Melanie Plageman
wrote:
> Attached is a patch that updates these as well as changes all usages
> of log_connections in the tests. I made some judgment calls about
> where we might want expanded or reduced log_connections aspects. As
> such, the patch could use a on
On Wed, 2025-05-21 at 11:08 -0500, Nathan Bossart wrote:
> On Tue, May 20, 2025 at 10:32:39AM -0700, Hari Krishna Sunder wrote:
> > Ah ya, forgot that reltuples are not always accurate. This sounds
> > reasonable to me.
>
> Cool. Here is what I have staged for commit, which I am planning to
> do
On Wed, May 21, 2025 at 09:12:54AM +0200, Pavel Stehule wrote:
> Last discussion is related to reducing the size of the session variable patch
> set.
>
> I have an idea to use variable's fencing more aggressively from the start, and
> then we can reduce it in future. This should not break issues w
On Wed, May 21, 2025 at 07:49:34AM +0200, Pavel Stehule wrote:
> st 21. 5. 2025 v 2:21 odesílatel Michael Paquier napsal:
> One thing that I keep hearing about this feature is that this would be
> really helpful for migration from Oracle to PostgreSQL, helping a lot
> with rewrites of
On Wed, May 21, 2025 at 02:14:55PM -0700, Jeff Davis wrote:
> Originally, one of the reasons we added a version field during dump is
> so that some future version could reinterpret stats in older dump files
> during import.
>
> This patch is using a newer version of pg_dump to interpret stats from
I wrote:
> Here's a v2 patchset that reaches the goal of zero reported leaks
> in the core regression tests, with some caveats:
Oh, another caveat is that I ran this with a fairly minimalistic set
of build options. In a more complete build, I observed a small leak
in xml.c, which I posted a fix f
On Tue, May 20, 2025 at 10:45 PM Michael Paquier wrote:
> I think that your suggestion of fix is right. The properties are
> marked as "WRITEV" and "READV" for vectored operations. So the
> documentation is right, not the name used in the code. Will fix,
> thanks for the report.
Since this was
Jim Jones writes:
> In my environment (libxml2 v2.9.10 and Ubuntu 22.04) I couldn't
> reproduce this memory leak.
Just when you thought it was safe to go back in the water ...
Experimenting with the improved valgrind leak detection code at [1],
I discovered that XMLSERIALIZE(... INDENT) has yet
Postgres 18 shows "Index Searches: N" in EXPLAIN ANALYZE output -- see
commit 0fbceae841. This is the same information that has long been
tracked by the pg_stat_*_indexes.idx_scan counter at the whole-index
granularity, except that it is now also shown at the level of an
individual index scan.
nbt
Hi Hackers,
Currently, if there's a typo in an extension name while adding a GUC to
postgresql.conf, PostgreSQL server starts up silently without any warning. This
can be misleading, as one might assume the configuration has been correctly
applied, when in fact the value hasn’t been set due to
Shaik Mohammad Mujeeb writes:
> Currently, if there's a typo in an extension name while adding a GUC to
> postgresql.conf, PostgreSQL server starts up silently without any warning.
> This can be misleading, as one might assume the configuration has been
> correctly applied, when in fact the val
On Wed, May 21, 2025 at 07:15:27AM +0200, Pavel Stehule wrote:
> út 20. 5. 2025 v 23:07 odesílatel Bruce Momjian napsal:
> > If no committer intends to pick it up and commit it, I think the proper
> > action would be to step up and reject the patch set, not complain about
> the
> >
On Fri, May 9, 2025 at 5:09 AM Nisha Moond wrote:
>
> On Thu, May 8, 2025 at 11:35 AM shveta malik wrote:
> >
> > On Wed, May 7, 2025 at 4:36 PM Nisha Moond wrote:
> > >
> > >
> > > Attached is the v13 patch with the above comments addressed.
> > >
> > > --
> >
> > Thanks for the patch.
> >
> >
Hi Tom
On 21.05.25 22:20, Tom Lane wrote:
> Just when you thought it was safe to go back in the water ...
>
> Experimenting with the improved valgrind leak detection code at [1],
> I discovered that XMLSERIALIZE(... INDENT) has yet a different memory
> leak problem. It turns out that xmlDocSetRoo
On Wed, May 21, 2025 at 12:17:55PM +0300, Andrey Borodin wrote:
> I've looked into the patch set and have some more questions:
> 1. What if we flush many times? Is it supposed to overwrite
> injection_points.data?
Yes.
> 2. What if we restart many times? first startup will remove the file... may
>
> I don't know precisely where that line might be, but in this case, the
> dumped stats have no hope of restoring into anything older than v18 (since
> the stats import functions won't exist), which is well past the point where
> we started using -1 for reltuples. If we could dump the stats from
On Tue, May 20, 2025 at 11:08 AM shveta malik wrote:
>
> Please find few more comments:
Thanks for the comments!
>
> 2)
>
> --
> send_feedback(last_received, requestReply, requestReply);
>
> + maybe_advance_nonremovable_xid(&data, false);
> +
> /*
> * Force reporting to ensure l
On Tue, May 20, 2025 at 6:30 PM shveta malik wrote:
>
> Few more comments mostly for patch001:
Thanks for the comments!
>
> 4)
> For this feature, since we are only interested in remote UPDATEs happening
> concurrently, so shall we ask primary to provide oldest "UPDATE"
> transaction-id in comm
On Fri, May 16, 2025 at 7:31 PM Amit Kapila wrote:
>
> A few more comments:
> =
> 3.
> maybe_advance_nonremovable_xid(RetainConflictInfoData *data,
>bool status_received)
> {
> /* Exit early if retaining conflict information is not required */
> if (!MySubscription->retainconfl
On Thu, May 22, 2025 at 1:01 AM Dmitry Koval wrote:
>
> > for example:
> > ...
>
> If in both examples you replace
>
> create role bob;
>
> with
>
> create role bob SUPERUSER;
>
> and in the second example add "set role bob;" before "alter table ..."
> query, then no error will be occur.
>
That i
On Thu, May 1, 2025 at 10:44 PM Bruce Momjian wrote:
> I have committd the first draft of the PG 18 release notes.
I suggest that you use something like the following wording for the
skip scan feature:
Add the "skip scan" optimization, which enables more efficient scans
of multicolumn B-tree ind
On Wed, May 21, 2025 at 10:09 AM Melanie Plageman
wrote:
>
>
> On Tue, May 20, 2025 at 6:59 PM Masahiko Sawada wrote:
>>
>> While I haven't identified how exactly read stream is related to this
>> issue, what I've observed through debugging this issue is, during a
>> single read_stream_next_buffe
Some of you might have already seen the recent postmortem from
Metronome, which involves an outage caused by MultiXact Member
exhaustion:
https://metronome.com/blog/root-cause-analysis-postgresql-multixact-member-exhaustion-incidents-may-2025
This reminded me of the fact that vacuum_multixact_fai
On Wednesday, May 21, 2025, Shaik Mohammad Mujeeb
wrote:
>
> Currently, if there's a typo in an extension name while adding a GUC to
> postgresql.conf, PostgreSQL server starts up silently without any warning.
>
Because any such setting name is perfectly valid (it serves as a
placeholder) and whe
Looks good to me.
On Wed, May 21, 2025 at 9:08 AM Nathan Bossart
wrote:
> On Tue, May 20, 2025 at 10:32:39AM -0700, Hari Krishna Sunder wrote:
> > Ah ya, forgot that reltuples are not always accurate. This sounds
> > reasonable to me.
>
> Cool. Here is what I have staged for commit, which I am
Robert Haas writes:
> Hi,
>
> ... As a recap, my overall goal here
> is to make it so that you can examine a finished plan, figure out what
> decisions the planner made, and then somehow get the planner to make
> those same decisions over again in a future planning cycle.
I am feeling that this
89 matches
Mail list logo
