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?"
fferently, but I am surprised we
didn't get more complaints about the security situation we put them in.
--
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?"
On Tue, Nov 5, 2024 at 05:24:07PM +0800, jian he wrote:
> On Thu, Oct 31, 2024 at 11:51 PM Bruce Momjian wrote:
> >
> > On Fri, Oct 18, 2024 at 10:00:54AM +0800, jian he wrote:
> > > On Fri, Oct 18, 2024 at 2:05 AM Bruce Momjian wrote:
> > > > Yes, updated
On Thu, Oct 17, 2024 at 02:24:33PM +0200, Daniel Gustafsson wrote:
> > On 17 Oct 2024, at 04:45, Bruce Momjian wrote:
>
> > I looked at this and decided the GUC section was illogical, so I just
> > moved the variables up into the be-secure.c section. Patch attached.
>
ove list. What we have now is too confusing.
--
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?"
comments, even if the archive
> contains them.
Fixed in the attached applied patch.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he means
"Am
On Tue, Nov 19, 2024 at 05:40:20PM -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2024 at 03:47:20PM -0500, Corey Huinker wrote:
> > * create a pg_stats_health_check script that lists tables missing stats,
> > with
> > --fix/--fix-in-stages options, effectively replaci
re
> are no significant backward compatibility or backpatching gotchas here.
>
> I'm more concerned that many of these just keep getting copied around
> indiscriminately, and this is liable to hide actual type mismatches or
> silently discard qualifiers. So I'm arguing in
king back when the function took JSON input, so it's do-able,
> but the difficulty lies in how to represent an array of incomplete
> pg_statistic
> rows in a serial fashion that is cross-version compatible.
I am not a big fan of that at this point. If we get it, we can adjust
our API at that time, but I don't want to plan on it.
--
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?"
On Mon, Nov 18, 2024 at 08:42:35PM -0500, Bruce Momjian wrote:
> On Mon, Nov 18, 2024 at 08:29:10PM -0500, Corey Huinker wrote:
> > That's not a great surprise for group 6, but I have to believe that group is
> > smaller than group 5, and it's definitely smaller than the
be
considered. The patch is smaller than I expected.
--
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?"
> I wonder we can get unified results if executed with LANG=C.
> The updated patch 0001 is fixed in this direction.
Yes, good idea.
> + @ ( $(PERL) -ne '/[\x80-\xFF]/ and `${ICONV} -t ISO-8859-1 -f UTF-8
> "$$ARGV" 2>/dev/null` and print("$$ARGV:$$_")
On Mon, Nov 18, 2024 at 08:29:10PM -0500, Corey Huinker wrote:
> On Mon, Nov 18, 2024 at 2:47 PM Bruce Momjian wrote:
> You seem to be optimizing for people using pg_upgrade, and for people
> upgrading to PG 18, without adequately considering people using vacuumdb
> in no
;SQL" in front of the command name is unnecessary [...]
>
> +1 for "Do not dump COMMENT commands", which is what I think you're
> saying.
Patch applied to master.
--
Bruce Momjian https://momjian.us
EDB https://enterpr
On Mon, Nov 18, 2024 at 06:36:45PM -0300, Marcos Pegoraro wrote:
> But it would be good to have this patch applied to all supported versions, as
> soon as nothing was changed on that pg_dump option, no ?
>
> Em seg., 18 de nov. de 2024 às 18:30, Bruce Momjian
> escreveu:
>
&g
ight be some possibilities.
>
> When a character that cannot be displayed in PDF is found, a warning
> "Glyph ... not available in font " is output in fop's log. We can
> prevent such characters from being contained in PDF by checking
> the me
a lot)
>
> ALTER TABLE your_schema.your_table SET
> (autovacuum_enabled,autovacuum_analyze_scale_factor,autovacuum_vacuum_scale_factor);
>
> Just wanted to mention
I don't think it would affect it since those control autovacuum, and we
are talking about manual vacuum/analyz
t; I agree the error message could be improved.
>
> The phrasing "Did you forget" feels a bit indirect to me.
> How about using something clearer and more direct instead?
>
> ---
> psql: error: unexpected spaces found "a b", use percent-encoded spaces ins
cating when the slot became inactive."
> >
> > Thoughts?
> >
> > For the description of synced slots on standby, I’m fine with keeping
> > Bruce's suggestion from patch [2] as it is.
> >
> > Attached the patch with modification.
> >
>
>
ed. It is usually necessary to periodically run a manual
ANALYZE to keep the statistics of the table hierarchy up to date.
Now, you can say partitioned table statistics are not as important as
extended statistics, but that fact remains that we have these two odd
cases where special work must be done to generate statistics.
--
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?"
already makes it more "standardized" than many parts of the SQL standard =)
Proposed patch attached.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he mean
Do not dump comments.
We could change it to:
--no-comments
Do not dump SQL COMMENT commands
I think this is someone with limited English ability, which could
explain the confusion.
--
Bruce Momjian https://momjian.us
EDB
vantage of this is, we don't need to covert each LATIN1
> characters to HTML entities and make the sgml file authors life a
> little bit easier.
I might have misread the feedback. I know people didn't want a Makfile
rule to prevent it, but I though converting few UTF8'
On Sat, Nov 2, 2024 at 07:27:00AM +0900, Tatsuo Ishii wrote:
> > On Wed, Oct 16, 2024 at 09:54:57AM -0400, Bruce Momjian wrote:
> >> On Wed, Oct 16, 2024 at 10:00:15AM +0200, Peter Eisentraut wrote:
> >> > On 15.10.24 23:51, Bruce Momjian wrote:
> >> > >
On Fri, Jul 5, 2024 at 05:11:22PM -0400, Bruce Momjian wrote:
> Wow, I see that now:
>
> test=> SELECT 'now('::timestamptz;
> timestamptz
> ---
>2024-07-05 17:04:33.457915-04
>
> If I remove t
On Wed, Oct 16, 2024 at 09:54:57AM -0400, Bruce Momjian wrote:
> On Wed, Oct 16, 2024 at 10:00:15AM +0200, Peter Eisentraut wrote:
> > On 15.10.24 23:51, Bruce Momjian wrote:
> > > On Tue, Oct 15, 2024 at 05:27:49PM -0400, Tom Lane wrote:
> > > > Bruce Momjian write
On Mon, Oct 28, 2024 at 01:07:16PM +0100, Daniel Gustafsson wrote:
> > On 17 Oct 2024, at 00:35, Bruce Momjian wrote:
> > On Tue, Jul 16, 2024 at 08:23:11AM -0400, Andrew Dunstan wrote:
>
> >> See https://postgr.es/m/4acddcd4-1c08-44e7-ba60-cab102259...@dunslane.net
>
I found that this inconsistency with input
> hints is due to PostgreSQL’s implementation and is not a bug in pg_hint_plan.
Just to clarify, the bug is not in pg_hint_plan but in the fact that the
Postgres server ignores "disable_cost of disabled operators in the
initial phase of cost estimation,&qu
kind of -0.1, just
> because I'm afraid it's going to create back-patching gotchas.
> I don't really find that it's improving readability, though
> clearly that's a matter of opinion.
I kind of liked the patch in terms of simplifying things.
--
Bruce Momjian
ike that
> > is implemented totally by history_truncate_file(), so if that's
> > busted it's surely their fault.
> >
>
> Sounds likely. What surprises me a bit, I haven't found any reports of
> particularly similar bugs ... I'd have expected other people
On Fri, Oct 25, 2024 at 01:55:57PM +0200, Daniel Gustafsson wrote:
> > On 14 Oct 2024, at 18:57, Bruce Momjian wrote:
>
> > What might be acceptable would be to add an option that would make
> > pg_upgrade more tolerant of problems in many areas, that is a lot more
> &
; relnamespace::oid::regnamespace,
> oid::regclass
> ) as vacuum_command
> from pg_class
> where relkind = 'p' \gexec
>
> Additionally, I do like the idea of ANALYZE ONLY from the -general discussion
> above (though, there might be confusion with logic of --analyze and
On Thu, Oct 24, 2024 at 08:01:11PM -0400, Greg Sabino Mullane wrote:
> On Mon, Oct 14, 2024 at 5:15 PM Bruce Momjian wrote:
>
> I am not a fan of this patch. I don't see why _removing_ the magnetic
> part helps because you then have no logic for any 1.2 was chosen.
>
uot;; fix, typo "sychronized", etc.
>
>
> /The time slot sychronized was stopped./The time when slot
> synchronization was most recently stopped./
Yes, all good suggestions, updated patch attached.
--
Bruce Momjian https://momjian.us
EDB
or slots on the
> +standby that are intended to be synced from a primary server
>
> I think it is better to be explicit here and probably say: "This is
> useful for slots on the standby that are being synced from a primary
> server ..&q
On Fri, Oct 18, 2024 at 10:00:54AM +0800, jian he wrote:
> On Fri, Oct 18, 2024 at 2:05 AM Bruce Momjian wrote:
> > Yes, updated patch attached.
> >
> looks good.
>
> in the meantime, do you think it's necessary to slightly rephrase
> jsonb_path_match doc
On Thu, Oct 17, 2024 at 02:47:57PM -0300, Marcos Pegoraro wrote:
> Em qui., 17 de out. de 2024 às 13:31, Bruce Momjian
> escreveu:
>
> Oh, okay, but I think we need to say JSON null so we are clear --- patch
>
>
> But true, false and null are all JSON, since y
would be better.
>
> since we can select 'null'::jsonb;
> but cannot
> select 'NULL'::jsonb;
Oh, okay, but I think we need to say JSON null so we are clear --- patch
attached.
--
Bruce Momjian https://momjian.us
EDB
On Thu, Oct 17, 2024 at 02:07:00PM +0800, jian he wrote:
> On Thu, Oct 17, 2024 at 7:59 AM Bruce Momjian wrote:
> >
> >
> > Where are we on this? I still see this behavior.
> >
> > ---
&
, and without the dash, it might be understood as "SQL
standard-path" vs. "SQL-standard path". There aren't clear rules on
when to add the dash, but when it can be misread, a dash is often added.
--
Bruce Momjian https://momjian.us
EDB
ize BufferShmemSize(void);
>
> /* in localbuf.c */
> extern void AtProcExit_LocalBuffers(void);
>
> /* in freelist.c */
>
> which doesn't say "prototypes for functions xxx", but it still make sense
> for me.
I looked at this and decided the GUC section was illogic
1 - 100 of 1388 matches
Mail list logo
