esults
Yeah. I mentioned earlier that I very recently saw a customer query
with UPPER() in the join condition. If someone is doing foo JOIN bar
ON upper(foo.x) = upper(bar.x), it is not unlikely that one or both of
those expressions are indexed. Not guaranteed, of course, but very
plausible.
--
l backup of a standby server can fail if there has
> been very little activity since the previous backup, since no new
> restartpoint might have been created.
--
Robert Haas
EDB: http://www.enterprisedb.com
ext column is a lot more common than one that involves UPPER.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Jul 24, 2024 at 1:45 PM Jeff Davis wrote:
> There's a qualitative difference between a collation update which can
> break your PKs and FKs, and a ctype update which definitely will not.
I don't think that's true. All you need is a unique index on UPPER(somecol).
--
Robert Ha
e even if the fire can be put out.
--
Robert Haas
EDB: http://www.enterprisedb.com
nd gives you
a way to get it fixed again. Or better yet, when you do something that
would break something as things stand today, some kind of versioning
logic kicks in and you keep the old behavior and nothing actually
breaks.
--
Robert Haas
EDB: http://www.enterprisedb.com
(2)
those changes will be so minor that nobody will have a problem, I
think we will lose our bet.
--
Robert Haas
EDB: http://www.enterprisedb.com
lace a dependency on an unstable set of
libc definitions with a dependency on an equally unstable set of
PostgreSQL definitions, we're not really winning. Do we need to
version the new ctype provider?
--
Robert Haas
EDB: http://www.enterprisedb.com
are system objects. I
agree that doesn't help with schemas, but most people don't have a
huge number of schemas, and even if you do, you don't necessarily need
to look at the list all that frequently.
--
Robert Haas
EDB: http://www.enterprisedb.com
cu, and
partly on our own internal tables.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Jul 23, 2024 at 3:11 AM Laurenz Albe wrote:
> I hear you. It would be interesting to know what other RDBMS do here.
Yeah, I agree.
--
Robert Haas
EDB: http://www.enterprisedb.com
e -- including me, I'm afraid
-- are going to use those emojis once they show up, so software that
wants to remain relevant is going to have to support them.
--
Robert Haas
EDB: http://www.enterprisedb.com
nything. See
the comment that begins with "If the last checkpoint record we've
replayed is already our last".
--
Robert Haas
EDB: http://www.enterprisedb.com
important to
understand the conventions and expectations that people have here. If
you insist on doing things differently than what everyone else does,
you're going to annoy a lot of people.
--
Robert Haas
EDB: http://www.enterprisedb.com
ff on a wild goose chase
looking for a perfect test case that may not realistically exist,
either.
--
Robert Haas
EDB: http://www.enterprisedb.com
l of work into
developing specifically for collation definition changes a few
releases ago and it was judged not good enough, but that means we just
still have nothing, which is unfortunate considering how often things
go wrong in this area.
--
Robert Haas
EDB: http://www.enterprisedb.com
commit them, but I also don't want to wait too long.
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
v3-0002-Wait-for-WAL-summarization-to-catch-up-before-cre.patch
Description: Binary data
v3-0001-Allow-WAL-summarization-to-back-up-when-timeline-.patch
Description: Binary data
backup that is lagging
behind the primary (or some other standby) using a prior backup taken
at a later WAL position may fail for the same reason.
I'm not saying that's perfect, but let me know your thoughts.
--
Robert Haas
EDB: http://www.enterprisedb.com
and reports behind it.
Wow, that's an incredible wiki page.
--
Robert Haas
EDB: http://www.enterprisedb.com
e should perhaps look harder at
doing something along these lines in core.
--
Robert Haas
EDB: http://www.enterprisedb.com
on? Or are you wanting me to do that?
--
Robert Haas
EDB: http://www.enterprisedb.com
he bug?
--
Robert Haas
EDB: http://www.enterprisedb.com
t for (checks
thread) 10 months when according to multiple reviewers, it works.
--
Robert Haas
EDB: http://www.enterprisedb.com
f
scenarios where it definitely isn't. Plus, it's not quite clear how to
distinguish the cases where it's OK from the cases where it isn't.
--
Robert Haas
EDB: http://www.enterprisedb.com
go well.)
> The log volume is the lesser of the problems. Not printing the message
> just because the system does have a problem isn't the right fix.
Yeah.
> Let's fix the default. People who have a problem can still disable it,
> but then everyone else gets the useful me
On Mon, Jul 15, 2024 at 11:27 AM Laurenz Albe wrote:
> On Sat, 2024-06-29 at 07:01 +0200, Laurenz Albe wrote:
> > I played around with incremental backup yesterday and tried $subject
> >
> > The WAL summarizer is running on the standby server, but when I try
> > to take an incremental backup, I
m recurs.
I have yet to run into a customer who was thrilled about receiving that message.
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi Pavel,
First, thanks for your dedication to this effort. I always find it
hard to make time for things like psql backslash command improvements,
but I'm glad that we have people in our community who work on such
things.
Second, I think that the threshold question for this patch is: will
wait you
often ended up using more disk space at the end than you had at the
beginning due to the index bloat. I remember being surprised by the
decision to remove it entirely, but it sure was painful to use.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Jul 10, 2024 at 5:01 PM Robert Haas wrote:
> Here is a draft patch that attempts to fix this problem. I'm not
> certain that it's completely correct, but it does seem to fix the
> reported issue.
I tried to write a test case for this and discovered that there are
actually two
reworded slightly to make the tenses work.
I just realized that I should've created a CF entry for this so that
it went through CI before actually committing it. Let's see how long
it takes for me to get punished for that oversight...
--
Robert Haas
EDB: http://www.enterprisedb.com
arizer_state(). The
previous version made no documentation changes.
--
Robert Haas
EDB: http://www.enterprisedb.com
v5-0001-Do-not-summarize-WAL-if-generated-with-wal_level-.patch
Description: Binary data
pler than trying to
implement cross-checks on the values for which we don't have proper
infrastructure.
--
Robert Haas
EDB: http://www.enterprisedb.com
fact I'm not sure we should have the
protected flag at all.
> In addition
> to that, also allow users to explicitly set $extension_schema as the
> search_path and bypass resolution of $extension_schema for objects
> outside the extension?
Yes, I'm saying that.
--
ion_name.
And even that wouldn't really work cleanly because the relation could
be renamed or moved to a different schema. Plus, adding string
construction overhead here sounds unappealing.
Maybe we'll find a clever solution someday, but I think for now you're
right that integer IDs are the way to go.
--
Robert Haas
EDB: http://www.enterprisedb.com
it feels like we're losing as much as we're
gaining, and Tom seems to have lost interest in the thread, too.
--
Robert Haas
EDB: http://www.enterprisedb.com
> is too short, so there is no reason in hiding them.
>
> But you are right, we need more opinions.
Which version of the patch is currently under discussion?
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Jul 15, 2024 at 2:33 PM Jeff Davis wrote:
> On Mon, 2024-07-15 at 13:44 -0400, Robert Haas wrote:
> > But ... why? I mean, what's the point of prohibiting that?
>
> Agreed. We ignore all kinds of stuff in search_path that doesn't make
> sense, like non-existent schemas.
you know that, during startup, the setting for
summarize_wal is processed after the setting for wal_level?
--
Robert Haas
EDB: http://www.enterprisedb.com
I can update the documentation.
> I have one small comment:
>
> +# This test aims to validate that takeing an incremental backup fails when
>
> "takeing" should be "taking"?
Will fix, thanks.
--
Robert Haas
EDB: http://www.enterprisedb.com
assaging it, I also think that's
fine. I simply don't believe it's the only way forward here. YMMV, but
my opinion is that none of these approaches have such critical flaws
that we need to get stressed about it.
--
Robert Haas
EDB: http://www.enterprisedb.com
ell which SQL is to blame."
So the point of that commit was to find better ways of distinguishing
between similar contexts. It sounds like perhaps we're not all the way
there yet, but if we agree on the goal, maybe we can figure out how to
reach it.
--
Robert Haas
EDB: http://www.enterprisedb.com
e "protected" flag is enabled.
But ... why? I mean, what's the point of prohibiting that? In fact,
maybe we should have *that* and forget about the protected flag in the
control file.
--
Robert Haas
EDB: http://www.enterprisedb.com
r at least a
clearer explanation of what's going on with $extension_schema here?
--
Robert Haas
EDB: http://www.enterprisedb.com
h[2]
> = 22 and level <= 3;
I'm doubtful about this because nothing prevents the set of memory
contexts from changing between one query and the next. We should try
to make it so that it's easy to get what you want in a single query.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, Jul 11, 2024 at 6:51 AM Fujii Masao wrote:
> So far, I haven't found any other issues with the patch.
Here is a new version that removes the hunks you highlighted and also
adds a test case.
--
Robert Haas
EDB: http://www.enterprisedb.com
v4-0001-Do-not-summarize-WAL-if-genera
that perhaps it should be exposed by
pg_get_wal_summarizer_state(), but I didn't actually implement that.
Thinking about it again, I think maybe it's fine to just remove it
from the shared memory state, as this should be a rare scenario in
practice. What is your opinion?
--
Robert Ha
ing the
> documentation.
The only problem I see with this is that it doesn't make it clear that
we're being shown parentage or ancestry, rather than values for the
current node. I suspect path is fairly understandable, but if you
don't like that, what about parent_ids?
--
Robert Haas
EDB: http://www.enterprisedb.com
ink the transient path IDs make it any more difficult.
I feel like Melih has chosen a simple and natural representation and I
would have done pretty much the same thing. And AFAICS there's no
reasonable alternative design.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Jul 3, 2024 at 1:07 PM Robert Haas wrote:
> I think the problem here is that the WAL summarizer believes that when
> a new timeline appears, it should pick up from where the old timeline
> ended. And here, that doesn't happen: the new timeline branches off
> before the en
On Wed, Jul 10, 2024 at 10:10 AM Robert Haas wrote:
> On Wed, Jul 10, 2024 at 1:56 AM Fujii Masao
> wrote:
> > I believe this issue occurs when the server is shut down cleanly.
> > The shutdown-checkpoint record retains the wal_level value used
> > before the shutdown.
ld not proceed with
that approach:
https://www.postgresql.org/message-id/CAGECzQR2r-rHFLQr5AonFehVP8DiFH+==r2yqdbvunynwxs...@mail.gmail.com
http://postgr.es/m/3253790.1720019...@sss.pgh.pa.us
--
Robert Haas
EDB: http://www.enterprisedb.com
ases where it's wrong and performance is bad.
--
Robert Haas
EDB: http://www.enterprisedb.com
Here's v2.
Jakub Wartak pointed out to me off-list that this broke the case where
a chain of incrementals crosses a timeline switch. That made me
realize that I also need to add the WAL level to XLOG_END_OF_RECOVERY,
so this version does that.
I also forgot to mention that this patch changes
hey also need
adjustment.
--
Robert Haas
EDB: http://www.enterprisedb.com
s in the
first place, we have to have some other way of finding that out, and
it's difficult to see how that can happen without postmaster
involvement.
--
Robert Haas
EDB: http://www.enterprisedb.com
for .0 or .1, not betaX.
--
Robert Haas
EDB: http://www.enterprisedb.com
v1-0001-Do-not-summarize-WAL-if-generated-with-wal_level-.patch
Description: Binary data
ge "Fix bugs in pg_wal_summary_contents()" to "Fix limit
block handling in pg_wal_summary_contents()".
--
Robert Haas
EDB: http://www.enterprisedb.com
ing the next
couple of days due to the US holiday tomorrow, but I've made a note to
look into this more next week.
--
Robert Haas
EDB: http://www.enterprisedb.com
answer is
"remove the assertion," and maybe that is all we need to do. However,
I'm not quite sure what the actual behavior will be if we just do
that, so I think more investigation is needed. I'll keep looking at
this, although given the US holiday I may not have results u
ains something
backend-specific.
--
Robert Haas
EDB: http://www.enterprisedb.com
tion for another
day) but just cutting down on the number seems like it might not be
such a bad idea.
--
Robert Haas
EDB: http://www.enterprisedb.com
have any particular technical insight on this topic, but I
just want to mention that I'm excited about the work. Numeric
performance can be painfully slow, and these seem like quite
significant speedups that will affect lots of real-world cases.
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi,
I've now sent acceptance and rejection emails to, I believe, all
applicants. If you applied and didn't get an email, let me know.
For those who may be interested in the statistics, I received 34
applications. Although I initially anticipated being unable to accept
more than 9, because we had
ght be. But that doesn't seem like a great reason, either.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Jul 2, 2024 at 2:37 PM Tom Lane wrote:
> Robert Haas writes:
> > What happens right now is:
>
> > - If you set enable_indexscan=false, then disable_cost is added to the
> > cost of index scan paths and the cost of index-only scan paths.
>
> > - If y
is:
- If you set enable_indexscan=false, then disable_cost is added to the
cost of index scan paths and the cost of index-only scan paths.
- If you set enable_indexonlyscan=false, then index-only scan paths
are not generated at all.
Bitmap scans are controlled by enable_bitmapscan.
--
Rob
> Could we cram it into the "cost=... rows=..." part? And perhaps a marker
> that a node was disabled would be more user friendly than showing the
> cumulative count? Something like:
The problem is that we'd have to derive that. What we actually know is
the disable count; to figure out whether the node itself was disabled,
we'd have to subtract the value for the underlying nodes back out.
That seems like it might be buggy or confusing.
--
Robert Haas
EDB: http://www.enterprisedb.com
u
would need or want to use system() to wait for asynchronous tasks to
complete. Wouldn't it be something like select()?
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, Jun 20, 2024 at 1:12 PM Robert Haas wrote:
> I'm working to start a mentoring program where code contributors can
> be mentored by current committers. Applications are now open:
> https://forms.gle/dgjmdxtHYXCSg6aB7
Applications are now closed. Initially, I had imagined jus
Hi,
I think you need to find a way to disable this "Attachment protected
by Amazon" thing:
http://postgr.es/m/01000190606e3d2a-116ead16-84d2-4449-8d18-5053da66b1f4-000...@email.amazonses.com
We want patches to be in the pgsql-hackers archives, not temporarily
accessible via some link.
that bumps the version number (update major
version in src/tools/version_stamp.pl, then run it, then run autoconf,
then commit). Then I build my patch set on top of that. Once the
actual major release bump happens, I just drop that commit from the
stack.
--
Robert Haas
EDB: http://www.enterprisedb.com
lways - going to be
cheaper than the untransformed version.
> On 24.06.2024 18:28, Robert Haas wrote:
> Andrei mentioned the problem, which might be caused by the transformation on
> the later stage of optimization is updating references to expressions in
> RestrictInfo [3] lists,
concerned about code
that still uses MD5, for example, or SHA-1, but this is the first time
I can remember someone expressing a concern about a KDF.
Anbazhagan, or anyone, is there some reason to think that the PBKDF2
approach used by SCRAM is a problem?
--
Robert Haas
EDB: http://www.enterprisedb.
obably isn't the only page of our docs that might require ctrl+f.
> But I'll yield to the majority opinion here.
I'm not objecting. I'm just asking.
--
Robert Haas
EDB: http://www.enterprisedb.com
popular testing infrastructure.
--
Robert Haas
EDB: http://www.enterprisedb.com
were just
pointers to global variables.
Well, I don't know. I guess that doesn't leave any real options but to
fix it as Melanie proposed. But I still don't like it very much. I
feel like having to test against two different thresholds in the
pruning code is surely a sign that we're doing something wrong
running on
> the CPU.
>
> I'll see if I can do some more testing of this, and see if there's a
> value where it stops improving / starts degrading, etc.
Sounds good.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Jun 25, 2024 at 3:51 PM Tom Lane wrote:
> This comment seems to be truncated:
Thanks. New version attached.
--
Robert Haas
EDB: http://www.enterprisedb.com
v2-0001-Prevent-summarizer-hang-when-summarize_wal-turned.patch
Description: Binary data
I don't have a problem with doing it the way you have here if you
think that's good. I'm just asking.
--
Robert Haas
EDB: http://www.enterprisedb.com
nwhile, it might not be
correct. Here's a patch to fix that.
--
Robert Haas
EDB: http://www.enterprisedb.com
v1-0001-Prevent-summarizer-hang-when-summarize_wal-turn-o.patch
Description: Binary data
egress such scenarios in the back-branches.
Is there any way that we could instead tweak things so that we adjust
the visibility test object itself? Like can have a GlobalVisTest API
where we can supply the OldestXmin from the VacuumCutoffs and have it
... do something useful with that?
--
Robert Ha
On Tue, Jun 25, 2024 at 11:39 AM Melanie Plageman
wrote:
> On Tue, Jun 25, 2024 at 10:31 AM Robert Haas wrote:
> > On Tue, Jun 25, 2024 at 9:07 AM Andres Freund wrote:
> > > It's not hard - but it has downsides. It'll mean that - outside of vacuum
> > > -
> >
ceive grants of access privileges. Consequently, once
pg_database_owner has rights within a template database, each owner of
a database instantiated from that template will exercise those rights.
Initially, this role owns the public schema, so each database owner
governs local use of the s
parate thread. It's not going to
be meaningfully harder to move in that direction after some patch like
this than it is today.
--
Robert Haas
EDB: http://www.enterprisedb.com
t
> slots, will prevent fewer conflicts.
Can you explain this in more detail?
--
Robert Haas
EDB: http://www.enterprisedb.com
an error flag rather than an error message, I end up
regretting it. It's possible that this case is, for some reason, an
exception to that principle, but I feel like we need to nail down
exactly what the protocol flow *and* the libpq API for these new
messages is going to be before I can really have an intelligent
opinion about that.
--
Robert Haas
EDB: http://www.enterprisedb.com
em are
off-hand, and I bet nobody else could either, at least until recently,
else we might not have this bug. I feel like if it were possible to
have fewer of them and still have things work, we'd be better off. I'm
not sure that's doable. But six seems like a lot.
--
Robert Haas
EDB: http://www.enterprisedb.com
alculation now and then, but maybe it doesn't actually do that?
Suppose process A begins a transaction, acquires an XID, and then goes
idle. Process B now begins a giant vacuum. At some point in the middle
of the vacuum, A ends the transaction. Are you saying that B's
GlobalVisTest never really n
t use, including:
>
> BINDIR
> DOCDIR
> HTMLDIR
> PKGINCLUDEDIR
> LOCALEDIR
> MANDIR
>
> I can imagine an extension wanting or needing to use any and all of these.
Are these really all relevant to backend code?
--
Robert Haas
EDB: http://www.enterprisedb.com
ch a sign, I would frankly be a little
concerned.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, Jun 21, 2024 at 11:40 AM Nathan Bossart
wrote:
> Done.
If you look at how the varlistentries begin, there are three separate patterns:
* Some document a single role and start with "Allow doing blah blah blah".
* Some document a couple of rolls so there are several paragraphs,
each
rify it. My feeling is that the patch
doesn't meet that standard today, but I think that just means it needs
some more work. I'm not arguing we have to throw the whole thing out,
or invent a lot of new infrastructure, or anything like that.
--
Robert Haas
EDB: http://www.enterprisedb.com
an
analogue of that for control files.
--
Robert Haas
EDB: http://www.enterprisedb.com
ns to the target type, e.g.
column1 op1 ANY[const1,converted_const2]
I don't think the default opclass matters here, or the index properties either.
--
Robert Haas
EDB: http://www.enterprisedb.com
forward during
vacuum is desirable. I'm just wondering if having the vacuum code need
to know a second horizon is really the best way to address that.
--
Robert Haas
EDB: http://www.enterprisedb.com
ce here -- I think it's great that
you've done the work to pin this down and perhaps there is no better
fix than what you've proposed.)
--
Robert Haas
EDB: http://www.enterprisedb.com
s better
to keep it simple and only do things that we know are simple and safe,
like assembling a bunch of datums that we already have into an array.
--
Robert Haas
EDB: http://www.enterprisedb.com
rmance is going to
degrade, so you can imagine wanting to try to have enough lock groups
to make that unlikely. Which leads me to wonder if there's any
particular number of lock groups that is clearly "too many" or whether
it's just about how much memory we want to use.
--
Robert Haas
EDB: http://www.enterprisedb.com
JumbleState *JumbleExpr(Expr *expr, uint64 *exprId);
This is no longer needed.
--
Robert Haas
EDB: http://www.enterprisedb.com
1 - 100 of 7159 matches
Mail list logo
