Patch looks good
On Mon, Aug 25, 2025 at 4:31 AM Alyona Vinter wrote:
> ... could attempt a restore using the incomplete archive. While we hope
> this would cause a clear error during recovery, there is a risk that
> partial application of non-sequential segments might lead to silent
> corruption or other unfores
Your v3 did not get attached to the previous email.
I've seen this idea pop up over the years, and it's still a good one.
Rather than invent new flags, I think a better approach would be to
convince pg_dump to dump a view, such that table foo has a view fooslice to
limit / filter the output. Then we can simply do:
pg_dump -t foo=view:fooslice
and
On Tue, Aug 12, 2025 at 5:32 AM Bertrand Drouvot <
bertranddrouvot...@gmail.com> wrote:
> I considered pg_stat_locks, but chose the singular form to be consistent
> with
> pg_stat_database, pg_stat_subscription, and friends.
>
Counter-examples: pg_stat_statements, pg_stat_subscription_stats. Our
Patch looks good, applies and works. Needs a pgindent run:
- for (f = cont->footers; f; f = f->next) {
- int f_lines;
+ for (f = cont->footers; f; f = f->next)
+ {
+ int
Basic concept looks good. However:
and fixes the incorrect behaviour. Additionally, it renames variables to
> make
> similar errors more apparent in the future.
- if (!innerrel_is_unique_ext(root, joinrelids, inner->relids,
> - outer, JOIN_INNER, selfjoinquals,
> + if (!innerrel_is_unique_ext(ro
Great idea. +1. Here is a quick overall review to get things started.
Meta:
patch did not apply via "git apply". Also has carriage returns (e.g. DOS
file), and some errant whitespace. Seems to pass pgindent, though.
Name:
I think the name would read better as pg_stat_locks, especially as it
retur
On Thu, Jul 31, 2025 at 3:21 PM Laurenz Albe
wrote:
> Having checksums on does not improve data integrity...
>
Maybe not directly, but in the same way that a smoke detector does not
directly prevent fire damage. Checksums do allow you to detect problems and
fix things (esp. bad hardware) before
On Thu, Jun 26, 2025 at 3:22 AM Jim Jones wrote:
> What do you think?
>
Seems good enough for me. I think as long as we document it well, it's only
going to be a net positive, even with some edge cases.
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Pro
I would imagine you'd need a pretty edge case query with a ton of rows
before you would really be able to have enough difference to change plans.
And what would it change to?
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
Damien, maybe we can let the time ones go? Tom and I are not big fans of
those, and nobody else has stepped up to defend them.
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
On Mon, Jul 14, 2025 at 3:21 AM Dean Rasheed
wrote:
> But it's completely trivial to emulate random(min_date, max_date), just by
> doing
>
> min_date + random(0, max_date - min_date)
>
> Is it really worth adding a core function for that?
>
Yes, I think it is. It is also trivial to get a rando
(picking up the thread again too)
>> Five minutes?! That's not been my experience. Not claiming parallelism
is perfect yet,
>> but there are plenty of parallel performance savings under the five
minute mark.
> Absolutely, I've seen 1 second queries go to 200ms with parallelism of
2. The problem
Rebasing this for v19
0003-Add-new-server-config-cleartext_passwords_action.patch
Description: Binary data
Patch review
OVERALL:
I like the idea, especially the date variant. Unlike Tom, I'm not
particularly concerned about breakage of existing scripts, as
most already are working just fine with raw numbers and I don't see this
patch breaking them.
In a selfish vein, I would use the "date" and timest
On Wed, Jun 25, 2025 at 11:50 AM Jim Jones
wrote:
> Since I cannot get the value of transaction_read_only via
> PQparameterStatus.
Hmmm... we can at least get default_transaction_read_only. As fe-connect.c
points out:
/*
* "transaction_read_only = on" pr
On Wed, Jun 25, 2025 at 10:36 AM Nathan Bossart
wrote:
> > This is so close to ideal. It's just that the first bullet should be
> "off by default" :)
>
> If we did that, the only way to dump statistics would be
> --statistics-only, right? You wouldn't be able to include statistics along
> with o
On Wed, Jun 25, 2025 at 4:02 AM Jim Jones wrote:
> if (pset.db && PQparameterStatus(pset.db, "in_hot_standby"))
>
Seems transaction_read_only might be a more useful thing to examine? That's
the side-effect, if you will, that people really care about when in hot
standby mode (and of course, w
On Wed, Jun 25, 2025 at 3:26 AM Ale Rox wrote:
> - A JDBC driver (and ideally other drivers as well) that accepts a list of
> nodes in the connection string and can automatically detect the current
> primary node for write operations — similar to how MongoDB drivers handle
> replica sets.
>
This
On Wed, Jun 25, 2025 at 3:26 AM Ale Rox wrote:
> Specifically, it would be extremely useful to have:
>
(snip wishlist)
> Are there any plans to introduce such functionality in the core
> PostgreSQL project in the future?
Getting failover to work, and work CORRECTLY[1], is an extremely
compli
01 looks sensible to me.
I like 02 as well. Only quibble would be the name (tcp) as it doesn't
really describe a class of things to be tested like the other things in
PG_TEST_EXTRA. Something indicating a lack of socket? Just more verbose
somehow? "tcp_only" perhaps?
Cheers,
Greg
--
Crunchy Dat
On Wed, Jun 18, 2025 at 11:43 AM Nathan Bossart
wrote:
> IIUC the current proposal is to:
>
> * Dump/restore stats by default.
> * Keep the --no-statistics, --no-schema, and --no-data options.
> * Keep the --statistics-only, --schema-only, and --data-only options.
> * Remove the --with-statistics
On Wed, Jun 18, 2025 at 3:35 AM Jelte Fennema-Nio
wrote:
> And what I just don't understand about this whole discussion: We're
> talking about people who want to be frozen in time for 5 years
> straight during this "maintenance support" window by the vendor (whom they
> are paying), with only acc
On Tue, Jun 17, 2025 at 2:23 PM Andres Freund wrote:
> From my POV, which I am sure is not uniformly shared, we don't need to
> support
> new major PG versions on things like RHEL 8.
Ha ha ha ha! (wipes tears from eyes). RHEL 8 is still cutting edge / very
active for many companies out there. A
On Thu, Jun 12, 2025 at 9:14 AM Peter Eisentraut
wrote:
> And this is not something users ever see, so the connection would not be
> obvious. Maybe this should be called something more specific like
> \close_stmt.
>
Maybe just \closeprepared ?
Cheers,
Greg
--
Crunchy Data - https://www.crunch
I think the overall idea is sound. But we need a better solution for the
truncate fk failure. Can we introspect somehow and do a truncate or do a
delete as necessary? I don't like the idea of simply ignoring the
constraint, or of throwing an error.
--
Cheers,
Greg
--
Crunchy Data - https://www.c
On Thu, Jun 12, 2025 at 4:12 PM Corey Huinker
wrote:
(peacefully skimming thread...)
...
> If we're hot to remove options, how about we remove the sections flags?
> Their utility is reliant upon the user understanding exactly which things
> go in which section, and further assumes that everything
On Fri, May 30, 2025 at 9:34 PM Tom Lane wrote:
> I think calling it in the postmaster is a nonstarter.
Thanks for the feedback. Please find attached version two, which moves the
code to the very start of BackendInitialize in
tcop/backend_startup.c. If we handle the request, we simply proc_exit
On Fri, May 30, 2025 at 11:02 AM Antonin Houska wrote:
> Why is it important not to fork?
Good question. Forking is expensive, and there is also a lot of
housekeeping associated with it that is simply not needed here. We want
this to be lightweight, and simple. No need to fork if we are just go
Proposal: Allow a carefully curated selection of information to be shown
without authentication.
A common task for an HA system or a load balancer is to quickly determine
which of your Postgres clusters is the primary, and which are the replicas.
The canonical way to do this is to log in to each s
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 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
On Tue, May 20, 2025 at 2:32 PM Robert Haas wrote:
> trying to create a role that already exists. At this point, my head is
> already kind of exploding, because I thought we were pretty careful to
> try to make it so that pg_dump output can be restored without error even
> in the face of pre-exis
On Tue, May 13, 2025 at 4:37 PM Scott Mead wrote:
> I'll open by proposing that we prevent the planner from automatically
> selecting parallel plans by default
That seems a pretty heavy hammer, when we have things like
parallel_setup_cost that should be tweaked first.
The recommendation that I
On Tue, Apr 1, 2025 at 10:24 PM Robert Haas wrote:
> On Tue, Apr 1, 2025 at 4:24 PM Jeff Davis wrote:
> > On Tue, 2025-04-01 at 09:37 -0400, Robert Haas wrote:
> > > I don't think I was aware of the open item; I was just catching up on
> > > email.
> >
> > I lean towards making it opt-in for pg_
On Wed, May 7, 2025 at 4:55 AM Ian Lawrence Barwick
wrote:
> Version which applies/builds against current HEAD attached. I haven't yet
> had a chance to look at the code beyond fixing it, however.
>
I too, have wanted this over the years, so +1 on the idea.
Quick review: nice patch, very thorou
On Wed, Apr 30, 2025 at 10:07 AM Junwang Zhao wrote:
> I ended up with adding a guc configuration that may support different
> vacuum
> strategies.
+1 to this: it's a good solution to a tricky problem. I would be a -1 if
this were not a GUC.
Yes, it is masking the problem, but maybe a better w
On Thu, Apr 24, 2025 at 8:37 AM Bruce Momjian wrote:
> When I wrote pg_upgrade, I assumed at some point the value of changing the
> storage format would outweigh the value of allowing in-place upgrades. I
> guess that hasn't happened yet.
>
It reminds me of TDE, which is an good example of that
On Thu, Apr 24, 2025 at 8:12 AM Bruce Momjian wrote:
> Do we think most people are _not_ going to use pg_upgrade now that we
> are defaulting to checksums being enabled by default in PG 18?
I cannot imagine this would stop anyone from upgrading. It's one additional
flag, which was already a req
On Thu, Apr 24, 2025 at 7:31 AM David Rowley wrote:
> On Thu, 24 Apr 2025 at 21:27, Japin Li wrote:
> > I propose that PostgreSQL prevent redundant index creation by:
> In any case, who are we to define what a duplicate index is?
I think this part is easier than you make it sound: everythin
On Wed, Apr 16, 2025 at 2:18 AM Ashutosh Bapat
wrote:
> Users find it a waste of resources to deploy 3 big PostgreSQL instances
> just for HA where 2 suffice even if they deploy 3 lightweight DCS
> instances. Having only some of the nodes act as DCS and others purely
> PostgreSQL nodes will reduc
On Mon, Apr 14, 2025 at 1:15 PM Konstantin Osipov
wrote:
> If anyone is working on Raft already I'd be happy to discuss
> the details. I am fairly new to the PostgreSQL hackers ecosystem
> so cautious of starting work in isolation/knowing there is no
> interest in accepting the feature into the t
>
> I am writing to inquire about the use cases for the SAVEPOINT feature.
>
Savepoints are used to implement ON_ERROR_ROLLBACK in psql. See:
https://www.endpointdev.com/blog/2015/02/postgres-onerrorrollback-explained/
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgre
On Tue, Apr 15, 2025 at 4:57 AM Srinath Reddy wrote:
> - Table Access Methods are increasingly used.
>
Citation needed.
> - There's currently no native `\d`-style way to explore which tables are
> using a given TAM.
>
There's also no way to list which tables are unlogged. Or which have
autova
On Mon, Apr 7, 2025 at 12:55 PM Kirill Reshke
wrote:
> Maybe we can tab-complete here if prefix matches pg_% ? Does that makes
> good use case?
>
>>
I think you will have to get much more specific than pg_ before tab
completion makes sense. You are still looking at hundreds of answers. The
exampl
On Sun, Apr 6, 2025 at 6:01 PM Tom Lane wrote:
> 1. Ignore the inconsistency, commit 0004 as-is.
>
> 2. Change the output to be an empty string in background processes.
>This is consistent, but it goes against our upthread feeling that
> "[none]" would avoid confusion.
>
I lean for #1. Yes,
On Thu, Mar 20, 2025 at 4:45 PM Daniel Gustafsson wrote:
> Having a watch interval of zero is IMHO somewhat nonsensical, but since it
> was done intentionally in 6f9ee74d45 (which I had missed) I agree that the
> default should support it as well. Fixed.
>
Yeah, I forgot about that too. The new
I think it's fine the way it is, with regards to v10 check. Can you post a
rebased patch?
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
Thanks for all the feedback. Please find attached a version which prints
"[none]" as the default value, "[local]" for a socket, and otherwise
whatever pg_getnameinfo_all spits out. I cleaned up the coding, respected
padding, removed the family checks, and expanded the docs a tiny bit to
give the re
>
> The user has no particular reason to care about the fact that the password
> they just typed ended up in the log. That is a concern for
> the DBA, not the user, and even if they care about the DBA's feelings,
> they only get the warning after it's too late to do otherwise.
Can't the same be s
I'd rather not sit on this another year, if we can help it. We really
should be warning people about this practice. The exact wording of the hint
can be up for debate (or postponed - we technically don't have to say
anything other than 'bad idea').
Having the ability to disable clear text password
New patch looks good. TIL I learned you can even use things like
\set WATCH_INTERVAL 0xAp-4
:)
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
Patch looks good. One minor issue:
greg=# \set WATCH_INTERVAL -1
invalid value "-1" for "WATCH_INTERVAL": must be greater than 0.00
greg=# \set WATCH_INTERVAL 0.00
greg=#
We should disallow 0 as the error message implies
I've long wanted to be able to set the default interval for \watch in psql
On Fri, Mar 7, 2025 at 8:52 AM Robert Haas wrote:
> There is no "what we'd like them to do" -- we have no policy or preference
> or anything as a group. Everybody's just guessing what other people want
> and care about, and then sometimes we're all grumpy at each other.
>
This is a great point.
It looks like your bytea_output is set to 'escape', which would explain
what you are seeing. Try adding this in first:
SET bytea_output = hex;
SELECT JSON_VALUE(jsonb '"AQID"', '$' RETURNING bytea);
That (hex) is the default value, so you must be setting it to escape
somewhere. You can see where
On Wed, Mar 5, 2025 at 2:43 PM Nathan Bossart
wrote:
> One other design point I wanted to bring up is whether we should bother
> generating a rollback script for the new "swap" mode. In short, I'm
> wondering if it would be unreasonable to say that, just for this mode, once
> pg_upgrade enters t
Overall I like the idea; adds some nice visibility to something that has
been very ephemeral in the past.
Not included in this patch and maybe for follow-up work, is this
> information a good idea also?
can be added to EXPLAIN output and perhaps pg_stat_database.
>
I could see EXPLAIN being some
Does not seem like a bug to me. Just the normal auto-lowercase encountered
in every other SQL command. See:
greg=# select * from pg_listening_channels();
pg_listening_channels
---
(0 rows)
greg=# listen foo;
LISTEN
greg=# select * from pg_listening_channels();
pg_listening_c
On Sat, Mar 1, 2025 at 4:23 PM Tom Lane wrote:
> That particular argument needs to be rejected vociferously.
Okay, I will concede that part of my argument. And for the record, I've
written pg_dump output parsing programs many times over the years, and seen
others in the wild. It's not uncommon
On Mon, Mar 3, 2025 at 11:33 AM Nathan Bossart
wrote:
> I think it would be good to hear some other opinions on whether we should
> consider sending clear-text passwords to the server as either 1) fully
> supported, 2) deprecated but with no intent to remove anytime soon, or 3)
> deprecated with
> Can you expand on some of those cases?
Certainly. I think one of the problems is that because this patch is
solving a pg_upgrade issue, the focus is on the "dump and restore"
scenarios. But pg_dump is used for much more than that, especially "dump
and examine".
Although pg_dump is meant to be a
I know I'm coming late to this, but I would like us to rethink having
statistics dumped by default. I was caught by this today, as I was doing
two dumps in a row, but the output changed between runs solely because the
stats got updated. It got me thinking about all the use cases of pg_dump
I've see
On Thu, Feb 27, 2025 at 1:42 PM Jeff Davis wrote:
> It would make more sense to me if we either (a) enforced work_mem as it
> was at the time of planning; or (b) replanned if executed with a different
> work_mem (similar to how we replan sometimes with different parameters).
>
Definitely (b).
B
Re-reviewed this patch: still compiles, tests pass, and does what it says
on the tin. +1
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
On Mon, Nov 18, 2024 at 10:07 AM Jim Jones
wrote:
> 2024-11-18 16:00:42.720 CET [3135117] -> 192.168.178.27 STATEMENT:
> ...
> 2024-11-18 16:01:23.273 CET [3114980] -> [local] LOG: received SIGHUP,
> ...
2024-11-18 16:01:46.769 CET [3114981] -> [local] LOG: checkpoint
> Is it supposed to be li
Changes look good to me, thanks. Can you make a new patch that applies a
single set of changes to HEAD?
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
On Wed, Feb 26, 2025 at 12:31 AM Srinath Reddy
wrote:
> i was actually trying to recreate power outage scenario using
>>> node->kill9(),node->start() in a custom tap test,then i found this crash.
>>
>>
LOL ,that's not a power outage test, that's a kill -9 postgres test. A true
power outage would
The patch applies cleanly, and works as advertised. Nice work!
Quick notes:
* doc/src/sgml/ref/psql-ref.sgml
In the varlistentry section, the order should be the same as the other
places (N after m)
Line 1644 has an extra comma
Line 1651, maybe the example is simpler as \dNt to keep the wordin
On Tue, Feb 25, 2025 at 11:03 AM Melanie Plageman
wrote:
> Because users can now manually update these values in pg_class, there
> wouldn't be a way to detect the difference
> between a bogus relallfrozen value due to VM corruption or a bogus value
> due to manual statistics intervention.
Er..y
On Tue, Feb 25, 2025 at 10:12 AM Sami Imseih wrote:
> > What about a more general solution, such as a flag to turn off logging
> of ALTER ROLE statements completely?
>
> IMO, flags for a specific type of utility statement seems way too much for
> pg_stat_statements, and this will also not complet
On Tue, Feb 25, 2025 at 10:34 AM Nathan Bossart
wrote:
> I noticed a nearby thread [0] in which there appears to be some budding
> support for a GUC that disables sending passwords to the server in
> clear-text, at least for CREATE/ALTER ROLE.
Yep, that was the thread that inspired this patch!
What about a more general solution, such as a flag to turn off logging of
ALTER ROLE statements completely? Does anyone really need to know the
standard deviation of the timings for "ALTER ROLE alice SET
work_mem='50MB'"? Let's be honest, there are a lot of things that go into
pg_stat_statements th
On Mon, Feb 24, 2025 at 4:18 PM Nathan Bossart
wrote:
> Well, the discussion upthread suggests "disallowing plain text passwords
> completely"
Yeah, that's more of a long-term dream than a real plan. It would certainly
be no sooner than Postgres v24 or so...
Cheers,
Greg
--
Crunchy Data - htt
Guillaume Lelarge wrote:
I'm obviously +1 on this patch since I sent kinda the same patch two weeks
> ago
Ha ha, my brain forgot about that one (even though I commented on it!) -
apologies for that.
> set password_encryption to 'md5';
> create user u4 password 'md5u1';
> ...
It complains tha
On Mon, Feb 24, 2025 at 5:07 AM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> If the problem is that the password might be logged, wouldn't a proper
> solution be not to log such queries?
>
Yes, this has been discussed before. The short answer is that it is
extremely difficult to imple
On Mon, Feb 24, 2025 at 3:07 AM Sadeq Dousti wrote:
> * While capitalization of N might seem arbitrary, it can be acceptable as
> it's "negating" some concept
> ...
>
> If there are no hard objections, I'll proceed with adding the N letter to
> \d commands.
>
Not strongly opposed, but "N" is a
On Sun, Feb 23, 2025 at 4:34 PM Sadeq Dousti wrote:
> Totally agree about the naming. There's no other terminology known to me,
> but I'll definitely think about it. Of course, I'm very open to
> suggestions from you or anyone else in the community.
>
The problem is that we are really tight on a
There have been a few complaints lately about the fact that we cavalierly
allow clear text passwords to be sent when doing CREATE USER or ALTER USER.
These, of course, can end up in many places, such as pg_stat_activity,
pg_stat_statements, .psql_history, and the server logs. It is a genuinely
vali
The idea and the patch looks good to me at first glance, +1.
I'm wondering what else we can do to discourage this pattern, however.
There are more secure ways to set/change a password, but we keep seeing
plain text pop up in various contexts. Maybe a strong warning+hint when
someone uses these com
On Tue, Feb 18, 2025 at 9:17 AM Sébastien wrote:
> Sorry it won't work. It just delays the problem. But still the freeze
> procedure must rewrite all pages.
>
Actually, a 64-bit transaction ID allows for quite a "delay" - like
hundreds of millions of years at your current rate. :)
(Yes, there a
On Fri, Feb 14, 2025 at 1:41 AM Sébastien wrote:
> I had huge problems on server 3 weeks after a 6 TB migration from other
> DB. I think it's sad to rewrite all data twice.
>
You could always COPY FREEZE into a new table, then move any remaining
rows, and finally rename the tables. Should be a w
On Thu, Feb 13, 2025 at 9:45 AM Sébastien wrote:
> This issue is particularly critical during database *migrations* or *version
> upgrades*, where a full data reload is often necessary. Each time a major
> PostgreSQL upgrade occurs, users must reimport large datasets, leading to
> the same proble
On Tue, Feb 11, 2025 at 7:08 PM Michael Paquier wrote:
> On Mon, Feb 10, 2025 at 02:02:10PM -0600, Sami Imseih wrote:
> > I am OK with moving away from "jumble" in-lieu of something else, but my
> thoughts are we should actually call this process "fingerprint"
>
I agree fingerprint is the right
On Tue, Feb 11, 2025 at 3:25 PM Tom Lane wrote:
> More generally, should we reject if the netmask causes *any* nonzero
> IP bits to be ignored? Our CIDR type already imposes that rule:
>
Yeah, I like that idea a lot. That's a great DETAIL message.
Cheers,
Greg
--
Crunchy Data - https://www.cr
>
> This too would work better if hba.c were sharing cidr_in's logic:
+1, a two-for-one solution.
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
ep 17 00:00:00 2001
From: Greg Sabino Mullane
Date: Tue, 11 Feb 2025 11:16:11 -0500
Subject: [PATCH] Only allow a CIDR mask of zero if the IP contains only
zeroes.
Prevents a common error of not realizing the security implications of 1.2.3.4/0
---
src/backend/libpq/hba.c | 20
Currently, all IP addresses in the address field of records in the
pg_hba.conf file require a CIDR mask. This means that rather than the
intuitive way to add a single IP address:
host postgres alice 10.128.0.10 scram-sha-256
One must do:
host postgres alice 10.128.0.10/32 scram-sha-256
I'd li
On Thu, Feb 6, 2025 at 6:46 AM Marcos Pegoraro wrote:
> And obviously, if you don't know the purpose of that GUC, you'll have to
> read the entire paragraph to understand it.
> Objective here is to those ones who know what it is, but don't
> remember its default.
>
That seems a somewhat arbitrar
On Mon, Feb 3, 2025 at 5:38 PM Tom Lane wrote:
> One problem with it is that while we can leave "List of ???" out of the
> set of translatable strings easily, we can't currently do that for the
> argument of pg_log_error because it's automatically a gettext trigger. I'd
> rather not burden trans
I like the ntypes idea: please find attached version 3 which implements it.
I wrote it slightly differently as I did not want to leave any chance of it
escaping the if else blocks without a match.
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & T
On Mon, Feb 3, 2025 at 1:07 PM Tom Lane wrote:
> As presented, I think this fails the translatability guideline
Thanks, good point. Please find attached a slightly more verbose version
that should be better for translations.
For myself, if we were going to do something like this, I'd kind of
2KHy9tZirH2PVfi-uD96R5J8FCsw%40mail.gmail.com
From eaf1097eb0ac02d2ab093e4e4261d0a15adf8ac2 Mon Sep 17 00:00:00 2001
From: Greg Sabino Mullane
Date: Mon, 3 Feb 2025 12:19:14 -0500
Subject: [PATCH] Show more intuitive titles for psql commands \dt \di \dv \dm
\ds and \dE
This applies to the modified versions
Looks good to me. Would ideally like to see some tests: should be easy
enough to add to t/002_pg_dump.pl, but probably not worth it just for a
simple flag like this? We don't test a lot of other flags, but on the other
hand, that's what a test suite is supposed to do.
Cheers,
Greg
On Wed, Jan 8, 2025 at 8:44 AM Dean Rasheed
wrote:
> Attached is a more complete patch
+1, looks good
So in the end, I decided to just add a sentence to each command's
> description, keeping it as
> short as possible.
>
Yes, that makes sense.
Cheers,
Greg
On Fri, Jan 3, 2025 at 8:33 AM Robert Haas wrote:
> We tried to make our code as robust as it could be in the face of kernel
> code that behaved in a manner that was fairly ridiculous relative to our
> needs. This case doesn't seem that different to me.
>
+1. Seems a shame that freebsd chooses s
>
> While backwards compatibility is important, there’s definitely precedent
> for changing what shows up in the catalog. IMHO it’s better to bite the
> bullet and move those fields instead of having vacuum stats spread across
> two different views.
>
-1. That's a huge change, and pg_stat_all_tabl
On Tue, Dec 31, 2024 at 2:33 AM wenhui qiu wrote:
> Of course, to observe the duration of vacuum operations, we can configure
> the log_autovacuum_min_durationparameter, but if there are many tables in
> the database, the vacuum entries in the logs might be quite numerous,
> making it difficult t
On Sun, Dec 29, 2024 at 8:19 PM Rafael Thofehrn Castro
wrote:
> Plans are only printed if the new GUC parameter progressive_explain is
> enabled.
>
Maybe track_explain instead? In the spirit of track_activity.
- progressive_explain_output_size: max output size of the plan printed in
> the in-me
I like this, very useful. It's a shame about the conflict with \dx (lesson
for the future: think extra carefully about option namings!). I am
impressed that \dx \d \d+ \d+x and even \dxx all work as one might
intuit with this patch.
Cheers,
Greg
1 - 100 of 229 matches
Mail list logo
