public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v9 8/9] Default to zstd..
17+ messages / 7 participants
[nested] [flat]
* [PATCH v9 8/9] Default to zstd..
@ 2021-03-12 21:35 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 17+ messages in thread
From: Justin Pryzby @ 2021-03-12 21:35 UTC (permalink / raw)
for CI, not for merge
---
configure | 6 ++++--
configure.ac | 2 +-
src/backend/access/transam/xlog.c | 2 +-
src/backend/utils/misc/guc.c | 2 +-
4 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/configure b/configure
index 72bbd719dc..b445db933e 100755
--- a/configure
+++ b/configure
@@ -1582,7 +1582,7 @@ Optional Packages:
use system time zone data in DIR
--without-zlib do not use Zlib
--without-lz4 build without LZ4 support
- --with-zstd build with Zstd compression library
+ --without-zstd build without Zstd compression library
--with-gnu-ld assume the C compiler uses GNU ld [default=no]
--with-ssl=LIB use LIB for SSL/TLS support (openssl)
--with-openssl obsolete spelling of --with-ssl=openssl
@@ -8750,7 +8750,9 @@ $as_echo "#define USE_ZSTD 1" >>confdefs.h
esac
else
- with_zstd=no
+ with_zstd=yes
+
+$as_echo "#define USE_ZSTD 1" >>confdefs.h
fi
diff --git a/configure.ac b/configure.ac
index c348a3ee91..f8ee35ebfd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1015,7 +1015,7 @@ fi
# ZSTD
#
AC_MSG_CHECKING([whether to build with zstd support])
-PGAC_ARG_BOOL(with, zstd, no, [build with Zstd compression library],
+PGAC_ARG_BOOL(with, zstd, yes, [build without Zstd compression library],
[AC_DEFINE([USE_ZSTD], 1, [Define to 1 to build with zstd support. (--with-zstd)])])
AC_MSG_RESULT([$with_zstd])
AC_SUBST(with_zstd)
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index f2b0af6360..599381337e 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -98,7 +98,7 @@ char *XLogArchiveCommand = NULL;
bool EnableHotStandby = false;
bool fullPageWrites = true;
bool wal_log_hints = false;
-int wal_compression = WAL_COMPRESSION_LZ4;
+int wal_compression = WAL_COMPRESSION_ZSTD;
char *wal_consistency_checking_string = NULL;
bool *wal_consistency_checking = NULL;
bool wal_init_zero = true;
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 0ad62e4d1f..f37251a27f 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -4822,7 +4822,7 @@ static struct config_enum ConfigureNamesEnum[] =
NULL
},
&wal_compression,
- WAL_COMPRESSION_LZ4, wal_compression_options,
+ WAL_COMPRESSION_ZSTD, wal_compression_options,
NULL, NULL, NULL
},
--
2.17.0
--neYutvxvOLaeuPCA
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v9-0009-Use-GUC-hooks-to-support-compression-level.patch"
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: First draft of PG 17 release notes
@ 2024-09-07 09:55 Alvaro Herrera <[email protected]>
2024-09-10 02:46 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
0 siblings, 1 reply; 17+ messages in thread
From: Alvaro Herrera @ 2024-09-07 09:55 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Nathan Bossart <[email protected]>; pgsql-hackers
On 2024-Sep-05, Bruce Momjian wrote:
> That seems more infrastructure/extension author stuff which isn't
> normally mentioned in the release notes. I think such people really
> need to look at all the commit messages.
Are you saying all extension authors should be reading the complete git
log for every single major release? That's a strange position to take.
Isn't this a good fit for "E.1.3.10. Source Code"?
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
<Schwern> It does it in a really, really complicated way
<crab> why does it need to be complicated?
<Schwern> Because it's MakeMaker.
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: First draft of PG 17 release notes
2024-09-07 09:55 Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
@ 2024-09-10 02:46 ` Bruce Momjian <[email protected]>
2024-09-10 06:28 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
0 siblings, 1 reply; 17+ messages in thread
From: Bruce Momjian @ 2024-09-10 02:46 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Nathan Bossart <[email protected]>; pgsql-hackers
On Sat, Sep 7, 2024 at 11:55:09AM +0200, Álvaro Herrera wrote:
> On 2024-Sep-05, Bruce Momjian wrote:
>
> > That seems more infrastructure/extension author stuff which isn't
> > normally mentioned in the release notes. I think such people really
> > need to look at all the commit messages.
>
> Are you saying all extension authors should be reading the complete git
> log for every single major release? That's a strange position to take.
> Isn't this a good fit for "E.1.3.10. Source Code"?
Yes. There are so many changes at the source code level it is unwise to
try and get them into the main release notes. If someone wants to
create an addendum, like was suggested for pure performance
improvements, that would make sense.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: First draft of PG 17 release notes
2024-09-07 09:55 Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
2024-09-10 02:46 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
@ 2024-09-10 06:28 ` Jelte Fennema-Nio <[email protected]>
2024-09-10 08:51 ` Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
2024-09-10 16:52 ` Re: First draft of PG 17 release notes Masahiko Sawada <[email protected]>
2024-09-11 14:10 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
0 siblings, 3 replies; 17+ messages in thread
From: Jelte Fennema-Nio @ 2024-09-10 06:28 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Tue, 10 Sept 2024 at 04:47, Bruce Momjian <[email protected]> wrote:
> Yes. There are so many changes at the source code level it is unwise to
> try and get them into the main release notes. If someone wants to
> create an addendum, like was suggested for pure performance
> improvements, that would make sense.
I agree that the release notes cannot fit every change. But I also
don't think any extension author reads the complete git commit log
every release, so taking the stance that they should be seems
unhelpful. And the "Source Code" section does exist so at some level
you seem to disagree with that too. So what is the way to decide that
something makes the cut for the "Source Code" section?
I think as an extension author there are usually three types of
changes that are relevant:
1. New APIs/hooks that are meant for extension authors
2. Stuff that causes my existing code to not compile anymore
3. Stuff that changes behaviour of existing APIs code in a
incompatible but silent way
For 1, I think adding them to the release notes makes total sense,
especially if the new APIs are documented not only in source code, but
also on the website. Nathan his change is of this type, so I agree
with him it should be in the release notes.
For 2, I'll be able to easily find the PG commit that caused the
compilation failure by grepping git history for the old API. So having
these changes in the release notes seems unnecessary.
For 3, it would be very useful if it would be in the release notes,
but I think in many cases it's hard to know what commits do this. So
unless it's obviously going to break a bunch of extensions silently, I
think we don't have to add such changes to the release notes.
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: First draft of PG 17 release notes
2024-09-07 09:55 Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
2024-09-10 02:46 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-10 06:28 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
@ 2024-09-10 08:51 ` Alvaro Herrera <[email protected]>
2 siblings, 0 replies; 17+ messages in thread
From: Alvaro Herrera @ 2024-09-10 08:51 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On 2024-Sep-10, Jelte Fennema-Nio wrote:
> I think as an extension author there are usually three types of
> changes that are relevant:
>
> 1. New APIs/hooks that are meant for extension authors
> For 1, I think adding them to the release notes makes total sense,
> especially if the new APIs are documented not only in source code, but
> also on the website. Nathan his change is of this type, so I agree
> with him it should be in the release notes.
I agree. The volume of such items should be pretty small.
> 3. Stuff that changes behaviour of existing APIs code in a
> incompatible but silent way
> For 3, it would be very useful if it would be in the release notes,
> but I think in many cases it's hard to know what commits do this. So
> unless it's obviously going to break a bunch of extensions silently, I
> think we don't have to add such changes to the release notes.
While we cannot be 100% vigilant (and it doesn't seem likely for
automated tools to detect this), we try to avoid API changes that would
still compile but behave incompatibly. In many review discussions you
can see suggestions to change some function signature so that
third-party authors would be aware that they need to adapt their code to
new behavior, turning cases of (3) into (2). I agree that these don't
need release notes items.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"XML!" Exclaimed C++. "What are you doing here? You're not a programming
language."
"Tell that to the people who use me," said XML.
https://burningbird.net/the-parable-of-the-languages/
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: First draft of PG 17 release notes
2024-09-07 09:55 Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
2024-09-10 02:46 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-10 06:28 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
@ 2024-09-10 16:52 ` Masahiko Sawada <[email protected]>
2024-09-11 14:12 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2 siblings, 1 reply; 17+ messages in thread
From: Masahiko Sawada @ 2024-09-10 16:52 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Alvaro Herrera <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Mon, Sep 9, 2024 at 11:29 PM Jelte Fennema-Nio <[email protected]> wrote:
>
> On Tue, 10 Sept 2024 at 04:47, Bruce Momjian <[email protected]> wrote:
> > Yes. There are so many changes at the source code level it is unwise to
> > try and get them into the main release notes. If someone wants to
> > create an addendum, like was suggested for pure performance
> > improvements, that would make sense.
>
> I agree that the release notes cannot fit every change. But I also
> don't think any extension author reads the complete git commit log
> every release, so taking the stance that they should be seems
> unhelpful. And the "Source Code" section does exist so at some level
> you seem to disagree with that too. So what is the way to decide that
> something makes the cut for the "Source Code" section?
>
> I think as an extension author there are usually three types of
> changes that are relevant:
> 1. New APIs/hooks that are meant for extension authors
> 2. Stuff that causes my existing code to not compile anymore
> 3. Stuff that changes behaviour of existing APIs code in a
> incompatible but silent way
>
> For 1, I think adding them to the release notes makes total sense,
> especially if the new APIs are documented not only in source code, but
> also on the website. Nathan his change is of this type, so I agree
> with him it should be in the release notes.
+1. I think that the increment JSON parser that is already mentioned
in the release note would fall in this type too; it's not a feature
aimed just for extension authors, but it's kind of source and internal
changes IMO. Since the DSM registry feature is described in the doc, I
think it would make sense to have it in the release notes and probably
has a link to the "Requesting Shared Memory After Startup" section.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: First draft of PG 17 release notes
2024-09-07 09:55 Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
2024-09-10 02:46 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-10 06:28 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
2024-09-10 16:52 ` Re: First draft of PG 17 release notes Masahiko Sawada <[email protected]>
@ 2024-09-11 14:12 ` Bruce Momjian <[email protected]>
2024-09-11 14:36 ` Re: First draft of PG 17 release notes Nathan Bossart <[email protected]>
0 siblings, 1 reply; 17+ messages in thread
From: Bruce Momjian @ 2024-09-11 14:12 UTC (permalink / raw)
To: Masahiko Sawada <[email protected]>; +Cc: Jelte Fennema-Nio <[email protected]>; Alvaro Herrera <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Tue, Sep 10, 2024 at 09:52:42AM -0700, Masahiko Sawada wrote:
> On Mon, Sep 9, 2024 at 11:29 PM Jelte Fennema-Nio <[email protected]> wrote:
> >
> > On Tue, 10 Sept 2024 at 04:47, Bruce Momjian <[email protected]> wrote:
> > > Yes. There are so many changes at the source code level it is unwise to
> > > try and get them into the main release notes. If someone wants to
> > > create an addendum, like was suggested for pure performance
> > > improvements, that would make sense.
> >
> > I agree that the release notes cannot fit every change. But I also
> > don't think any extension author reads the complete git commit log
> > every release, so taking the stance that they should be seems
> > unhelpful. And the "Source Code" section does exist so at some level
> > you seem to disagree with that too. So what is the way to decide that
> > something makes the cut for the "Source Code" section?
> >
> > I think as an extension author there are usually three types of
> > changes that are relevant:
> > 1. New APIs/hooks that are meant for extension authors
> > 2. Stuff that causes my existing code to not compile anymore
> > 3. Stuff that changes behaviour of existing APIs code in a
> > incompatible but silent way
> >
> > For 1, I think adding them to the release notes makes total sense,
> > especially if the new APIs are documented not only in source code, but
> > also on the website. Nathan his change is of this type, so I agree
> > with him it should be in the release notes.
>
> +1. I think that the increment JSON parser that is already mentioned
> in the release note would fall in this type too; it's not a feature
> aimed just for extension authors, but it's kind of source and internal
> changes IMO. Since the DSM registry feature is described in the doc, I
> think it would make sense to have it in the release notes and probably
> has a link to the "Requesting Shared Memory After Startup" section.
This commit?
commit 8b2bcf3f287
Author: Nathan Bossart <[email protected]>
Date: Fri Jan 19 14:24:36 2024 -0600
Introduce the dynamic shared memory registry.
Yes, we have time to add it.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: First draft of PG 17 release notes
2024-09-07 09:55 Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
2024-09-10 02:46 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-10 06:28 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
2024-09-10 16:52 ` Re: First draft of PG 17 release notes Masahiko Sawada <[email protected]>
2024-09-11 14:12 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
@ 2024-09-11 14:36 ` Nathan Bossart <[email protected]>
2024-09-13 20:17 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
0 siblings, 1 reply; 17+ messages in thread
From: Nathan Bossart @ 2024-09-11 14:36 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Masahiko Sawada <[email protected]>; Jelte Fennema-Nio <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers
On Wed, Sep 11, 2024 at 10:12:58AM -0400, Bruce Momjian wrote:
> On Tue, Sep 10, 2024 at 09:52:42AM -0700, Masahiko Sawada wrote:
>> On Mon, Sep 9, 2024 at 11:29 PM Jelte Fennema-Nio <[email protected]> wrote:
>> > For 1, I think adding them to the release notes makes total sense,
>> > especially if the new APIs are documented not only in source code, but
>> > also on the website. Nathan his change is of this type, so I agree
>> > with him it should be in the release notes.
>>
>> +1. I think that the increment JSON parser that is already mentioned
>> in the release note would fall in this type too; it's not a feature
>> aimed just for extension authors, but it's kind of source and internal
>> changes IMO. Since the DSM registry feature is described in the doc, I
>> think it would make sense to have it in the release notes and probably
>> has a link to the "Requesting Shared Memory After Startup" section.
>
> This commit?
>
> commit 8b2bcf3f287
> Author: Nathan Bossart <[email protected]>
> Date: Fri Jan 19 14:24:36 2024 -0600
>
> Introduce the dynamic shared memory registry.
>
> Yes, we have time to add it.
Yes, that's the one.
--
nathan
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: First draft of PG 17 release notes
2024-09-07 09:55 Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
2024-09-10 02:46 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-10 06:28 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
2024-09-10 16:52 ` Re: First draft of PG 17 release notes Masahiko Sawada <[email protected]>
2024-09-11 14:12 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-11 14:36 ` Re: First draft of PG 17 release notes Nathan Bossart <[email protected]>
@ 2024-09-13 20:17 ` Bruce Momjian <[email protected]>
2024-09-13 21:00 ` Re: First draft of PG 17 release notes Nathan Bossart <[email protected]>
0 siblings, 1 reply; 17+ messages in thread
From: Bruce Momjian @ 2024-09-13 20:17 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Masahiko Sawada <[email protected]>; Jelte Fennema-Nio <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers
On Wed, Sep 11, 2024 at 09:36:35AM -0500, Nathan Bossart wrote:
> On Wed, Sep 11, 2024 at 10:12:58AM -0400, Bruce Momjian wrote:
> > On Tue, Sep 10, 2024 at 09:52:42AM -0700, Masahiko Sawada wrote:
> >> On Mon, Sep 9, 2024 at 11:29 PM Jelte Fennema-Nio <[email protected]> wrote:
> >> > For 1, I think adding them to the release notes makes total sense,
> >> > especially if the new APIs are documented not only in source code, but
> >> > also on the website. Nathan his change is of this type, so I agree
> >> > with him it should be in the release notes.
> >>
> >> +1. I think that the increment JSON parser that is already mentioned
> >> in the release note would fall in this type too; it's not a feature
> >> aimed just for extension authors, but it's kind of source and internal
> >> changes IMO. Since the DSM registry feature is described in the doc, I
> >> think it would make sense to have it in the release notes and probably
> >> has a link to the "Requesting Shared Memory After Startup" section.
> >
> > This commit?
> >
> > commit 8b2bcf3f287
> > Author: Nathan Bossart <[email protected]>
> > Date: Fri Jan 19 14:24:36 2024 -0600
> >
> > Introduce the dynamic shared memory registry.
> >
> > Yes, we have time to add it.
>
> Yes, that's the one.
Attached patch applied, with commit URL link.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"
Attachments:
[text/x-diff] REL_17_STABLE.diff (893B, ../../[email protected]/2-REL_17_STABLE.diff)
download | inline diff:
diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index 8aed30428bd..36e19bb8329 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -3011,6 +3011,23 @@ Author: Michael Paquier <[email protected]>
</para>
</listitem>
+<!--
+Author: Nathan Bossart <[email protected]>
+2024-01-19 [8b2bcf3f2] Introduce the dynamic shared memory registry.
+-->
+
+ <listitem>
+ <para>
+ Add dynamic shared memory registry (Nathan Bossart)
+ <ulink url="&commit_baseurl;8b2bcf3f2">§</ulink>
+ </para>
+
+ <para>
+ This allows shared libraries which are not initialized at startup
+ to coordinate dynamic shared memory access.
+ </para>
+ </listitem>
+
<!--
Author: Michael Paquier <[email protected]>
2024-04-04 [2a217c371] Coordinate emit_log_hook and all log destinations to sha
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: First draft of PG 17 release notes
2024-09-07 09:55 Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
2024-09-10 02:46 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-10 06:28 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
2024-09-10 16:52 ` Re: First draft of PG 17 release notes Masahiko Sawada <[email protected]>
2024-09-11 14:12 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-11 14:36 ` Re: First draft of PG 17 release notes Nathan Bossart <[email protected]>
2024-09-13 20:17 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
@ 2024-09-13 21:00 ` Nathan Bossart <[email protected]>
0 siblings, 0 replies; 17+ messages in thread
From: Nathan Bossart @ 2024-09-13 21:00 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Masahiko Sawada <[email protected]>; Jelte Fennema-Nio <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers
On Fri, Sep 13, 2024 at 04:17:31PM -0400, Bruce Momjian wrote:
> Attached patch applied, with commit URL link.
Looks good, thanks.
--
nathan
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: First draft of PG 17 release notes
2024-09-07 09:55 Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
2024-09-10 02:46 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-10 06:28 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
@ 2024-09-11 14:10 ` Bruce Momjian <[email protected]>
2024-09-17 08:01 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
2 siblings, 1 reply; 17+ messages in thread
From: Bruce Momjian @ 2024-09-11 14:10 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Tue, Sep 10, 2024 at 08:28:42AM +0200, Jelte Fennema-Nio wrote:
> I think as an extension author there are usually three types of
> changes that are relevant:
> 1. New APIs/hooks that are meant for extension authors
> 2. Stuff that causes my existing code to not compile anymore
> 3. Stuff that changes behaviour of existing APIs code in a
> incompatible but silent way
>
> For 1, I think adding them to the release notes makes total sense,
> especially if the new APIs are documented not only in source code, but
> also on the website. Nathan his change is of this type, so I agree
> with him it should be in the release notes.
>
> For 2, I'll be able to easily find the PG commit that caused the
> compilation failure by grepping git history for the old API. So having
> these changes in the release notes seems unnecessary.
>
> For 3, it would be very useful if it would be in the release notes,
> but I think in many cases it's hard to know what commits do this. So
> unless it's obviously going to break a bunch of extensions silently, I
> think we don't have to add such changes to the release notes.
So, we are looking at this commit:
commit b5a9b18cd0b
Author: Thomas Munro <[email protected]>
Date: Wed Apr 3 00:17:06 2024 +1300
Provide API for streaming relation data.
Introduce an abstraction allowing relation data to be accessed as a
stream of buffers, with an implementation that is more efficient than
the equivalent sequence of ReadBuffer() calls.
Client code supplies a callback that can say which block number it wants
next, and then consumes individual buffers one at a time from the
stream. This division puts read_stream.c in control of how far ahead it
can see and allows it to read clusters of neighboring blocks with
StartReadBuffers(). It also issues POSIX_FADV_WILLNEED advice ahead of
time when random access is detected.
Other variants of I/O stream will be proposed in future work (for
example to support recovery, whose LsnReadQueue device in
xlogprefetcher.c is a distant cousin of this code and should eventually
be replaced by this), but this basic API is sufficient for many common
executor usage patterns involving predictable access to a single fork of
a single relation.
Several patches using this API are proposed separately.
This stream concept is loosely based on ideas from Andres Freund on how
we should pave the way for later work on asynchronous I/O.
You are right that I do mention changes specifically designed for the
use of extensions, but there is no mention in the commit message of its
use for extensions. In fact, I thought this was too low-level to be of
use for extensions. However, if people feel it should be added, we have
enough time to add it.
I also mention changes that are _likely_ to affect extensions, but not
all changes that could affect extensions. An interesting idea would be
to report all function signature changes in each major release in some
way.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: First draft of PG 17 release notes
2024-09-07 09:55 Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
2024-09-10 02:46 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-10 06:28 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
2024-09-11 14:10 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
@ 2024-09-17 08:01 ` Jelte Fennema-Nio <[email protected]>
2024-09-18 21:33 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
0 siblings, 1 reply; 17+ messages in thread
From: Jelte Fennema-Nio @ 2024-09-17 08:01 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Wed, 11 Sept 2024 at 16:10, Bruce Momjian <[email protected]> wrote:
> You are right that I do mention changes specifically designed for the
> use of extensions, but there is no mention in the commit message of its
> use for extensions. In fact, I thought this was too low-level to be of
> use for extensions. However, if people feel it should be added, we have
> enough time to add it.
Another new API that is useful for extension authors is the following
one (I'm obviously biased since I'm the author, and I don't know if
there's still time):
commit 14dd0f27d7cd56ffae9ecdbe324965073d01a9ff
Author: Nathan Bossart <[email protected]>
Date: Thu Jan 4 16:09:34 2024 -0600
Add macros for looping through a List without a ListCell.
Many foreach loops only use the ListCell pointer to retrieve the
content of the cell, like so:
ListCell *lc;
foreach(lc, mylist)
{
int myint = lfirst_int(lc);
...
}
This commit adds a few convenience macros that automatically
declare the loop variable and retrieve the current cell's contents.
This allows us to rewrite the previous loop like this:
foreach_int(myint, mylist)
{
...
}
> An interesting idea would be
> to report all function signature changes in each major release in some
> way.
I think that might be useful, but it very much depends how long that
list gets. If it gets too long I think authors will just try to
compile and only look at the ones that break for them.
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: First draft of PG 17 release notes
2024-09-07 09:55 Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
2024-09-10 02:46 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-10 06:28 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
2024-09-11 14:10 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-17 08:01 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
@ 2024-09-18 21:33 ` Bruce Momjian <[email protected]>
2024-09-19 01:09 ` Re: First draft of PG 17 release notes Nathan Bossart <[email protected]>
0 siblings, 1 reply; 17+ messages in thread
From: Bruce Momjian @ 2024-09-18 21:33 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Nathan Bossart <[email protected]>; pgsql-hackers
On Tue, Sep 17, 2024 at 10:01:28AM +0200, Jelte Fennema-Nio wrote:
> On Wed, 11 Sept 2024 at 16:10, Bruce Momjian <[email protected]> wrote:
> > You are right that I do mention changes specifically designed for the
> > use of extensions, but there is no mention in the commit message of its
> > use for extensions. In fact, I thought this was too low-level to be of
> > use for extensions. However, if people feel it should be added, we have
> > enough time to add it.
>
> Another new API that is useful for extension authors is the following
> one (I'm obviously biased since I'm the author, and I don't know if
> there's still time):
>
> commit 14dd0f27d7cd56ffae9ecdbe324965073d01a9ff
> Author: Nathan Bossart <[email protected]>
> Date: Thu Jan 4 16:09:34 2024 -0600
>
> Add macros for looping through a List without a ListCell.
>
> Many foreach loops only use the ListCell pointer to retrieve the
> content of the cell, like so:
>
> ListCell *lc;
>
> foreach(lc, mylist)
> {
> int myint = lfirst_int(lc);
>
> ...
> }
>
> This commit adds a few convenience macros that automatically
> declare the loop variable and retrieve the current cell's contents.
> This allows us to rewrite the previous loop like this:
>
> foreach_int(myint, mylist)
> {
> ...
> }
Can someone else comment on the idea of adding this release note item?
I don't feel confident in my ability to evaluate this. I obviously did
not see it as significant the first time.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: First draft of PG 17 release notes
2024-09-07 09:55 Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
2024-09-10 02:46 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-10 06:28 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
2024-09-11 14:10 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-17 08:01 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
2024-09-18 21:33 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
@ 2024-09-19 01:09 ` Nathan Bossart <[email protected]>
2024-09-19 16:23 ` Re: First draft of PG 17 release notes Robert Haas <[email protected]>
0 siblings, 1 reply; 17+ messages in thread
From: Nathan Bossart @ 2024-09-19 01:09 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Jelte Fennema-Nio <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers
On Wed, Sep 18, 2024 at 05:33:18PM -0400, Bruce Momjian wrote:
> On Tue, Sep 17, 2024 at 10:01:28AM +0200, Jelte Fennema-Nio wrote:
>> Another new API that is useful for extension authors is the following
>> one (I'm obviously biased since I'm the author, and I don't know if
>> there's still time):
>>
>> Add macros for looping through a List without a ListCell.
>
> Can someone else comment on the idea of adding this release note item?
> I don't feel confident in my ability to evaluate this. I obviously did
> not see it as significant the first time.
I'm not sure precisely what criteria you use to choose what goes in the
release notes, but this one seems like a judgement call to me. My initial
reaction is that it shouldn't be included, but I do see some items with a
similar scope, such as "Remove some SPI macros."
--
nathan
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: First draft of PG 17 release notes
2024-09-07 09:55 Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
2024-09-10 02:46 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-10 06:28 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
2024-09-11 14:10 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-17 08:01 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
2024-09-18 21:33 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-19 01:09 ` Re: First draft of PG 17 release notes Nathan Bossart <[email protected]>
@ 2024-09-19 16:23 ` Robert Haas <[email protected]>
2024-09-19 17:04 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
0 siblings, 1 reply; 17+ messages in thread
From: Robert Haas @ 2024-09-19 16:23 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Jelte Fennema-Nio <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers
On Wed, Sep 18, 2024 at 9:09 PM Nathan Bossart <[email protected]> wrote:
> On Wed, Sep 18, 2024 at 05:33:18PM -0400, Bruce Momjian wrote:
> > On Tue, Sep 17, 2024 at 10:01:28AM +0200, Jelte Fennema-Nio wrote:
> >> Another new API that is useful for extension authors is the following
> >> one (I'm obviously biased since I'm the author, and I don't know if
> >> there's still time):
> >>
> >> Add macros for looping through a List without a ListCell.
> >
> > Can someone else comment on the idea of adding this release note item?
> > I don't feel confident in my ability to evaluate this. I obviously did
> > not see it as significant the first time.
>
> I'm not sure precisely what criteria you use to choose what goes in the
> release notes, but this one seems like a judgement call to me. My initial
> reaction is that it shouldn't be included, but I do see some items with a
> similar scope, such as "Remove some SPI macros."
I wouldn't mention either this or "Remove some unused SPI macros".
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: First draft of PG 17 release notes
2024-09-07 09:55 Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
2024-09-10 02:46 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-10 06:28 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
2024-09-11 14:10 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-17 08:01 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
2024-09-18 21:33 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-19 01:09 ` Re: First draft of PG 17 release notes Nathan Bossart <[email protected]>
2024-09-19 16:23 ` Re: First draft of PG 17 release notes Robert Haas <[email protected]>
@ 2024-09-19 17:04 ` Bruce Momjian <[email protected]>
2024-09-19 17:23 ` Re: First draft of PG 17 release notes Robert Haas <[email protected]>
0 siblings, 1 reply; 17+ messages in thread
From: Bruce Momjian @ 2024-09-19 17:04 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Nathan Bossart <[email protected]>; Jelte Fennema-Nio <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers
On Thu, Sep 19, 2024 at 12:23:21PM -0400, Robert Haas wrote:
> On Wed, Sep 18, 2024 at 9:09 PM Nathan Bossart <[email protected]> wrote:
> > On Wed, Sep 18, 2024 at 05:33:18PM -0400, Bruce Momjian wrote:
> > > On Tue, Sep 17, 2024 at 10:01:28AM +0200, Jelte Fennema-Nio wrote:
> > >> Another new API that is useful for extension authors is the following
> > >> one (I'm obviously biased since I'm the author, and I don't know if
> > >> there's still time):
> > >>
> > >> Add macros for looping through a List without a ListCell.
> > >
> > > Can someone else comment on the idea of adding this release note item?
> > > I don't feel confident in my ability to evaluate this. I obviously did
> > > not see it as significant the first time.
> >
> > I'm not sure precisely what criteria you use to choose what goes in the
> > release notes, but this one seems like a judgement call to me. My initial
> > reaction is that it shouldn't be included, but I do see some items with a
> > similar scope, such as "Remove some SPI macros."
>
> I wouldn't mention either this or "Remove some unused SPI macros".
I mentioned the SPI macros because that could lead to breakage, and
there might be applications, as well as extensions, that use it.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: First draft of PG 17 release notes
2024-09-07 09:55 Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
2024-09-10 02:46 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-10 06:28 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
2024-09-11 14:10 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-17 08:01 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
2024-09-18 21:33 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-19 01:09 ` Re: First draft of PG 17 release notes Nathan Bossart <[email protected]>
2024-09-19 16:23 ` Re: First draft of PG 17 release notes Robert Haas <[email protected]>
2024-09-19 17:04 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
@ 2024-09-19 17:23 ` Robert Haas <[email protected]>
0 siblings, 0 replies; 17+ messages in thread
From: Robert Haas @ 2024-09-19 17:23 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Nathan Bossart <[email protected]>; Jelte Fennema-Nio <[email protected]>; Alvaro Herrera <[email protected]>; pgsql-hackers
On Thu, Sep 19, 2024 at 1:04 PM Bruce Momjian <[email protected]> wrote:
> I mentioned the SPI macros because that could lead to breakage, and
> there might be applications, as well as extensions, that use it.
Sure, this is all a judgement call. I don't think it's particularly
likely that many people are relying on those macros, though, and if
they are, they will mostly likely find out that they're gone when they
try to compile, rather than from reading the release notes. Likewise,
I feel that the new list iteration macros are both optional and minor,
so there's not really a reason to tell people about them. But opinions
will vary, and that's fine. I just mentioned my opinion since you
seemed to be asking. :-)
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 17+ messages in thread
end of thread, other threads:[~2024-09-19 17:23 UTC | newest]
Thread overview: 17+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-03-12 21:35 [PATCH v9 8/9] Default to zstd.. Justin Pryzby <[email protected]>
2024-09-07 09:55 Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
2024-09-10 02:46 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-10 06:28 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
2024-09-10 08:51 ` Re: First draft of PG 17 release notes Alvaro Herrera <[email protected]>
2024-09-10 16:52 ` Re: First draft of PG 17 release notes Masahiko Sawada <[email protected]>
2024-09-11 14:12 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-11 14:36 ` Re: First draft of PG 17 release notes Nathan Bossart <[email protected]>
2024-09-13 20:17 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-13 21:00 ` Re: First draft of PG 17 release notes Nathan Bossart <[email protected]>
2024-09-11 14:10 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-17 08:01 ` Re: First draft of PG 17 release notes Jelte Fennema-Nio <[email protected]>
2024-09-18 21:33 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-19 01:09 ` Re: First draft of PG 17 release notes Nathan Bossart <[email protected]>
2024-09-19 16:23 ` Re: First draft of PG 17 release notes Robert Haas <[email protected]>
2024-09-19 17:04 ` Re: First draft of PG 17 release notes Bruce Momjian <[email protected]>
2024-09-19 17:23 ` Re: First draft of PG 17 release notes Robert Haas <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox