On Thu, Apr 24, 2025 at 04:51:08PM +0200, Álvaro Herrera wrote:
> On 2025-Apr-24, 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? And if
> > so, do we th
On Thu, Apr 24, 2025 at 08:51:41AM -0400, Greg Sabino Mullane wrote:
> 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
On Thu, Apr 24, 2025 at 08:35:10AM -0400, Greg Sabino Mullane wrote:
> 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?
>
>
asking anyway.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
On Wed, Apr 16, 2025 at 01:43:46PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Apr 14, 2025 at 10:38:29AM -0400, Robert Haas wrote:
> >> I agree that we should do something about this. I haven't reviewed
> >> your patches but the approach sounds br
query.
>
> I agree that we should do something about this. I haven't reviewed
> your patches but the approach sounds broadly reasonable.
Yep, we went down the road in PG 18 to convert syntax, and now we have
to fix this, or we have to revert all the PG 18 syntax changes, which
seems l
there's probably some value in keeping it similar to what
> people are used to seeing.
FYI, I researched these messages in 2023 to see if the message can be
adjusted based on the code line generating the message, but with no
conclusion:
https://www.postgresql.org/mes
On Tue, Apr 8, 2025 at 09:17:03AM -0700, Jacob Champion wrote:
> On Tue, Apr 8, 2025 at 9:14 AM Bruce Momjian wrote:
> > How does this patch help us avoid having to handle curl CVEs and its
> > curl's additional dependencies? As I understand the patch, it makes
> > l
asking too. For me it was curl's
security reputation and whether that would taint the security reputation
of libpq. For Tom, I think it was the dependency additions.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
On Tue, Apr 8, 2025 at 06:42:19PM +0200, Daniel Gustafsson wrote:
> > On 8 Apr 2025, at 18:33, Bruce Momjian wrote:
>
> > Would we have to put out minor releases for curl CVEs? I don't think we
> > have to for OpenSSL so would curl be the same?
>
> Why do y
On Tue, Apr 8, 2025 at 02:11:19PM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-04-08 13:02:11 -0400, Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 06:57:18PM +0200, Wolfgang Walther wrote:
> > > Jacob Champion:
> > > > On Tue, Apr 8, 2025 at 9:32
d client dependencies. I'm not sure.
Well, if we think we are going to do that, it seems we would need a
different architecture than the one being proposed for PG 18, which
could lead to a lot of user/developer API churn.
--
Bruce Momjian https://momjian.us
EDB
On Tue, Apr 8, 2025 at 10:00:56AM -0700, Jacob Champion wrote:
> On Tue, Apr 8, 2025 at 9:49 AM Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 09:43:01AM -0700, Jacob Champion wrote:
> > > By adding the new .so to a different package. For example, RPM specs
> > >
On Tue, Apr 8, 2025 at 09:43:01AM -0700, Jacob Champion wrote:
> On Tue, Apr 8, 2025 at 9:33 AM Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 09:17:03AM -0700, Jacob Champion wrote:
> > > It allows packagers to ship the OAuth library separately, so end users
> &g
ng as it is before April 18 midnight wherever you are, it
is not feature freeze yet.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
On Tue, Apr 8, 2025 at 06:00:27PM +0200, Peter Eisentraut wrote:
> On 08.04.25 16:59, Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
> > > Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
> > > Earth):
it?
How does this patch help us avoid having to handle curl CVEs and its
curl's additional dependencies? As I understand the patch, it makes
libpq _not_ have additional dependencies but moves the dependencies to a
special loadable library that libpq can use.
--
Bruce Momjian https:/
pre-installation testing.
> > (Contrast with the server, which is able to relocate extension paths
> > based on its executable location.)
>
> That strikes me as a signifant drawback.
Uh, where are we on the inclusion of curl in our build? Maybe it was
explained b
On Tue, Apr 8, 2025 at 11:20:11AM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-04-08 11:13:51 -0400, Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 08:04:22AM -0700, Jacob Champion wrote:
> > > On Tue, Apr 8, 2025 at 7:32 AM Bruce Momjian wrote:
> > > >
On Tue, Apr 8, 2025 at 08:04:22AM -0700, Jacob Champion wrote:
> On Tue, Apr 8, 2025 at 7:32 AM Bruce Momjian wrote:
> > Uh, where are we on the inclusion of curl in our build? Maybe it was
> > explained but I have not seen it.
>
> The above is discussing a patch to sp
On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
> Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
> Earth):
>
>
> https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items#Important_Dates
> https://www.timeanddate.com/time/zon
Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
Earth):
https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items#Important_Dates
https://www.timeanddate.com/time/zones/aoe
and it is now 2:34 AM AoE, I guess we are now in feature freeze.
--
Bruce
On Thu, Jan 30, 2025 at 08:26:54AM -0500, Bruce Momjian wrote:
> On Wed, Jan 8, 2025 at 04:24:34PM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > I think this needs some serious research.
> >
> > We've discussed this topic before. The spec&#x
moved.
>
> Yeah, at least not without a solid use case. (If anyone does feel
> motivated to pick it up, be aware of the server-side SNI work [1].
> It'd be nice if the two halves were complementary -- or at minimum,
> not clashing with each othe
be created
> > without infunc and outfunc.
>
> I rebased the patch 0001 and add the documentation to it.
Okay, this is too late for PG 18 but I am hopeful we can make progress
on this for PG 19.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
One observation is that security scanning tools are going to see the
curl dependency and look at any CSVs related to them and ask us, whether
they are using OAUTH or not.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
kagers will use the --with-libcurl configure option?
It does kind of make sense for curl to handle OAUTH since curl has to
simulate a browser. I assume we can't call a shell to invoke curl from
the command line.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
and if they don't their connections will just fail,
> presumably with some error message explaining why. Or something like
> that...
Am I understanding that curl is being used just to honor the RFC and it
is only for testing? That seems like a small reason to add such a
depende
user change is still being
debated in mid-March, when the feature freeze is only a few weeks away.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
me.
>
>
> This is not quite a hill that I wish to die on, but I will
> flatly predict that we will regret this.
I regularly see curl security fixes in my Debian updates, so there is a
security issue that any serious curl bug could also make Postgres
vulnerable. I might be w
On Tue, Mar 18, 2025 at 10:16:20PM -0400, Bruce Momjian wrote:
> With the last commitfest underway:
>
> https://commitfest.postgresql.org/52/
>
> the release team has decided that the feature freeze deadline will be
> April 8, 2025, time zone Anywhere on E
With the last commitfest underway:
https://commitfest.postgresql.org/52/
the release team has decided that the feature freeze deadline will be
April 8, 2025, time zone Anywhere on Earth (AoE) (UTC-12):
https://www.timeanddate.com/time/zones/aoe
--
Bruce Momjian
On Tue, Mar 18, 2025 at 04:13:26PM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-03-18 16:08:22 -0400, Bruce Momjian wrote:
> > This commit makes our default random_page_cost = 4 out of line with
> > these new settings (assumes modern SSD/NAS/SAN hardware) and more out of
On Tue, Mar 18, 2025 at 05:04:46PM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-03-18 16:35:29 -0400, Bruce Momjian wrote:
> > Uh, the random_page_cost = 4 assumes caching, so it is assuming actual
> > random I/O to be 40x slower, which I doubt is true f
On Tue, Mar 18, 2025 at 04:27:18PM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-03-18 16:22:45 -0400, Bruce Momjian wrote:
> > On Tue, Mar 18, 2025 at 04:13:26PM -0400, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2025-03-18 16:08:22 -0400, Bruce Mo
lighted to hear that, if
> that's what you found from talking to a legal team, but it's not clear
> to me.
Contributing code is copyright, which is unrelated to patents. I don't
think the Postgres community even has a method of accepting patent usage
grants.
--
Bruce Momji
pg_upgrade docs mention taking a backup, but that's always step 0 in
> my playbook, and that's the rollback plan in the unlikely event of failure.
I avoided many optimizations in pg_upgrade in the fear they would lead
to hard-to-detect bugs, or breakage from major release changes.
pg_upgra
, please let me know.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
On Tue, Feb 18, 2025 at 11:39:54PM +0100, Jelte Fennema-Nio wrote:
> On Tue, 18 Feb 2025 at 22:15, Bruce Momjian wrote:
> > Looking at the live version, I can sort the "Stats" column from smallest
> > to largest, but not from largest to smallest. Is this intended?
>
le, though I don't see much of an use-case for this.
Looking at the live version, I can sort the "Stats" column from smallest
to largest, but not from largest to smallest. Is this intended?
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
On Wed, Jan 8, 2025 at 04:24:34PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I think this needs some serious research.
>
> We've discussed this topic before. The spec's definition of IS [NOT]
> NULL for composite values is bizarre to say the least
On Tue, Jan 21, 2025 at 03:23:31PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I did write a patch in Novemer 2023 to pass the dimension to the layers
> > that needed it, but it was considered too much code compared to its
> > value:
> > https://ww
On Fri, Jan 17, 2025 at 03:47:28PM +0100, Álvaro Herrera wrote:
> On 2025-Jan-17, Bruce Momjian wrote:
>
> > Is this really something we are considering applying, since it has been
> > around for years? I am unclear on that and we had better know if we are
> > going to
On Sun, Jan 19, 2025 at 06:47:14PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Using the queries in that URL, I see:
>
> > CREATE TABLE test (data integer, data_array integer[5][5]);
> > CREATE TABLE test2 (LIKE test);
> > CREATE TAB
On Fri, Jan 17, 2025 at 04:55:07PM +0100, Pavel Stehule wrote:
> pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian napsal:
>
> So this feature would be like global GUC variables, with permission
> control?
>
> + types and domain type check - holds data in binary fo
n session variables. At the end
> session variables are trivial against global temp tables, and can replace
> global temp tables in some use cases.
> And the solution can be nicer, cleaner, safer than with a workaround based on
> GUC.
So this feature would be like global GUC variables, wi
On Fri, Jan 17, 2025 at 02:48:29PM +0100, Pavel Stehule wrote:
> Hi
>
> pá 17. 1. 2025 v 14:41 odesílatel Bruce Momjian napsal:
>
> On Fri, Jan 17, 2025 at 08:18:20AM +0100, Pavel Stehule wrote:
> > Hi
> >
> > fix oid collision
>
> Wha
On Fri, Jan 17, 2025 at 08:18:20AM +0100, Pavel Stehule wrote:
> Hi
>
> fix oid collision
What is the purpose of continually posting this patch to the email
lists?
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
D
On Wed, Jan 8, 2025 at 04:24:34PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I think this needs some serious research.
>
> We've discussed this topic before. The spec's definition of IS [NOT]
> NULL for composite values is bizarre to say the least
IS NULL;
col | ?column?
-+--
(,) | t
EXPLAIN SELECT col, col IS NULL FROM complex_test WHERE col IS NULL;
QUERY PLAN
--
Seq Scan on complex_
On Wed, Jan 8, 2025 at 03:21:27PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Will people now always get a clear error on failure? Crazy idea, but
> > could we have initdb or postmaster start test this?
>
> It'd require adding quite a lot of cycles: I'
d for any user trying to figure out if their setup is
> compliant, though. In many setups (especially production) a drop database is
> rare.
Will people now always get a clear error on failure? Crazy idea, but
could we have initdb or postmaster start test this?
--
Bruce Momjian http
to
> miss or double-process files in every one of them.
>
> I'm still of the opinion that the best thing to do is disclaim
> safety of storing a database on NFS.
It would be nice to have some details on the docs about why NFS can
cause problems s
On Wed, Jan 1, 2025 at 08:43:40PM -0500, Roberto C. Sánchez wrote:
> On Wed, Jan 01, 2025 at 01:32:18PM -0500, Bruce Momjian wrote:
> >
> > Actually, there is another concern. Debian users who are using these 6+
> > year-old releases might think the release is supported by
On Tue, Dec 31, 2024 at 03:52:07PM -0500, Bruce Momjian wrote:
> On Tue, Dec 31, 2024 at 01:47:19PM -0700, David G. Johnston wrote:
> > On Tue, Dec 31, 2024 at 1:30 PM Bruce Momjian wrote:
> >
> > On Tue, Dec 31, 2024 at 03:19:25PM -0500, Roberto C. Sánchez wrote:
>
On Tue, Dec 31, 2024 at 01:47:19PM -0700, David G. Johnston wrote:
> On Tue, Dec 31, 2024 at 1:30 PM Bruce Momjian wrote:
>
> On Tue, Dec 31, 2024 at 03:19:25PM -0500, Roberto C. Sánchez wrote:
>
> > My thinking was "ask once, bump the thread once after 2 or 3 wee
On Tue, Dec 31, 2024 at 03:19:25PM -0500, Roberto C. Sánchez wrote:
> On Tue, Dec 31, 2024 at 02:46:37PM -0500, Bruce Momjian wrote:
> >
> > Good question. In a way, if the person who made the change sees your
> > request and can answer it easily, it makes sense to ask.
On Tue, Dec 31, 2024 at 12:14:37PM -0500, Roberto C. Sánchez wrote:
> On Tue, Dec 31, 2024 at 11:50:45AM -0500, Bruce Momjian wrote:
> > On Tue, Dec 31, 2024 at 10:50:10AM +0100, Christoph Berg wrote:
> > > > Maybe, if we were doing an only-critical-fixes LTS release series,
&
gt;
> Overall, I think the current 5-year support window is good enough.
> I don't see PostgreSQL supporting 10 years, so ELTS efforts will
> always have to do some patching on their own.
Thanks, that was very helpful.
--
Bruce Momjian https://momjian.us
EDB
buildfarm changes that might require.
> Probably just adjust how we manage branches_of_interest.txt, but maybe
> there's something I haven't thought of.
Ubuntu does LTS every two years but has three releases in between.
Since we have yearly releases, an LTS every two years only cuts our
backpatches
do have a small (paid) team that tries
> to support a specific subset of packages going back longer than 5 years.
>
> If my request is not reasonable or somehow inappropriate, then please
> consider it withdrawn.
I think it is good you are asking --- I just don't know if anyone ca
ed versions of Postgres that we don't support? Is this part of
Debian policy? Is our five-year insufficient?
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
On Mon, Dec 30, 2024 at 12:02:47PM -0800, Jeff Davis wrote:
> On Thu, 2024-12-26 at 13:54 -0500, Bruce Momjian wrote:
> > I am _again_ not happy with this part of the patch. Please reply to
> > the
> > criticism in my November 19th email:
> >
> >
>
rewarming purposes.
Yeah, the ranage-of-blocks case is rare, and I hoped to explain it in
the docs, but it seems like that isn't helping, so I retract my patch.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
you get back from BUFFERS are not as big of a problem as
> they might seem.
I certainly would love to see storage I/O numbers as distinct from
kernel read I/O numbers.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
ter startup isn't a problem - while reading blocks from disk
> for the first time. After the first read, blocks that are frequently
> accessed will remain in the cache. The Postgres cache management
> algorithm works well in general.
>
> This is my two cents, anyway
It feels
27;t contain any abbreviations.
> (If it didn't then we'd not have such a problem...)
>
> > But that said I personally only use ISO timestamps with numerical
> > offsets. Partially to avoid all this mess.
>
> If you only use ISO notation then this doe
, the sign of "char" is undetermined.) We display the data
type and value as "Int32(8)", which looks more like a function call than
what is represents. Any ideas on how to improvem that?
--
Bruce Momjian https://momjian.us
EDB htt
On Fri, Dec 27, 2024 at 12:25:11PM -0500, Greg Sabino Mullane wrote:
> On Fri, Dec 27, 2024 at 10:12 AM Bruce Momjian wrote:
>
> The value of TDE is limited from a security value perspective, but high on
> the list of security policy requirements. Our community
required, I think the balance tilted to
TDE requiring too many code changes given its security value (not policy
compliance value).
At least that is my analysis, and part of me wishes I was wrong. I know
there are several commercial forks of TDE, mostly because companies are
more sensitive to po
the kernel log, which might have
more details of what XFS is having problems with.
I agree trying to modify Postgres for this now makes no sense since we
don't even know the cause. Once we find the cause, and admit it can't
be avoided or quickly fixed, we can reevaluate.
--
exist: oid + oid
LINE 1: SELECT 42::oid + 1::oid;
^
HINT: No operator matches the given name and argument types. You might
need to add explicit type casts.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
On Thu, Dec 26, 2024 at 05:08:36PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > So, if users are referencing attndims and the values are not accurate,
> > how useful are they? I was suggesting removal so people would stop
> > relying on inaccurate information, or we c
. Allowing people to continue relying on inaccurate information
seems like the worst of all options.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
truly
> wanted it.
I am _again_ not happy with this part of the patch. Please reply to the
criticism in my November 19th email:
https://www.postgresql.org/message-id/zz0t1benifdnx...@momjian.us
rather than ignoring it and posting the same version of the patch.
--
Bruce Momjian
sspelling:
+ printf(_(" --no-statisttics do not import statistics from
old cluster\n"));
--
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
On Thu, Dec 5, 2024 at 12:03:30PM -0500, Bruce Momjian wrote:
> On Thu, Dec 5, 2024 at 12:00:30PM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Thu, Dec 5, 2024 at 11:33:22AM -0500, Tom Lane wrote:
> > >> I don't think we can do th
On Thu, Dec 5, 2024 at 12:00:30PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Dec 5, 2024 at 11:33:22AM -0500, Tom Lane wrote:
> >> I don't think we can do this as presented. Maybe we could do
> >> something like constrain the stored value to b
help
update the list.
Their email address at the bottom:
contribut...@postgresql.org
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
ld do
> something like constrain the stored value to be only 0 or 1,
> but how much does that improve matters?
Well, then the question becomes will we retain useless system columns
forever?
--
Bruce Momjian https://momjian.us
EDB https:
On Tue, Dec 3, 2024 at 03:58:20PM -0500, Bruce Momjian wrote:
> On Tue, Dec 3, 2024 at 09:05:45PM +0100, Peter Eisentraut wrote:
> > On 26.11.24 20:04, Bruce Momjian wrote:
> > > %.pdf: %.fo $(ALL_IMAGES)
> > > - $(FOP) -fo $< -pdf $@
> > > + LANG=C $(F
On Tue, Dec 3, 2024 at 09:03:37PM +0100, Peter Eisentraut wrote:
> On 03.12.24 04:13, Bruce Momjian wrote:
> > On Mon, Dec 2, 2024 at 09:33:39PM -0500, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Now that we have a warning about non-emittable characters in
On Tue, Dec 3, 2024 at 09:05:45PM +0100, Peter Eisentraut wrote:
> On 26.11.24 20:04, Bruce Momjian wrote:
> > %.pdf: %.fo $(ALL_IMAGES)
> > - $(FOP) -fo $< -pdf $@
> > + LANG=C $(FOP) -fo $< -pdf $@ 2>&1 | \
> > + awk 'BEGIN { warn = 0 }
On Mon, Dec 2, 2024 at 09:33:39PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Now that we have a warning about non-emittable characters in the PDF
> > build, do you want me to put back the Latin1 characters in the SGML
> > files or leave them as HTML entities?
>
On Tue, Nov 5, 2024 at 10:08:17AM +0100, Peter Eisentraut wrote:
> On 02.11.24 14:18, Bruce Momjian wrote:
> > On Sat, Nov 2, 2024 at 12:02:12PM +0900, Tatsuo Ishii wrote:
> > > > Yes, we _allow_ LATIN1 characters in the SGML docs, but I replaced the
> > > > L
On Tue, Nov 26, 2024 at 02:04:15PM -0500, Bruce Momjian wrote:
> On Tue, Nov 26, 2024 at 12:41:37PM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Tue, Nov 26, 2024 at 11:43:02AM -0500, Tom Lane wrote:
> > >> I don't think this patch is doing anythi
.
> This test didn't show any regressions with a relatively small number of bytes,
> and it showed the expected improvements with many bytes.
You must attach actual attachments for this to be considered. Download
links are unacceptable.
--
Bruce Momjian https://momjian
rotocol behavior go through a normal beta test cycle.
Yeah, I was surprised too, even though the author was clear they wanted
to backpatch. I couldn't figure out why it was being backpatched, so I
figured I was missing something.
--
Bruce Momjian https://momjian.us
EDB
e current patchset provides that in the form of the parameter
> "--force-analyze", which is a modifier to "--analyze-in-stages" and
> "--analyze-only".
I don't think there is consensus to change --analyze-only, only maybe
--analyze-in-sta
On Wed, Nov 27, 2024 at 11:44:25AM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2024-Nov-27, Bruce Momjian wrote:
> >> Would there be a default?
>
> > There would be no default. Running with no option given would raise an
> > error. The point is: yo
On Wed, Nov 27, 2024 at 04:57:35PM +0100, Álvaro Herrera wrote:
> On 2024-Nov-27, Bruce Momjian wrote:
> There would be no default. Running with no option given would raise an
> error. The point is: you want to break scripts currently running
> --analyze-in-stages so that they can m
On Wed, Nov 27, 2024 at 09:18:45AM -0600, Nathan Bossart wrote:
> On Wed, Nov 27, 2024 at 04:00:02PM +0100, Alvaro Herrera wrote:
> > On 2024-Nov-27, Bruce Momjian wrote:
> >
> >> On Wed, Nov 27, 2024 at 02:44:01PM +0100, Magnus Hagander wrote:
> >> > If you
til
> much
> later".
>
> That might trade some of that surprise and confusion for annoyance instead,
> but
> going forward that might be a clearer path?
Oh, so remove --analyze-in-stages and have it issue a suggestion, and
make two versions --- yeah, that would work
On Tue, Nov 26, 2024 at 12:41:37PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Nov 26, 2024 at 11:43:02AM -0500, Tom Lane wrote:
> >> I don't think this patch is doing anything I want at all.
>
> > Gee, I kind of liked the patch, but mayb
On Tue, Nov 26, 2024 at 11:43:02AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Do we want to add this complexity?
>
> I don't think this patch is doing anything I want at all.
Gee, I kind of liked the patch, but maybe you didn't like the additional
complexit
om the build? To allow such builds to
keep those PDF files, we would need to probably override
.DELETE_ON_ERROR, but it would have to be done in a way that an error
exit from FOP would still remove the PDF file. I think we would have to
have FOP write to a temporary file, and then override t
On Wed, Nov 20, 2024 at 10:12:55PM -0500, Jonathan Katz wrote:
> On 11/20/24 10:08 PM, Bruce Momjian wrote:
> > Yes, or for MacOS.
>
> Well, why did EDB remove them? We didn't issue any guidance to remove
> downloads. We only provided guidance to users on decision making
On Wed, Nov 20, 2024 at 09:51:09PM -0500, Jonathan Katz wrote:
> On 11/20/24 9:50 PM, Jonathan S. Katz wrote:
> > On 11/20/24 9:48 PM, Tom Lane wrote:
> > > "David G. Johnston" writes:
> > > > On Wed, Nov 20, 2024 at 7:18 PM Bruce Momjian wrote:
&g
On Wed, Nov 20, 2024 at 07:40:36PM -0700, David G. Johnston wrote:
> On Wed, Nov 20, 2024 at 7:18 PM Bruce Momjian wrote:
>
> so when we decided to remove the downloads
>
>
> Can you elaborate on who "we" is here?
>
> I don't recall this event happen
dates would be available within
> the next week.
Makes sense. This is the discussion I wanted to have. Thanks.
--
Bruce Momjian 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?"
1 - 100 of 1428 matches
Mail list logo
