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
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.
Note that I’ve only reverted the changes related to deferring locks on
prunable partitions. I’m planning to leave the pre
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_USERSET,
> RESOURCES_WORKER_PROCESSES,
> + gettext_noop("Number of worker processes, reser
hi.
"Catalog domain not-null constraints" commit[1]
doesn't have a pg_dump test.
I actually found another bug.
create schema test;
CREATE DOMAIN test.d1 AS integer NOT NULL default 11;
pg_dump --schema=test > 1.sql
""
pg_dump: warning: could not resolve dependency loop among these items:
pg_dump
I came across a query where the plan includes some unnecessary Sort
nodes. Here's an example that shows the issue.
create table t(a int, b int);
insert into t select i%100, i from generate_series(1,1)i;
create index on t(a);
vacuum analyze t;
set enable_hashagg to off;
explain (costs off)
s
74 matches
Mail list logo
