ember for PG 17 since it
doesn't compile anymore, so someone has to go over the reverted patch,
figure out which ones are still valid, and report back. Trying to add a
port, with possible breakage, during beta seems too risky compared to
the value.
--
Bruce Momjian htt
On Thu, Apr 25, 2024 at 10:16:34AM +0200, Álvaro Herrera wrote:
> On 2024-Apr-24, Bruce Momjian wrote:
>
> > I agree that targeting PG 18 for a new-er AIX port is the reasonable
> > approach. If there is huge demand, someone can create an AIX fork for
> > PG 17 us
ee that targeting PG 18 for a new-er AIX port is the reasonable
approach. If there is huge demand, someone can create an AIX fork for
PG 17 using the reverted patches --- yeah, lots of pain there, but we
have carried the AIX pain for too long with too little support.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
statistics can be copied from a donor
> replica if needed, and btree indexes only really really need to
> contain their highest and lowest values (and need their height set
> correctly).
Is it possible to prevent stats from being updated by autovacuum and
other methods?
--
Bruce Mo
at's in the docs. The description string has to be a short
> one-liner in just about every case.)
>
> This sounds to me like it would be a painful exercise with not a
> lot of benefit in the end.
Maybe we could _verify_ the contents of func.sgml against pg_pro
On Thu, Apr 4, 2024 at 04:51:50PM -0400, Bruce Momjian wrote:
> On Thu, Apr 4, 2024 at 04:38:10PM -0400, Greg Sabino Mullane wrote:
> > On Thu, Apr 4, 2024 at 2:23 PM Bruce Momjian wrote:
> > +Such upgrades might require manual changes to complete so always read
> >
On Fri, Apr 12, 2024 at 04:55:16PM -0400, Bruce Momjian wrote:
> On Thu, Apr 11, 2024 at 03:37:00PM +0200, Daniel Gustafsson wrote:
> > On 11 Apr 2024, at 15:29, David Rowley wrote:
> >
> > On Fri, 12 Apr 2024, 1:05 am Daniel Gustafsson, wrote:
> >
> &
I opted for "if" due to recent threads where the use of
> "iff" was discouraged due to not being commonly known, but that was in doc/
> and
> not code comments.
I actually agree "iff" is just not clear enough. "Iff" stands for "if
an
now we are requiring
Andres to stop what he is doing to give immediate feedback --- that is
not fair to him.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
ed to
write the paper with the ideas I had, and if I come up with a better
idea later, I can add it to the end.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
r to lose context of the patch and thus interest in
> the patch. And then finally getting into the exact same situation next
> year in the final commit fest, when some other committer didn't agree
> with the redesign of the first one and request a new one pushing it
> another yea
o communicate with us securely. I
suppose some special word could be used to communicate that status ---
that is how it was done in non-electronic communication in the past.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Onl
mand where we define the behavior only alone at the
beginning of a line, and not in other circumstances. The \a example
above suggests \. should be period in all other cases, as suggested, but
I don't know the ramifications if that.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
es. I haven't looked into what
> sort of savings that could yield (if any) but if we go the route of
> regeneration at test-time we shouldn't leave potential savings on the table.
Rather then everyone testing it on every build, couldn't we have an
automated test every night that checked binary f
On Thu, Apr 4, 2024 at 04:38:10PM -0400, Greg Sabino Mullane wrote:
> On Thu, Apr 4, 2024 at 2:23 PM Bruce Momjian wrote:
> +Such upgrades might require manual changes to complete so always read
> +the release notes first.
>
> Proposal:
> "Such upgrades might r
ual steps) from the user's perspective.
Yes, you are correct. It used to be under "modules" and we didn't
update this text, partly because this it not in our source git tree;
updated patch attached.
--
Bruce Momjian https://momjian.us
EDB
gt; otherwise. I think that has more to do with this being just the wrong
> structure to get our point across. Can we pick out some statistics from our
> long history of publishing minor releases to present an objective reality to
> the reader to convince them to trust our track-record
On Wed, Apr 3, 2024 at 09:25:02AM -0400, Bruce Momjian wrote:
> On Wed, Apr 3, 2024 at 04:17:21PM +0300, Panda Developpeur wrote:
> > Dear PostgreSQL Hackers,
> >
> > I am submitting a patch to modify pg_ctl to detect the presence of a geek
> > user
> > on
ents based on the community's suggestions.
>
> Thank you for considering my contribution.
Aside from an extra newline in the patch, I think this is ready to go!
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
bit) that we
> really consider all the older ones to be, well, obsolete. The difference
> "current vs obsolete" is stronger than "latest vs not quite latest".
Okay, I changed "superseded" to "old", and changed "latest" to
"current", pa
out major releases, and then minor releases. This gives a more
natural flow.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
diff --git a/templates/support/versioning.html b/templates
On Mon, Apr 1, 2024 at 03:17:55PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I was more asking if users have access to patches so they could recreate
> > the build by using the Postgres git tree and supplied OS-specific
> > patches.
>
> AFAIK, every o
On Fri, Mar 29, 2024 at 06:37:24PM -0400, Bruce Momjian wrote:
> You might have seen reports today about a very complex exploit added to
> recent versions of liblzma. Fortunately, it was only enabled two months
> ago and has not been pushed to most stable operating systems li
he behavior, nor adding fundamentally new
> monitoring capabilities.
I think pg_upgrade could check for the existence of extended statistics
in any database and adjust the analyze recommdnation wording
accordingly.
--
Bruce Momjian https://momjian.us
EDB
.
I was more asking if users have access to patches so they could recreate
the build by using the Postgres git tree and supplied OS-specific
patches.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
Reality check --- are we still targeting this feature for PG 17?
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
the patches in its source tarball.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
inize it? Imagine hiding something bad in the middle of
> that file somewhere.
So, in this case, the hooks were in 'configure', but not configure.ac,
and the exploit was in a test file which was in the tarball but _not_ in
the git tree. So, they used the obfuscation of 'configure's syntax
e known
individuals, but this might have cautionary lessons for us.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
On Fri, Mar 29, 2024 at 08:46:33AM -0400, Robert Haas wrote:
> On Thu, Mar 28, 2024 at 3:33 PM Bruce Momjian wrote:
> > I am fine with moving ahead. I thought my later emails explaining we
> > have to be careful communicated that.
>
> OK. Thanks for clarifying. I'v
it updates the
"discarding" -> "overwriting" ?
> +
> + ALTER SYSTEM can be disabled by setting
> +to off, but
> this
> + is no security mechanism (as explained in detail in the documentation for
"is no" -> "is not a"
--
Br
els a little ... over-edited. But if you're happy with the latest
> version, we can go with that. Or, do you need more time to review?
I am fine with moving ahead. I thought my later emails explaining we
have to be careful communicated that.
--
Bruce Momjian https://m
valid concern. I do agree with your analysis of other patches in the
commitfest, but I just don't see them stretching our boundaries like
this patch.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
arameter to off can
> +help to avoid such mistakes.
"help to avoid" -> "help avoid"
> +
> +
> +
> + This parameter only controls the use of ALTER
> SYSTEM.
> +The settings stored in postgresql.auto.conf
> always
&q
On Thu, Mar 28, 2024 at 12:47:46AM +0100, Jelte Fennema-Nio wrote:
> On Wed, 27 Mar 2024 at 23:06, Bruce Momjian wrote:
> > > > > > +some outside mechanism. In such environments, using
> > > > > > ALTER
> > > > > > +SYSTE
ROM generate_series(1,10) AS i;
>
> WITH edge AS (
> SELECT start_node, end_node
> FROM edge_data
> WHERE edge_id = 1
> )
> SELECT start_node id FROM edge UNION
> SELECT end_node FROM edge;
I can confirm the crash in git master.
--
Bruce Momjian
On Wed, Mar 27, 2024 at 03:20:38PM -0700, David G. Johnston wrote:
> On Wed, Mar 27, 2024 at 3:18 PM David G. Johnston
> wrote:
>
> On Wed, Mar 27, 2024 at 3:13 PM Bruce Momjian wrote:
>
> On Wed, Mar 27, 2024 at 06:09:02PM -0400, Bruce Momjian wrote:
>
et's just be careful since we have a bad
history of pushing things near the end that we regret. I am not saying
that would be this feature, but let's be careful.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
On Wed, Mar 27, 2024 at 06:09:02PM -0400, Bruce Momjian wrote:
> On Wed, Mar 27, 2024 at 11:05:55AM -0400, Robert Haas wrote:
> > On Wed, Mar 27, 2024 at 10:43 AM Jelte Fennema-Nio
> > wrote:
> > > Alright, changed the GUC name to "allow_alter_system" since
>
> I agree, and have committed your 0001.
So, I email "Is this really a patch we think we can push into PG 17. I
am having my doubts," and the patch is applied a few hours after my
email. Wow.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
> > that outside
> > >
> > > "might"
> >
> > This does not seem like a mistake to me. I'm not sure why you think it is.
>
> I also think the original sentence was correct, but I don't think it
> read very naturally. Cha
> +mechanism updates the configuration. Setting this parameter to
> +on can help to avoid such mistakes.
> +
"off"
Is this really a patch we think we can push into PG 17. I am having my
doubts.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
On Tue, Mar 26, 2024 at 10:23:51AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Mar 25, 2024 at 5:04 PM Bruce Momjian wrote:
> >> To me, externally_managed_configuration is promising a lot more than it
> >> delivers because there is still a lot
On Mon, Mar 25, 2024 at 09:40:55PM +0100, Jelte Fennema-Nio wrote:
> On Mon, 25 Mar 2024 at 20:16, Bruce Momjian wrote:
> > I am wondering if the fact that you would be able to do:
> >
> > ALTER SYSTEM SET externally_managed_configuration = false
> >
> >
remember is that some people modified the ZFS file
system parameters enough that they made Postgres non-durable and
corrupted their database. This is a very hard thing to get right
because the user has very little feedback when they break things.
--
Bruce Momjian https://momjian.
uot;configuration" too generic a term for disabling ALTER SYSTEM?
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
imaging by turning off the full_page_writes parameter.
--> Battery-Backed Unit (BBU) disk controllers do not prevent partial page
--> writes unless they guarantee that data is written to the BBU as full
--> (8kB) pages.
--
Bruce Momjian https://momjian.us
EDB
On Fri, Mar 22, 2024 at 03:13:29PM -0400, Robert Haas wrote:
> On Fri, Mar 22, 2024 at 2:59 PM Bruce Momjian wrote:
> > I assume statistics collector views are in "Monitoring Database
> > Activity" because that is their purpose.
>
> Well, yes. :-)
>
> But t
nt, but maybe there was some other
> logic to it.
I assume statistics collector views are in "Monitoring Database
Activity" because that is their purpose.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
years we
thought we didn't need fsync since the BSD file system was 8k at the
time.
What we later realized is that we have no guarantee that the file system
will write to the device in the specified block size, and even it it
does, the I/O layers between the OS and the device might not, since many
d
ntil this commit in 2022, the system views were _under_ the
system catalogs chapter:
commit 64d364bb39c
Author: Bruce Momjian
Date: Thu Jul 14 16:07:12 2022 -0400
doc: move system views section to its own chapter
Previously it wa
hat way because it's the default setting of the
> > stylesheets.
>
> That's quite possible. I don't have strong opinions on whether we should
> change, or keep it the way it is.
If we can't justify why it should be different, it should be like the
surrounding sections.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
ch. The patch that Mr. Momjian reviewed
> is this.
> If user-facing documentation is needed for this POC patch, it can be added.
>
> I apologize for the lack of explanation regarding this positioning, which may
> have caused misunderstandings regarding the patch posted in [3
nk this kind of doc structure review is long overdue.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
h contains zero
> user-facing documentation, even though it's created new SQL syntax,
> not to mention a new postgres_fdw option. I assume this means that
> nobody thinks it's anywhere near ready to commit.
Previous versions of the patch had docs since I know I worked on
improving them. I am
n < PG_VERSION_NUM)
partial_agg_ok = false;
}
It uses check_partial_aggregate_support, which defaults to false,
meaning partial aggregates will be pushed down with no version check by
default. If set to true, pushdown will happen if the remote server is
the same version or newer, which seems acceptable to me.
FYI, the patch is much smaller now. :-)
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
cept you said it better than I would have done.
I do think the docs need to clearly say this is not a security feature.
In fact, I wonder if the ALTER SYSTEM error message should explain the
GUC that is causing the failure.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
On Thu, Mar 14, 2024 at 10:46:28PM -0400, Bruce Momjian wrote:
> > In the end, while I certainly don't mind improving the web page, I
> > think that a lot of what we're seeing here probably has to do with the
> > growing popularity and success of PostgreSQL. If you have more peo
ularity and success of PostgreSQL. If you have more people
> using your software, you're also going to have more people using
> out-of-date versions of your software.
Yeah, probably, and we recently end-of-life'ed PG 11.
--
Bruce Momjian https://momjian.us
EDB
enance updates.
>
I think "minor" is a better term since it contrasts with "major". We
don't actually supply patches to upgrade minor versions.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:
> On Mon, Mar 11, 2024 at 04:37:49PM -0400, Bruce Momjian wrote:
> > https://www.postgresql.org/support/versioning/
> >
> > This web page should correct the idea that "upgrades are more risky than
we can do? Should we
have a more consistent response for such reporters?
It would be a crazy idea to report something in the logs if a major
version is run after a certain date, since we know the date when major
versions will become unsupported.
--
Bruce Momjian https://momjia
; > clients that don't support longer keys.
>
> My intuition would be to make this a protocol version bump, not an optional
> feature. I think this is something that everyone should eventually be
> using, not a niche feature that you explicitly want to opt-in for.
Agree
to make Outlook do the leading ">" in a reply
> for the previous message?
Here is a blog post about how complex email posting can be:
https://momjian.us/main/blogs/pgblog/2023.html#September_8_2023
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
_minimal_ approach has changed in the past few years to make
pg_upgrade debugging easier. The original design was ultra-conservative
where it could be, considering how radical the core functionality was.
--
Bruce Momjian https://momjian.us
EDB https
this idea.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
ments are thrown away. They do not appear in the existing
> Doxygen output.
I have found it very strange that a tool like doxygen which can create
all sorts of call graphs, just ignores some comments. The comments
above function are very important.
--
Bruce Momjian https:/
by somebody hammering on the side of the argument that they believe to
> be correct and ignoring the other one.
What if we generate log messages when certain commands are used, like
ALTER TABLE? We could have GUC which controls which commands are
logged.
--
Bruce Momjian https://m
tion, preventing higher priority processes from
> progressing.
>
> I doubt you can implement this in a robust manner outside of postgres.
FYI, here is an article about priority inversion:
https://www.geeksforgeeks.org/priority-inversion-what-the-heck/
--
Bruce Momjian
stream. Packagers
> are probably more likely to package the tools if they are marked for
> installation by upstream too.
>
> Hope this helps to better explain what changes would be required within the
> Postgres source tree.
Yes, it does, thanks.
--
Bruce Momjian https://
ot need a hack to get the
> pg_bsd_indent executable.
So your point is that pg_bsd_indent and pgindent are in the source tree,
but not in any package distribution? Isn't that a packager decision?
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.co
pdates of the back
> branches?
>
> And of course, Happy New Year to all!
Done, sorry for the delay.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
On Wed, Dec 27, 2023 at 10:52:15PM +0100, Peter Eisentraut wrote:
> On 27.12.23 02:04, Bruce Momjian wrote:
> > I did_not_ change the user API, so CREATE/ALTER ROLE still uses
> > [ENCRYPTED] PASSWORD, the GUC is still called password_encryption, and
> > the libpq fun
de, etc. Try decoding the addresses with addr2line, or even better get
> a proper backtrace - either from a core file, or using gdb.
Also, Postgres 9.6 went out of support on November 11, 2021:
https://www.postgresql.org/support/versioning/
--
Bruce Momjian https://m
fix this issue but none of them
> worked. Therefore, can you please help me solve it?
For pgAdmin support, see:
https://www.pgadmin.org/support/list/
https://github.com/pgadmin-org/pgadmin4/issues
or email
pgadmin-supp...@postgresql.org
--
Bruce Momjian
would always be tailored to
> the importer's needs.
I think the question is whether we will have the export functionality in
the old cluster, or if it will be queries run by pg_dump and therefore
also run by pg_upgrade calling pg_dump.
--
Bruce Momjian https://momjian.us
EDB
this capability to pg_upgrade/pg_dump in
a minor version upgrade if it wasn't enabled by default, and if we were
very careful.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
On Wed, Dec 27, 2023 at 01:08:47PM +0100, Tomas Vondra wrote:
> On 12/26/23 20:19, Tom Lane wrote:
> > Bruce Momjian writes:
> >> I think we need a robust API to handle two cases:
> >
> >> * changes in how we store statistics
> >> * changes i
e GUC is still called password_encryption, and
the libpq function is still called PQencryptPasswordConn(). This makes
the user interface confusing since the API uses "encryption" but the
text calls it "hashing". Is there support for renaming the API to use
"hash"
_basebackup (which would need access to both keys) or is
> this handled already and I just missed it?
Yes, decrypt and re-encrypt in pg_basebackup would be necessary, or in
the actual protocol stream.
--
Bruce Momjian https://momjian.us
EDB https://
o make any
adjustments to it before loading it into pg_statistic. Doing that
internally in JSON just isn't efficient. If people want JSON for such
cases, I suggest we add a JSON format to COPY.
I think we can then look at pg_upgrade to see if we can simulate the
export action which can use the statisti
On Fri, Nov 24, 2023 at 10:19:29AM -0500, Bruce Momjian wrote:
> On Fri, Nov 24, 2023 at 04:06:22AM +0100, Laurenz Albe wrote:
> > On Thu, 2023-11-23 at 11:12 -0500, Bruce Momjian wrote:
> > > On Wed, Nov 22, 2023 at 10:25:14PM -0500, Bruce Momjian wrote:
> > > &g
On Fri, Nov 24, 2023 at 06:20:28PM +0100, Magnus Hagander wrote:
> On Fri, Nov 24, 2023 at 5:34 PM Bruce Momjian wrote:
> >
> > On Fri, Nov 24, 2023 at 01:10:01PM +0100, Michael Banck wrote:
> > > Hi,
> > >
> > > On Fri, Nov 24, 2023 at 12:17:56PM +0100,
tially lead to more version mismatch issues.
Finally, I am now concerned that this will not be able to be in PG 17,
which I was hoping for.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
icant enough
to list there because there are many other clauses we could potentially
add there.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
On Wed, Nov 22, 2023 at 08:23:42PM -0500, Bruce Momjian wrote:
> Let me also add that I apologize for brining up these old threads. I
> feel badly I didn't address them years ago, I feel bad for the original
> posters, and I do think there is some value in addressing some of them,
> w
ckDone() and XLogArchiveIsBusy() use the new
> XLogArchiveIsReady().
> Regards,
Old patch, but still valid, so applied to master, thanks.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
d I attached patch.(it just change 60 * 60 to SECS_PER_HOUR)
>
> What do you think?
Yes, this patch is nine years old, but macros are better, as you
suggested, so patch applied to master.
--
Bruce Momjian https://momjian.us
EDB https://enterp
errdetail("Flags %04X, expected %04X",
opaq->flags,
(GIN_DATA | GIN_LEAF | GIN_COMPRESSED;
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
On Mon, Nov 13, 2023 at 02:12:12PM -0500, Bruce Momjian wrote:
> On Mon, Nov 13, 2023 at 09:49:53AM -0800, Andres Freund wrote:
> > Hi,
> >
> > On 2023-11-13 12:14:57 -0500, Bruce Momjian wrote:
> > > +SELECT *
> > > +FROM (values ('0/16ff'), (
On Thu, Nov 9, 2023 at 06:40:55PM -0500, Bruce Momjian wrote:
> On Sun, Oct 21, 2018 at 04:24:16PM -0400, Tom Lane wrote:
> > Oleg Bartunov writes:
> > > The commit 9b5c8d45f62bd3d243a40cc84deb93893f2f5122 is now 10+ years
> > > old, may be we could rem
On Fri, Nov 17, 2023 at 04:36:44PM -0500, Bruce Momjian wrote:
> On Fri, Nov 17, 2023 at 01:20:46PM -0800, Andres Freund wrote:
> > On 2023-11-17 15:39:14 -0300, Euler Taveira wrote:
> >
> > I think the connection between freezing and removal of commit timestamps is
>
On Fri, Nov 17, 2023 at 01:39:46PM -0500, Bruce Momjian wrote:
> On Mon, Nov 13, 2023 at 05:32:24PM -0800, Andres Freund wrote:
> > Hi,
> >
> > On 2023-11-13 17:00:43 -0800, Peter Geoghegan wrote:
> > > On Mon, Nov 13, 2023 at 4:43 PM Bruce Momjian wrote:
> >
On Fri, Nov 24, 2023 at 06:20:28PM +0100, Magnus Hagander wrote:
> On Fri, Nov 24, 2023 at 5:34 PM Bruce Momjian wrote:
> > On Fri, Nov 24, 2023 at 01:10:01PM +0100, Michael Banck wrote:
> > > You're right, I somehow only saw your mail after I had already sent
> > > m
On Fri, Nov 24, 2023 at 01:10:01PM +0100, Michael Banck wrote:
> Hi,
>
> On Fri, Nov 24, 2023 at 12:17:56PM +0100, Magnus Hagander wrote:
> > On Fri, Nov 24, 2023 at 11:21 AM Michael Banck wrote:
> > > On Wed, Nov 22, 2023 at 11:23:34PM -0500, Bruce Momjian wrote:
>
On Fri, Nov 24, 2023 at 04:06:22AM +0100, Laurenz Albe wrote:
> On Thu, 2023-11-23 at 11:12 -0500, Bruce Momjian wrote:
> > On Wed, Nov 22, 2023 at 10:25:14PM -0500, Bruce Momjian wrote:
> > > Yes, you are correct. Here is a patch that implements the FATAL test,
> > >
On Wed, Nov 22, 2023 at 10:25:14PM -0500, Bruce Momjian wrote:
> On Wed, Nov 22, 2023 at 07:38:52PM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Wed, Sep 28, 2016 at 09:14:41AM -0400, Tom Lane wrote:
> > >> I could go along with just dropping the last se
t;
> - /* lock page' buffer and read tuple */
> + /* lock page buffer and read tuple */
> seq = read_seq_tuple(elm, seqrel, , );
>
> if ((next < seq->min_value) || (next > seq->max_value))
>
> --
> Sent via pgsql-hackers mailing lis
have docs on updating planner statistics:
https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-STATISTICS
but that doesn't seem to cover cases where you are doing an upgrade or
pg_dump restore. Should I move this information into there instea
On Wed, Nov 22, 2023 at 07:38:52PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Sep 28, 2016 at 09:14:41AM -0400, Tom Lane wrote:
> >> I could go along with just dropping the last sentence ("This probably...")
> >> if the last error
1 - 100 of 2493 matches
Mail list logo
