On Thu, May 23, 2024 at 01:34:10PM +1200, David Rowley wrote:
> On Thu, 23 May 2024 at 10:04, Bruce Momjian wrote:
> > You might have seen in this thread, I do record commits that speed up
> > workloads that are user-visible, or specifically make new workloads
> > possible.
than "slru",
> isn't it?
> I also found an older release note[1] used single quotes for this like:
>
> Add pg_stat_reset_shared('bgwriter') to reset the cluster-wide shared
> statistics for the background writer (Greg Smith)
Agreed, patch applied, tha
On Wed, May 22, 2024 at 11:29:06AM +0900, Masahiko Sawada wrote:
> I found a typo:
>
> s/pg_statstatement/pg_stat_statement/
>
> I've attached a patch to fix it.
Agreed, applied, thanks.
--
Bruce Momjian https://momjian.us
EDB
ngote)
>
>
>
> Should be:
>
>
>
> Add SQL/JSON constructor functions JSON(), JSON_SCALAR(), and
> JSON_SERIALIZE() (Nikita Glukhov, Teodor Sigaev, Oleg Bartunov,
> Alexander Korotkov, Andrew Dunstan, Amit Langote)
>
>
Thanks, app
On Mon, May 20, 2024 at 11:48:09AM -0700, Jeff Davis wrote:
> On Sat, 2024-05-18 at 17:51 -0400, Bruce Momjian wrote:
> > Okay, I went with the attached applied patch. Adjustments?
>
> I think it should have more emphasis on the actual new feature: a
> platform-independent
On Tue, May 21, 2024 at 09:40:28AM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-05-18 11:13:54 -0400, Bruce Momjian wrote:
> > Please see the email I just posted. There are three goals we have to
> > adjust for:
> >
> > 1. short release notes so they are read
aps you could
> argue that they were not in fact part of the same project and instead
> were just small individual changes -- none of which are individually
> worth including in the release notes.
I try and group them, but I am sure imperfectly. It is very true that
infrastucture chang
g large blocks of data to a
client (Melih Mutlu)
Allow the grouping of file system reads with the new system variable
io_combine_limit (Thomas Munro, Andres Freund, Melanie Plageman, Nazir
Bilal Yavuz)
Do we think more user-invisible
; commits related to release note entries. We already do much of the work of
> building that list of commits for each entry. That'd allow a reader to find
> more details if interested.
Yes, it would be cool if they could mouse-over a graphic next to each
release note item to get a popup
On Tue, May 21, 2024 at 09:27:20AM -0700, Andres Freund wrote:
> On 2024-05-18 10:59:47 -0400, Bruce Momjian wrote:
> > I agree the impact of performance improvements are often greater than
> > the average release note item. However, if people expect Postgres to be
> > fa
On Mon, May 20, 2024 at 02:47:28PM -0400, Melanie Plageman wrote:
> On Mon, May 20, 2024 at 9:37 AM Bruce Momjian wrote:
> >
> > On Mon, May 20, 2024 at 01:23:02PM +0700, John Naylor wrote:
> > > Hi Bruce, thanks for doing this again!
> > >
> > > I'm a b
On Mon, May 20, 2024 at 02:35:37PM -0400, Melanie Plageman wrote:
> On Sat, May 18, 2024 at 11:13 AM Bruce Momjian wrote:
> > Please see the email I just posted. There are three goals we have to
> > adjust for:
> >
> > 1. short release notes so they are readable
&
Agreed, patch applied, thanks.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
mmitfest, but that's probably
> not practical with the current patch volume. What I'm thinking
> for the moment is to try to make that happen once a year or so.
For me, if someone already knows what the blocker is, it saves me a lot
of time if they can state that somewhere.
--
On Sun, May 19, 2024 at 03:53:38PM +1200, David Rowley wrote:
> On Sun, 19 May 2024 at 02:40, Bruce Momjian wrote:
> >
> > On Thu, May 16, 2024 at 03:35:17PM +1200, David Rowley wrote:
> > > "Additionally, vacuum no longer silently imposes a 1GB tuple re
mit fest entries, they have to figure out what is
holding the patch back from being complete, so they have to read the
thread from the beginning. Should there be a clearer way in the commit
fest app to specify what is missing?
--
Bruce Momjian https://momjian.us
EDB
On Fri, May 17, 2024 at 01:30:03PM -0700, Jeff Davis wrote:
> On Thu, 2024-05-09 at 00:03 -0400, Bruce Momjian wrote:
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us
On Fri, May 17, 2024 at 09:22:59PM +0800, jian he wrote:
> On Thu, May 9, 2024 at 12:04 PM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momj
people will need to read the git logs or
> > review the code. Do we use it for anything yet?
>
>
> Yes, certainly, it's used in handling backup manifests. Without it we can't
> handle huge manifests. See commits ea7b4e9a2a and 222e11a10a.
>
> Other uses are in the wo
On Thu, May 16, 2024 at 04:29:38PM +0800, jian he wrote:
> On Thu, May 9, 2024 at 12:04 PM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us/pgsql_doc
ading a long document, and I get to a section where I start to
wonder, "Why should I care about this?", I start to skim the rest of
the document. I am particularly critical if I start to wonder, "Why
does the author _think_ I should care about this?" becasue it feels like
the author is writing for him/herself and not the audience.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
lls us that our work isn't
> valued.
Yes, but are we willing to add text that every user will have to read
just for this purpose?
One think we _could_ do is to create a generic performance release note
item saying performance has been improved in the following areas, with
no more de
On Thu, May 16, 2024 at 03:35:17PM +1200, David Rowley wrote:
> On Thu, 16 May 2024 at 14:48, Bruce Momjian wrote:
> >
> > On Wed, May 15, 2024 at 09:13:14AM -0400, Melanie Plageman wrote:
> > > Also +1 on the Sawada/Naylor change being on the highlight section of
>
od way or give
> > up. It's a reasonable request, after all.
>
> I don't think it's reasonable at all. We can't log the XID before it's
> assigned, and we can't log the statement after the XID is assigned
> without completely changing how the parameter works.
I have remo
mportant features. So, wouldn't it be good to have their own
> links, so the reader doesn't need to manually search for that feature ?
Yes, it would be nice to have them. I will be looking for them in the
coming weeks. I usually choose the closest link.
--
Bruce Momjian https://momjian
On Wed, May 15, 2024 at 09:50:36AM +0200, Álvaro Herrera wrote:
> On 2024-May-14, Bruce Momjian wrote:
>
> > Turns out these commits generated a single release note item, which I
> > have now removed with the attached committed patch.
>
> Hmm, but the commits ab
On Thu, May 16, 2024 at 10:39:18AM +0800, jian he wrote:
> On Thu, May 9, 2024 at 12:04 PM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us/pgsql_doc
lease (as David suggested upthread).
Agreed, I went with the attached applied patch.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
diff --git a/doc/src/sgml/release-17.sgml b/doc
rbase. I think that test suite was significant to
anyone using the TCL/Henry Spencer regex library.
If you want your test mentioned, you have to explain why it is useful
for users to know about it, or the value it brings them.
--
Bruce Momjian https://momjian.us
EDB
On Wed, May 15, 2024 at 02:03:32PM +1200, David Rowley wrote:
> On Wed, 15 May 2024 at 13:00, Bruce Momjian wrote:
> >
> > On Tue, May 14, 2024 at 03:39:26PM -0400, Melanie Plageman wrote:
> > > "Reduce system calls by automatically merging reads up to
> > &
On Tue, May 14, 2024 at 10:22:35AM +0800, Tender Wang wrote:
>
>
> jian he 于2024年5月9日周四 18:00写道：
>
> On Thu, May 9, 2024 at 12:04 PM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 17 release notes; you can
&
e at other times, so
> whatever is needed during pg_upgrade is also likely to be needed at
> other times. Maybe that's not sound reasoning for some reason or
> other, but that's my intuition.
I assume Alvaro is saying that pg_upgrade has only a single session,
which is unique and might make t
938311ef86047aa3c6b741f
> b0e96f311985bceba79825214f8e43f65afa653a
>
> with some significant conflict fixes (mostly in the last one).
Turns out these commits generated a single release note item, which I
have now removed with the attached committed patch.
--
Bruce Momjian
On Tue, May 14, 2024 at 03:39:26PM -0400, Melanie Plageman wrote:
> On Thu, May 9, 2024 at 12:04 AM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us/pgsq
On Tue, May 14, 2024 at 02:58:41PM +0100, Pantelis Theodosiou wrote:
> On Thu, May 9, 2024 at 5:03 AM Bruce Momjian wrote
> >
> >
> > I welcome feedback. For some reason it was an easier job than usual.
>
> This looks better if "more case" -> "m
On Tue, May 14, 2024 at 02:20:24PM +0200, Jelte Fennema-Nio wrote:
> On Tue, 14 May 2024 at 02:56, Bruce Momjian wrote:
> >
> > On Sat, May 11, 2024 at 10:24:39AM -0400, Joe Conway wrote:
> > > On 5/11/24 09:57, Jelte Fennema-Nio wrote:
> > > > The buffering c
On Tue, May 14, 2024 at 01:34:56PM +0300, Elena Indrupskaya wrote:
> Being a technical writer, I attached a small patch that fixes minor language
> stuff.
You are absolutely correct. Patch applied, thanks.
--
Bruce Momjian https://momjian.us
On Sat, May 11, 2024 at 03:32:55PM -0400, Andrew Dunstan wrote:
>
> On 2024-05-09 Th 00:03, Bruce Momjian wrote:
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian
On Tue, May 14, 2024 at 10:32:14AM +0800, Andy Fan wrote:
> Bruce Momjian writes:
> > It was unclear from the commit message exactly what user-visible
> > optimization this allowed. Do you have details?
>
> Yes, It allows the query like "SELECT * FROM t1 WHERE t1.a in
essage exactly what user-visible
optimization this allowed. Do you have details?
> - a8a968a8212ee3ef7f22795c834b33d871fac262 this is an optimizer costing
> improvement.
Does this allow faster UNION ALL with LIMIT, perhaps?
--
Bruce Momjian https://momjian.us
EDB
On Sat, May 11, 2024 at 10:24:39AM -0400, Joe Conway wrote:
> On 5/11/24 09:57, Jelte Fennema-Nio wrote:
> > On Fri, 10 May 2024 at 23:31, Tom Lane wrote:
> > >
> > > Bruce Momjian writes:
> > > > I looked at both of these. In both cases I didn't see
On Fri, May 10, 2024 at 05:31:33PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, May 10, 2024 at 06:50:54PM +0200, Jelte Fennema-Nio wrote:
> >> There are two commits that I think would benefit from being listed
> >> (but maybe they are already liste
On Fri, May 10, 2024 at 05:31:33PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, May 10, 2024 at 06:50:54PM +0200, Jelte Fennema-Nio wrote:
> >> There are two commits that I think would benefit from being listed
> >> (but maybe they are already liste
On Fri, May 10, 2024 at 06:50:54PM +0200, Jelte Fennema-Nio wrote:
> On Thu, 9 May 2024 at 06:04, Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us/pgsq
On Fri, May 10, 2024 at 08:10:58PM +, Karoline Pauls wrote:
> On Friday, 10 May 2024 at 20:17, Bruce Momjian
> wrote:
> >
> > log_line_prefix supports application name --- why would you not use
> > that?
> >
>
> log_line_prefix is effective in the serve
On Fri, May 10, 2024 at 06:29:11PM +0200, Daniel Verite wrote:
> Bruce Momjian wrote:
>
> > have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us/pgsql_docs/release-17.html
>
Process 194521 (application_name: woof) waits for ShareLock on transaction
> 775;
> blocked by process 194520.
> HINT: See server log for query details.
> CONTEXT: while locking tuple (0,2) in relation "q"
log_line_prefix supports application name --- why would you not use
On Fri, May 10, 2024 at 01:54:30PM +0530, Bharath Rupireddy wrote:
> On Thu, May 9, 2024 at 9:34 AM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momj
On Thu, May 9, 2024 at 08:40:00PM +0200, Álvaro Herrera wrote:
> On 2024-May-09, Bruce Momjian wrote:
>
> > However, I don't see it mentioned as a release note item in the commit
> > message or mentioned in our docs. I suppose the release note text would
> > be:
> &g
On Fri, May 10, 2024 at 08:05:43AM +1200, Thomas Munro wrote:
> On Thu, May 9, 2024 at 4:04 PM Bruce Momjian wrote:
> > I welcome feedback. For some reason it was an easier job than usual.
>
> > 2024-01-25 [820b5af73] jit: Require at least LLVM 10.
>
> > Require LLVM
On Wed, May 8, 2024 at 08:47:45PM -0700, Paul Jungwirth wrote:
> On 5/8/24 07:44, Bruce Momjian wrote:
> > On Wed, May 8, 2024 at 02:29:34PM +0200, Peter Eisentraut wrote:
> > > > Yes, David is correct here on all points. I like his suggestion to
> > > > clari
On Thu, May 9, 2024 at 12:10:11PM -0400, Andrew Dunstan wrote:
>
> On 2024-05-09 Th 00:03, Bruce Momjian wrote:
>
> I have committed the first draft of the PG 17 release notes; you can
> see the results here:
>
> https://momjian.us/pgsql
On Thu, May 9, 2024 at 11:26:44PM +0800, jian he wrote:
> On Thu, May 9, 2024 at 11:12 PM Bruce Momjian wrote:
> >
> > On Thu, May 9, 2024 at 07:49:55PM +0800, jian he wrote:
> > > On Thu, May 9, 2024 at 6:53 PM jian he
> > > wrote:
> > > >
On Thu, May 9, 2024 at 07:49:55PM +0800, jian he wrote:
> On Thu, May 9, 2024 at 6:53 PM jian he wrote:
> >
> > On Thu, May 9, 2024 at 12:04 PM Bruce Momjian wrote:
> > > I have committed the first draft of the PG 17 release notes; you can
> > > see the result
d hash aggregation on ltree columns.
> <<
Yes, please see my previous email where I am asking why being more
specific is worse.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
On Thu, May 9, 2024 at 06:53:30PM +0800, jian he wrote:
> On Thu, May 9, 2024 at 12:04 PM Bruce Momjian wrote:
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us/pgsql_docs/release-17.h
On Thu, May 9, 2024 at 11:31:17AM +0100, Dagfinn Ilmari Mannsåker wrote:
> Dagfinn Ilmari Mannsåker writes:
>
> > Bruce Momjian writes:
> >
> >> I have committed the first draft of the PG 17 release notes; you can
> >> see the results here:
> >>
On Thu, May 9, 2024 at 11:22:06AM +0100, Dagfinn Ilmari Mannsåker wrote:
> Bruce Momjian writes:
>
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us/pgsql_docs/release-17.htm
On Thu, May 9, 2024 at 06:00:24PM +0800, jian he wrote:
> On Thu, May 9, 2024 at 12:04 PM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us/pgsql_docs
tkov, Teodor Sigaev,
> Nikita Glukhov, Pavel Borisov, Yura Sokolov.
Wow, I try to only list source code items that have some user-facing
impact, and I don't think these do. I do realize how important they are
though. This gets into the balance of mentioning items _users_ need to
kn
On Thu, May 9, 2024 at 02:37:57PM +0800, Richard Guo wrote:
>
> On Thu, May 9, 2024 at 12:04 PM Bruce Momjian wrote:
>
> I have committed the first draft of the PG 17 release notes; you can
> see the results here:
>
> https://momjian.us/pgsql
On Thu, May 9, 2024 at 02:17:12PM +0900, Masahiko Sawada wrote:
> Hi,
>
> On Thu, May 9, 2024 at 1:03 PM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https:
On Thu, May 9, 2024 at 04:53:38AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Thu, May 09, 2024 at 12:03:50AM -0400, Bruce Momjian wrote:
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momj
not to decide what those are all by himself.
Yes, I already have so much of my opinion in the release notes that I
prefer others to make that list, and to make the Acknowledgments list
at the bottom.
--
Bruce Momjian https://momjian.us
EDB https:
>
> The above items and other new features of PostgreSQL 17 are explained in more
> detail in the sections below.
That is just a place-holder. I changed the bullet text to be:
TO BE COMPLETED LATER
--
Bruce Momjian https://momjian.us
EDB
On Thu, May 9, 2024 at 04:44:47PM +1200, David Rowley wrote:
> On Thu, 9 May 2024 at 16:04, Bruce Momjian wrote:
> > I welcome feedback. For some reason it was an easier job than usual.
>
> Thanks for working on that.
>
> > +2023-11-02 [cac169d68] Increase DEFAULT_
: 170
release-12: 180
release-13: 178
release-14: 220
release-15: 184
release-16: 206
release-17: 188
I welcome feedback. For some reason it was an easier job than usual.
--
Bruce Momjian https://momjian.us
EDB
t me know,
> > but I assume it's something a committer can just make happen?
>
> In principle yes, but it's also very helpful if someone produces an actual
> patch file, with complete commit message, credits, mailing list link, etc.
I am ready to do the work, but waited a day
; submit a patch for new, modernized AIX support for PG18.
Yes, I think we were clear that someone needs to review the reverted
patch and figure out which parts are still needed, and why. We have no
"plans" to restore support.
--
Bruce Momjian https://momjian.us
EDB
de of the foreign key uses
PERIOD, the other side must too." However, looking at the example
queries, it seems like if the foreign side has PERIOD, the primary side
must have WITHOUT OVERLAPS, not PERIOD.
Does this doc text need correcting?
--
Bruce Momjian
xcited to see the many optimizer improvements, and removing self-joins
from that list will be unfortunate.
I did write a blog entry in 2021 that suggested we could have
optimizer aggressiveness control to allow for more expensive
optimizations:
https://momjian.us/main/blogs/pgblog/2021.html#Ma
that we shouldn't have that level of confidence in
> this case.
I think what Robert is saying is that it is an unacceptable plan to just
dump the code into PG 18 and clean it up in the following months --- it
needs more research before it is re-added to git.
--
Kashif Zeeshan
> Bitnine Global
>
> On Thu, Apr 25, 2024 at 9:37 PM •Isaac
> Rv wrote:
>
>
ember for PG 17 since it
doesn't compile anymore, so someone has to go over the reverted patch,
figure out which ones are still valid, and report back. Trying to add a
port, with possible breakage, during beta seems too risky compared to
the value.
--
Bruce Momjian htt
On Thu, Apr 25, 2024 at 10:16:34AM +0200, Álvaro Herrera wrote:
> On 2024-Apr-24, Bruce Momjian wrote:
>
> > I agree that targeting PG 18 for a new-er AIX port is the reasonable
> > approach. If there is huge demand, someone can create an AIX fork for
> > PG 17 us
ee that targeting PG 18 for a new-er AIX port is the reasonable
approach. If there is huge demand, someone can create an AIX fork for
PG 17 using the reverted patches --- yeah, lots of pain there, but we
have carried the AIX pain for too long with too little support.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
statistics can be copied from a donor
> replica if needed, and btree indexes only really really need to
> contain their highest and lowest values (and need their height set
> correctly).
Is it possible to prevent stats from being updated by autovacuum and
other methods?
--
Bruce Mo
at's in the docs. The description string has to be a short
> one-liner in just about every case.)
>
> This sounds to me like it would be a painful exercise with not a
> lot of benefit in the end.
Maybe we could _verify_ the contents of func.sgml against pg_pro
On Thu, Apr 4, 2024 at 04:51:50PM -0400, Bruce Momjian wrote:
> On Thu, Apr 4, 2024 at 04:38:10PM -0400, Greg Sabino Mullane wrote:
> > On Thu, Apr 4, 2024 at 2:23 PM Bruce Momjian wrote:
> > +Such upgrades might require manual changes to complete so always read
> >
On Fri, Apr 12, 2024 at 04:55:16PM -0400, Bruce Momjian wrote:
> On Thu, Apr 11, 2024 at 03:37:00PM +0200, Daniel Gustafsson wrote:
> > On 11 Apr 2024, at 15:29, David Rowley wrote:
> >
> > On Fri, 12 Apr 2024, 1:05 am Daniel Gustafsson, wrote:
> >
> &
I opted for "if" due to recent threads where the use of
> "iff" was discouraged due to not being commonly known, but that was in doc/
> and
> not code comments.
I actually agree "iff" is just not clear enough. "Iff" stands for "if
an
now we are requiring
Andres to stop what he is doing to give immediate feedback --- that is
not fair to him.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
ed to
write the paper with the ideas I had, and if I come up with a better
idea later, I can add it to the end.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
r to lose context of the patch and thus interest in
> the patch. And then finally getting into the exact same situation next
> year in the final commit fest, when some other committer didn't agree
> with the redesign of the first one and request a new one pushing it
> another yea
o communicate with us securely. I
suppose some special word could be used to communicate that status ---
that is how it was done in non-electronic communication in the past.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Onl
mand where we define the behavior only alone at the
beginning of a line, and not in other circumstances. The \a example
above suggests \. should be period in all other cases, as suggested, but
I don't know the ramifications if that.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
es. I haven't looked into what
> sort of savings that could yield (if any) but if we go the route of
> regeneration at test-time we shouldn't leave potential savings on the table.
Rather then everyone testing it on every build, couldn't we have an
automated test every night that checked binary f
On Thu, Apr 4, 2024 at 04:38:10PM -0400, Greg Sabino Mullane wrote:
> On Thu, Apr 4, 2024 at 2:23 PM Bruce Momjian wrote:
> +Such upgrades might require manual changes to complete so always read
> +the release notes first.
>
> Proposal:
> "Such upgrades might r
ual steps) from the user's perspective.
Yes, you are correct. It used to be under "modules" and we didn't
update this text, partly because this it not in our source git tree;
updated patch attached.
--
Bruce Momjian https://momjian.us
EDB
gt; otherwise. I think that has more to do with this being just the wrong
> structure to get our point across. Can we pick out some statistics from our
> long history of publishing minor releases to present an objective reality to
> the reader to convince them to trust our track-record
On Wed, Apr 3, 2024 at 09:25:02AM -0400, Bruce Momjian wrote:
> On Wed, Apr 3, 2024 at 04:17:21PM +0300, Panda Developpeur wrote:
> > Dear PostgreSQL Hackers,
> >
> > I am submitting a patch to modify pg_ctl to detect the presence of a geek
> > user
> > on
ents based on the community's suggestions.
>
> Thank you for considering my contribution.
Aside from an extra newline in the patch, I think this is ready to go!
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
bit) that we
> really consider all the older ones to be, well, obsolete. The difference
> "current vs obsolete" is stronger than "latest vs not quite latest".
Okay, I changed "superseded" to "old", and changed "latest" to
"current", pa
out major releases, and then minor releases. This gives a more
natural flow.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
diff --git a/templates/support/versioning.html b/templates
On Mon, Apr 1, 2024 at 03:17:55PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I was more asking if users have access to patches so they could recreate
> > the build by using the Postgres git tree and supplied OS-specific
> > patches.
>
> AFAIK, every o
On Fri, Mar 29, 2024 at 06:37:24PM -0400, Bruce Momjian wrote:
> You might have seen reports today about a very complex exploit added to
> recent versions of liblzma. Fortunately, it was only enabled two months
> ago and has not been pushed to most stable operating systems li
he behavior, nor adding fundamentally new
> monitoring capabilities.
I think pg_upgrade could check for the existence of extended statistics
in any database and adjust the analyze recommdnation wording
accordingly.
--
Bruce Momjian https://momjian.us
EDB
.
I was more asking if users have access to patches so they could recreate
the build by using the Postgres git tree and supplied OS-specific
patches.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
Reality check --- are we still targeting this feature for PG 17?
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
the patches in its source tarball.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
1 - 100 of 2566 matches
Mail list logo
