Thanks you for v31 patch-set. Please find few comments on patch001:
1)
wait_for_local_flush:
+ if (data->last_recv_time &&
+ TimestampDifferenceExceeds(data->flushpos_update_time,
+data->last_recv_time, WalWriterDelay))
+ {
+ XLogRecPtr writepos;
+ XLogRecPtr flushpos;
+ bool have_pending_tx
On Thu, May 01, 2025 at 10:44:50PM -0400, Bruce Momjian wrote:
> I will continue improving it until beta 1, and until the final release.
> I will probably add markup in 1-3 weeks. Let the feedback begin. ;-)
May I suggest the attached addition for the release notes, following
commit 371f2db8b t
On Thursday, May 22, 2025, Amit Kapila wrote:
> On Sat, May 3, 2025 at 9:33 PM David G. Johnston
> wrote:
> >
> > While responding to a "our documentation is buggy" complaint I got
> annoyed in my attempt to reproduce the behavior by having to surgically
> copy line-by-line the DDL and DML code
On Sat, May 3, 2025 at 9:33 PM David G. Johnston
wrote:
>
> While responding to a "our documentation is buggy" complaint I got annoyed in
> my attempt to reproduce the behavior by having to surgically copy
> line-by-line the DDL and DML code involved. Let's strive for a more
> copy-paste frien
On Fri, May 23, 2025 at 9:57 AM Suraj Kharage <
suraj.khar...@enterprisedb.com> wrote:
> Hi,
>
> Noticed below behaviour where replication slot is not able to sync up if
> any catalog changes happened after the creation.
> Getting below LOG when trying to sync replication slots using
> pg_sync_rep
Hi,
Noticed below behaviour where replication slot is not able to sync up if
any catalog changes happened after the creation.
Getting below LOG when trying to sync replication slots using
pg_sync_replication_slots() function.
The newly created slot does not appear on the standby after this LOG -
On Tue, Feb 4, 2025 at 9:24 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Thu, Jan 02, 2025 at 08:15:13AM +, Bertrand Drouvot wrote:
> > rebased (v18 attached).
>
> Thanks to all of you that have discussed this patch during the developer
> meeting
> at FOSDEM PGDay last week [1]. I'm attaching a
> For example with bind queries like that:
> select where $1 in ($3, $2) and 1 in ($4, cast($5 as int))
> \bind 0 1 2 3 4
>
> Should we have a bit more coverage, where we use multiple IN and/or
> ARRAY lists with constants and/or external parameters?
I will add more test coverage. All the tests we
On Thu, May 22, 2025 at 11:51 PM Tom Lane wrote:
> I wonder if a better answer would be to make the rewriter responsible
> for this. If you hold your head at the correct angle, a table with
> virtual generated columns looks a good deal like a view, and we don't
> ask the planner to handle those.
On Fri, May 23, 2025 at 08:19:15AM +0530, vignesh C wrote:
> On Fri, 2 May 2025 at 08:14, Bruce Momjian wrote:
> >
> > I have committd the first draft of the PG 18 release notes. The item
> > count looks strong:
> >
> > I will continue improving it until beta 1, and until the final release.
> > I
On Fri, 2 May 2025 at 08:14, Bruce Momjian wrote:
>
> I have committd the first draft of the PG 18 release notes. The item
> count looks strong:
>
> I will continue improving it until beta 1, and until the final release.
> I will probably add markup in 1-3 weeks. Let the feedback begin. ;-)
Re
On Thu, May 22, 2025 at 10:25 AM jian he wrote:
>
hi.
earlier, i didn't check patch 0002.
i think in AlterFunction add
/* Lock the function so nobody else can do anything with it. */
LockDatabaseObject(ProcedureRelationId, funcOid, 0, AccessExclusiveLock);
right after
funcOid = LookupFun
On Wed, May 21, 2025 at 05:57:07PM -0400, Peter Geoghegan wrote:
> For example, TimescaleDB offers Loose index scan as part of the
> TimescaleDB Postgres extension, which (for whatever reason) they chose
> to call skip scan:
>
> https://www.timescale.com/blog/how-we-made-distinct-queries-up-to-800
On Wed, May 21, 2025 at 05:57:07PM -0400, Peter Geoghegan wrote:
> 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 s
On Thu, May 22, 2025 at 10:04 PM Tomas Vondra wrote:
> On 5/22/25 10:12, Amit Langote wrote:
> > Note that I’ve only reverted the changes related to deferring locks on
> > prunable partitions. I’m planning to leave the preparatory commits
> > leading up to that one in place unless anyone objects.
On Thu, May 22, 2025 at 10:02:16AM -0400, Bruce Momjian wrote:
> Agreed on notification. A radical idea would be to add a warning for
> the use of such encodings in PG 18, and then mention their deprecation
> in the PG 18 release notes so everyone is informed they will be removed
> in PG 19.
With
Andres Freund writes:
> [ review ]
Thanks for the comments! I'll go through them and post an updated
version tomorrow. The cfbot is already nagging me for a rebase
now that 0013 is moot.
>> But this is the last step to get to zero reported leaks in a run of the core
>> regression tests, so let
Hi,
0001:
This is rather wild, I really have only the dimmest memory of that other
thread even though I apparently resorted to reading valgrind's source code...
I think the vchunk/vpool naming, while not necessarily elegant, is helpful.
0002: Makes sense.
0003:
0004:
0005:
Ugh, that's rathe
Andy Fan writes:
Hi,
Some clearer idea are provided below. Any feedback which could tell this
is *obviously wrong* or *not obviously wrong* is welcome.
> see the below example:
>
> create table bigt (a int, b int, c int);
> insert into bigt select i, i, i from generate_series(1, 100)i;
> a
Hi Tom Lane,
> Well, yeah, because the core server has no way to identify bogus
> extension GUCs if the relevant extension isn't loaded. We do
> already complain about such things at extension load time.
Yes, currently we do issue warnings at extension load time if a GUC with a
valid prefix
On Thu, May 22, 2025 at 03:10:34PM -0500, Sami Imseih wrote:
> > IMO adding a struct as suggested is okay, especially if it reduces the
> > overall code complexity. But we don't want a node, just a bare struct.
> > Adding a node would be more troublesome.
>
> In v4, a new private struct is added
On Thu, May 22, 2025 at 10:48 AM Sami Imseih wrote:
>
> I started looking at the patch but I have some high level thoughts I would
> like to share before looking further.
>
> > > I find that the name "autovacuum_reserved_workers_num" is generic. It
> > > would be better to have a more specific nam
On Thu, May 22, 2025 at 12:44 AM Daniil Davydov <3daniss...@gmail.com> wrote:
>
> Hi,
>
> On Wed, May 21, 2025 at 5:30 AM Masahiko Sawada wrote:
> >
> > I have some comments on v2-0001 patch
>
> Thank you for reviewing this patch!
>
> > + {
> > + {"autovacuum_reserved_workers_num", PGC_USE
Hi,
I'm trying to understand when the visibility map WAL record
(xl_heap_visible) needs to include a snapshot conflict horizon.
Currently, when emitting a xl_heap_visible record after phase I of
vacuum, we include a snapshot conflict horizon if the page is being
newly set all-visible in the VM.
W
> You can see the failure at the artifacts ->
> 'log/tmp_install/log/install.log' file on the CI web page [1].
>
> If you want to replicate that on your local:
>
> $ ./configure --with-llvm CLANG="ccache clang-16"
> $ make -s -j8 world-bin
> $ make -j8 check-world
>
> should be enough. I was able t
On Thu, May 22, 2025 at 8:43 AM Shaik Mohammad Mujeeb <
mujeeb...@zohocorp.com> wrote:
> I do understand that not everyone may prefer seeing such warnings during
> PG server restart. To address this, we could introduce a new GUC (perhaps
> named *warn_on_unregistered_guc_prefix*), which defaults t
On Thu, May 22, 2025 at 1:20 PM Greg Sabino Mullane
wrote:
> On Thu, May 22, 2025 at 12:45 PM Tom Lane wrote:
>
>> > "lpgsql.bogus = 1" .
>>
>> [ shrug... ] How do you know that's a bogus prefix? It could perfectly
>> well be a fully valid setting for an extension that
>> the installation doesn
On Thu, 2025-05-22 at 15:41 -0400, Tom Lane wrote:
> There is no additional filter in text mode, so I think pg_restore's
> default behavior should also be "no additional filter".
Attached. Only the defaults for pg_dump and pg_dumpall are changed, and
pg_upgrade explicitly specifies --with-statisti
On Wed, May 21, 2025 at 5:20 PM Jacob Champion
wrote:
>
> I took a quick look at the authentication and oauth_validator changes.
> Maybe 007_pre_auth.pl should include `receipt`, to make it easier to
> debug pre-auth hangs using the logs? Other than that, the changes
> looked reasonable to me.
Co
Hi, Vitaly!
On Tue, May 20, 2025 at 6:44 PM Vitaly Davydov wrote:
>
> Thank you very much for the review!
>
> > The patchset doesn't seem to build after 371f2db8b0, which adjusted
> > the signature of the INJECTION_POINT() macro. Could you, please,
> > update the patchset accordingly.
>
> I've u
On 09.05.25 21:50, Robert Haas wrote:
I always struggle a bit to remember our policy on these issues -- to
the best of my knowledge, we haven't documented it anywhere, and I
think we probably should. I believe the way it works is that whenever
a function depends on the operating system's timestam
> In both cases, he recently dead tuples must be copied to the table or index,
> but
> they should not be counted towards reltuples. So, I think we need to fix this
> in
> heapam_relation_copy_for_cluster by probably subtracting
> tups_recently_dead from num_tuples ( which is the value set in
> p
On Thu, May 22, 2025 at 12:45 PM Tom Lane wrote:
> > "lpgsql.bogus = 1" .
>
> [ shrug... ] How do you know that's a bogus prefix? It could perfectly
> well be a fully valid setting for an extension that
> the installation doesn't choose to preload.
>
Well, we do have ways to view all *potential
On Thu, May 22, 2025 at 4:07 PM Masahiko Sawada wrote:
>
> Agreed. I've updated the patch. Does this address your comments?
Yep. LGTM.
I'd probably just remove the parenthetical remark about 20% from the
commit message since that only applies to the success cap and
referencing both the success a
On 20.05.25 17:16, Melanie Plageman wrote:
In src/backend/tcop/postgres.c, there is a call
SetConfigOption("log_connections", "true", context, source);
that could be adjusted.
Do you think the debug option should be 'all' or a list of the options
covered by "true" (whic
On 21.05.25 21:53, Melanie Plageman wrote:
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", "ye
> IMO adding a struct as suggested is okay, especially if it reduces the
> overall code complexity. But we don't want a node, just a bare struct.
> Adding a node would be more troublesome.
In v4, a new private struct is added in gram.y, but we are also adding
additional fields to track the expres
> You need a concurrent transaction to recreate the situation. I am attaching
> an isolation test to show the behavior,
Thanks! That helps.
Indeed heapam_relation_copy_for_cluster and heapam_index_build_range_scan
are counting HEAPTUPLE_RECENTLY_DEAD ( tuples removed but cannot be removed )
diffe
On Thu, May 22, 2025 at 7:27 AM Melanie Plageman
wrote:
>
> On Wed, May 21, 2025 at 6:11 PM Masahiko Sawada wrote:
> >
> > > if (vacrel->eager_scan_remaining_successes > 0)
> > > vacrel->eager_scan_remaining_successes--;
> >
> > I've attached a patch that uses this idea. Feedback is very wel
Greg Sabino Mullane writes:
> On Thu, May 22, 2025 at 2:52 PM Jeff Davis wrote:
>> * The default for pg_restore is --no-statistics. That could cause a minor
>> surprise if the user specifies --with-statistics for pg_dump and
>> not for pg_restore.
> Hm...somewhat to my own surprise, I don't like
On Thu, 2025-05-22 at 09:40 -0400, Robert Haas wrote:
> Pushing the locking down into recordDependencyOn amounts to hoping
> that we don't need to study each code path in detail and decide on
> the
> exactly right place to acquire the lock.
There are (by my rough count) over 250 call sites modifi
On Thu, May 22, 2025 at 3:36 PM Nathan Bossart wrote:
> +1, I think defaulting to restoring everything in the dump file is much
> less surprising than the alternative.
+1.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, May 22, 2025 at 03:29:38PM -0400, Greg Sabino Mullane wrote:
> On Thu, May 22, 2025 at 2:52 PM Jeff Davis wrote:
>> * The default for pg_restore is --no-statistics. That could cause a minor
>> surprise if the user specifies --with-statistics for pg_dump and
>> not for pg_restore. An argum
On Thu, May 22, 2025 at 2:52 PM Jeff Davis wrote:
> * The default for pg_restore is --no-statistics. That could cause a minor
> surprise if the user specifies --with-statistics for pg_dump and
> not for pg_restore. An argument could be made that "if the stats are
> there, restore them", and I do
Thanks for the help. This has unblocked us!
On Thu, May 22, 2025 at 8:25 AM Nathan Bossart
wrote:
> On Wed, May 21, 2025 at 04:53:17PM -0700, Jeff Davis wrote:
> > 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,
> >
On Tue, 20 May 2025, 22:14 Peter Geoghegan, wrote:
>
> On Mon, May 12, 2025 at 8:58 AM Peter Geoghegan wrote:
> > I wonder if we can fix this problem by getting rid of the old support
> > routine #5, "options". It currently doesn't do anything, and I always
> > thought it was strange that it was
On Thu, 2025-05-22 at 10:20 -0400, Robert Haas wrote:
> Yeah. This could use comments from a few more people, but I really
> hope we don't ship the final release this way. We do have a "Enable
> statistics in pg_dump by default" item in the open items list under
> "Decisions to Recheck Mid-Beta", b
On May 22, 2025, at 12:38, Florents Tselai wrote:
> In my experience timestamp related stuff from jsonb documents end up in a
> generated column,
> and are indexed & queried there.
Have you seen this in the wild using the _tz functions? I wouldn’t think they
were indexable, given the volatilit
I started looking at the patch but I have some high level thoughts I would
like to share before looking further.
> > I find that the name "autovacuum_reserved_workers_num" is generic. It
> > would be better to have a more specific name for parallel vacuum such
> > as autovacuum_max_parallel_worker
Hi Sami,
You need a concurrent transaction to recreate the situation. I am attaching
an isolation test to show the behavior, along with its output file. I ran
it on PostgreSQL 17.4.
The test has two permutations, the first one runs on a table without an
index and the second permutation with an in
Hi,
On 2025-05-21 15:43:01 -0400, Robert Haas wrote:
> 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
On Thu, May 22, 2025 at 12:10 PM Shaik Mohammad Mujeeb
wrote:
> In my patch, I currently warn and remove invalid GUCs from the hashtable.
> However, as you rightly pointed out, some of these could belong to valid but
> unregistered prefixes. In such cases, it might not be ideal to remove them
>
Shaik Mohammad Mujeeb writes:
> In my patch, I currently warn and remove invalid GUCs from the hashtable.
> However, as you rightly pointed out, some of these could belong to valid but
> unregistered prefixes. In such cases, it might not be ideal to remove them
> outright. Instead, it could be
Srinath Reddy Sadipiralla writes:
> Tom, the problem is when the prefix is a typo ,my bad i should have
> specified as bogus prefix instead of bogus GUC ,can you please try again
> with
> "lpgsql.bogus = 1" .
[ shrug... ] How do you know that's a bogus prefix? It could
perfectly well be a fully
> On 22 May 2025, at 5:05 PM, Robert Haas wrote:
>
> On Wed, May 21, 2025 at 2:31 PM Tom Lane wrote:
>> Having said that, what's wrong with inventing some improved function
>> names and never removing the old ones?
>
> I don't particularly like the clutter, but if the consensus is that
> the
Hi David J,
> Because any such setting name is perfectly valid (it serves as a placeholder)
> and whether it is a typo or just some valid unregistered prefix is not
> something the system can know.
In my patch, I currently warn and remove invalid GUCs from the hashtable.
However, as you rightl
On Thu, May 22, 2025 at 9:00 PM Tom Lane wrote:
> Srinath Reddy Sadipiralla writes:
> > the extension is loaded and then i entered the bogus extension GUC into
> > postgresql.conf and restarted, i did not observe any complain/warning .
>
> Were you looking in the right place? I experimented wit
On 22.05.25 17:00, Tom Lane wrote:
> Yeah, after sleeping on it I fear that leaving xml_parse entirely
> alone will just be a recipe for future copy-and-paste errors.
That's exactly my concern as well.
> The Assert solution seems like the way to go, approximately
>
> xmlNodePtrroo
On Wed, May 21, 2025 at 10:14 PM Tom Lane wrote:
> 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
Srinath Reddy Sadipiralla writes:
> the extension is loaded and then i entered the bogus extension GUC into
> postgresql.conf and restarted, i did not observe any complain/warning .
Were you looking in the right place? I experimented with adding
shared_preload_libraries = 'plpgsql'#
On Wed, May 21, 2025 at 04:53:17PM -0700, Jeff Davis wrote:
> 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 be
On Thu, May 22, 2025 at 10:29 AM Andrei Lepikhov wrote:
> > I don't think this is really true. It's just standard identifier
> > handling. You can have options with upper-case names if you quote
> > them.
> Sorry for my language. I meant that when you call function
> RegisterExtensionExplainOption
On Tue, May 20, 2025 at 9:18 AM torikoshia wrote:
> I tackled this again and the attached patch removes ExecProcNodeOriginal
> from Planstate.
> Instead of adding a new field, this version builds the behavior into the
> existing wrapper function, ExecProcNodeFirst().
>
> Since ExecProcNodeFirst()
> Does this seem like a bug or is it intentional?
pg_class.reltuples/relpages are only an estimate as per documentation.
However, I cannot reproduce the situation you are talking about on HEAD.
In the below example, I create a table without indexes, then insert and
delete some rows. run vacuum to
Jim Jones writes:
> On 22.05.25 01:48, Tom Lane wrote:
>> ... I considered adding an assertion that that call returns
>> NULL, but concluded that it wasn't worth the notational hassle.
>> I'm not strongly set on that conclusion, though, if you think
>> differently.
> I see. In that case I believe
Hi,
On 2022-12-13 14:18:48 +1300, Thomas Munro wrote:
> On Mon, Dec 12, 2022 at 4:43 PM Thomas Munro wrote:
> > On Mon, Dec 12, 2022 at 4:07 PM Tom Lane wrote:
> > > I'm for "turn the warning off". Per previous discussion, adhering
> > > strictly to that rule would make our code worse (less leg
Nathan Bossart writes:
> On Thu, May 22, 2025 at 10:20:16AM -0400, Robert Haas wrote:
>> It also sort
>> of looks like we might have a consensus anyway: Jeff said "I lean
>> towards making it opt-in for pg_dump and opt-out for pg_upgrade" and I
>> agree with that and it seems you do, too. So perha
Robert Haas writes:
> Before we commit to something along these lines, I think we need to
> understand whether Tom intends to press Peter for some bigger change
> around expand_virtual_generated_columns.
> If Tom doesn't respond right away, I suggest that we need to add an
> open item for http://p
On Sat, May 3, 2025 at 2:44 PM Andrei Lepikhov wrote:
> I have one additional proposal.
>
> I currently use this interface and have noticed that the parameter
> `option_name` in the RegisterExtensionExplainOption routine is
> case-sensitive. Since SQL treats our extended options as
> case-insensit
On Thu, May 22, 2025 at 10:20:16AM -0400, Robert Haas wrote:
> It also sort
> of looks like we might have a consensus anyway: Jeff said "I lean
> towards making it opt-in for pg_dump and opt-out for pg_upgrade" and I
> agree with that and it seems you do, too. So perhaps Jeff should make
> it so?
On 22/5/2025 16:17, Robert Haas wrote:
On Sat, May 3, 2025 at 2:44 PM Andrei Lepikhov wrote:
I have one additional proposal.
I currently use this interface and have noticed that the parameter
`option_name` in the RegisterExtensionExplainOption routine is
case-sensitive. Since SQL treats our ex
On Wed, May 21, 2025 at 6:11 PM Masahiko Sawada wrote:
>
> > if (vacrel->eager_scan_remaining_successes > 0)
> > vacrel->eager_scan_remaining_successes--;
>
> I've attached a patch that uses this idea. Feedback is very welcome.
Thanks for writing the patch!
I actually think we have the same
On Sat, May 10, 2025 at 3:51 PM Greg Sabino Mullane wrote:
> I may have missed something (we seem to have a lot of threads for this
> subject), but we are in beta and both pg_dump and pg_upgrade seem to be
> opt-out? I still object strongly to this; pg_dump is meant to be a canonical
> represe
On 2025/5/21 18:44, jian he wrote:
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 bulletpr
On Thu, May 1, 2025 at 4:33 AM Richard Guo wrote:
> Here is the patchset that implements this optimization. 0001 moves
> the expansion of virtual generated columns to occur before sublink
> pull-up. 0002 introduces a new function, preprocess_relation_rtes,
> which scans the rangetable for relati
On Wed, May 21, 2025 at 2:31 PM Tom Lane wrote:
> Having said that, what's wrong with inventing some improved function
> names and never removing the old ones?
I don't particularly like the clutter, but if the consensus is that
the clutter doesn't matter, fair enough.
--
Robert Haas
EDB: http:/
On Thu, May 22, 2025 at 02:44:39PM +0300, Heikki Linnakangas wrote:
> On 22/05/2025 08:54, Michael Paquier wrote:
> > With all that in mind, I have wanted to kick a discussion about
> > potentially removing one or more encodings from the core code,
> > including the backend part, the frontend part
On Wed, May 21, 2025 at 2:22 PM Jim Jones wrote:
> In v10 I added this to the documentation to make the difference to CAST
> clearer:
Yes, that looks very helpful.
> In v10 I changed these comments to:
That, too.
I don't have time to re-review this right now, but I encourage you to
look throug
On Thu, 22 May 2025 at 17:28, Andy Fan wrote:
> Richard Guo writes:
>
> Hi,
>
> > However, in the case of sort-based implementation,
> > this function pays no attention to the subpath's pathkeys or the
> > pathkeys of the resulting output.
>
> Good finding!
>
> >
> > In addition to this specific
On Tue, May 20, 2025 at 11:38 AM Tom Lane wrote:
> I still like the core idea of deferring locking, but I don't like
> anything about this implementation of it. It seems like there has
> to be a better and simpler way.
Without particularly defending this implementation, and certainly
without def
On Thu, May 22, 2025 at 8:15 AM Bertrand Drouvot
wrote:
> That would probably address Robert's concern [1] "acquiring two locks on the
> same
> object with different lock modes where we should really only acquire one" but
> probably not this one "I think it might result in acquiring the
> locks o
On 5/22/25 10:12, Amit Langote wrote:
> On Wed, May 21, 2025 at 7:22 PM Amit Langote wrote:
>> Fair enough. I’ll revert this and some related changes shortly. WIP
>> patch attached.
>
> I have pushed out the revert now.
>
Thank you.
> Note that I’ve only reverted the changes related to deferr
On Wed, May 21, 2025 at 6:04 PM Fujii Masao wrote:
>
> 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 ... SE
Hi,
On Wed, May 21, 2025 at 10:17:58AM -0700, Jeff Davis wrote:
> On Wed, 2025-05-21 at 12:55 -0400, Robert Haas wrote:
> > Yeah, that's not a terrible idea. I still like the idea I thought
> > Bertrand was pursuing, namely, to take no lock in
> > recordDependencyOn()
> > but assert that the calle
Hi all,
I noticed a potential issue with the heap cluster code used by VACUUM FULL
and CLUSTER, but I am not sure so I thought I'd post the question to the
list.
The code in question counts the number of tuples it processes and uses that
count to update reltuples in pg_class. However, the tuple c
čt 22. 5. 2025 v 13:44 odesílatel Heikki Linnakangas
napsal:
> On 22/05/2025 08:54, Michael Paquier wrote:
> > With all that in mind, I have wanted to kick a discussion about
> > potentially removing one or more encodings from the core code,
> > including the backend part, the frontend part and t
On 22/05/2025 08:54, Michael Paquier wrote:
With all that in mind, I have wanted to kick a discussion about
potentially removing one or more encodings from the core code,
including the backend part, the frontend part and the conversion
routines, coupled with checks in pg_upgrade to complain with
On 2025-May-22, Dmitry Dolgov wrote:
> Just to call this out, I don't think there is an agreement on squashing
> Params, which you have added into 0002.
Actually I think we do have agreement on squashing PARAM_EXTERN Params.
https://postgr.es/m/3086744.1746500...@sss.pgh.pa.us
> Now, both flavou
## Anas-ur-Rasheed Khan (annich...@gmail.com):
> We have a use case where some tables are derived, i.e., can be
> reconstructed entirely from 'source' tables (similar to views, but more
> complex mathematical transformations are applied). Data integrity and
> durability are important for 'source'
Anas-ur-Rasheed Khan writes:
Hi,
> We have a use case where some tables are derived, i.e., can be reconstructed
> entirely from 'source' tables (similar to
> views, but more complex mathematical transformations are applied). Data
> integrity and durability are important for
> 'source' tables,
Richard Guo writes:
Hi,
> However, in the case of sort-based implementation,
> this function pays no attention to the subpath's pathkeys or the
> pathkeys of the resulting output.
Good finding!
>
> In addition to this specific issue, it seems to me that there are
> other potential issues in cr
On Mon, May 19, 2025 at 10:21 PM Robert Haas wrote:
> On Thu, May 15, 2025 at 9:03 AM Andrei Lepikhov wrote:
> > 2. IncrementalSort is not always more effective - it depends on the
> > column's number of groups. In my experience, a non-cost-based decision
> > one day meets the problematic case, a
> On Wed, May 21, 2025 at 08:22:19PM 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,
superuser can bypass all permission checks.
superuser can attach any table to the partitioned table as he wants.
That's right.
Using SUPERUSER may be a rare situation, but it needs to be processed.
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
Shubhankar Anand Kulkarni writes:
Hi,
> SELECT sensitive_data1, column1 FROM benchmark_encytion AS t1 LEFT JOIN (
> SELECT aes256_cbc_decrypt( c1, '\x1234' ::
> bytea, '\x5678' :: bytea ) AS column1 FROM cipher ) AS t2 ON
> t1.sensitive_data1 = t2.column1;
>
> As you can see in the above Que
Hi,
On Thu, May 22, 2025 at 2:09 AM Tom Lane wrote:
> 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 configur
The obvious question is how many people would suffer because
of that removal, as it would prevent them from using pg_upgrade.
Can anybody who works in a region that uses these encodings make
an educated guess?
Yours,
Laurenz Albe
On 22.05.25 01:48, Tom Lane wrote:
> I did look at that one too. I think it's fine, because we're
> dealing with a newly-created document which can't have a root node
> yet. (Reinforcing this, Valgrind sees no leaks after applying
> my patch.) I considered adding an assertion that that call re
Andy Fan writes:
>
>> This list of elided nodes is stored in the PlannedStmt
>
> I did a quick check on the attached patches and I can see some more
> information is added into PlannedStmt. then my question are the
> PlannedStmt is not avaiable during the future planning cycle, then how
> does th
Hi Hackers,
While dealing with a few queries, I noticed that when the join expression (join
clause) is used in projection as well, the expression will be computed twice.
For a better understanding, please take reference from the following example:
SELECT sensitive_data1, column1 FROM benchmark
1 - 100 of 104 matches
Mail list logo
