aling bugs.
I'm not sure exactly what the rule should be here, but in general I
agree that a broader prohibition might be better. It's hard to
understand the rationale behind a system that doesn't allow
robert.max-workers as a GUC name, but does permit ro
b"ert.max^Hworke
RECOVERY_PAUSE_REQUESTED)
...I would suggest instead testing for != RECOVERY_NOT_PAUSED. Perhaps
we don't think RECOVERY_PAUSED can happen here. But if somehow it did,
calling recoveryPausesHere() would be right.
There might be some more to say here, but those are things I notice on
a first read-through.
--
Robert Haas
EDB: http://www.enterprisedb.com
atible with releases that most developers can't
actually build.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Dec 1, 2021 at 10:58 PM Andy Fan wrote:
> Thanks! I clearly understand what's wrong in my previous knowledge.
Cool, glad it helped.
--
Robert Haas
EDB: http://www.enterprisedb.com
h, that does mean more committer effort,
> but only for a very small number of patches.
I agree. I think that's exactly what we want to have happen, and if a
given policy won't have exactly this result then the policy needs
adjusting.
--
Robert Haas
EDB: http://www.enterprisedb.com
7;s some cost to that. For example, if some program
wants to sanitize the environment of all PG-related environment
variables, it has more to do. It seems reasonable to me to have
environment variables only for the most important connection
parameters, rather than all of them. I would
l sequential I/O and the data
pages don't need to be fsync'd, so perhaps the overhead is relatively
mild. I don't know.
--
Robert Haas
EDB: http://www.enterprisedb.com
And
Shruthi didn't write this comment anyway, it's only moved slightly
from where it was before.
> 7.
> There are some spelling mistakes in the comments as below, please
> correct the same
> + /*
> + * Make sure that binary upgrade propogate the database OID to the
> new => correct spelling
> + * cluster
> + */
>
> +/* OID 4 is reserved for Templete0 database */
> > Correct spelling
> +#define Template0ObjectId 4
Yes, those would be good to fix.
--
Robert Haas
EDB: http://www.enterprisedb.com
or this.
Why? If the client knows the CEK, can't the client choose to send
unprepared insert or update statements with pre-encrypted blobs? That
might be a bad idea from a security perspective because the encrypted
blob might then got logged, but we sometimes log parameters, too.
--
Robert Haas
EDB: http://www.enterprisedb.com
all-visible when it wasn't
before, it's certainly a good guess that the portions that still
aren't have about the same distribution of dead tuples that they did
before ... although the other direction is less clear: it seems
possible that newly not-all-visible pages have fewer dead tu
or all purposes, not
just the ones we as implementers find convenient. I understand that we
have to do *something* here and that the present behavior is buggy and
unacceptable ... but I'm not sure I accept that the only possible fix
is the one you propose here.
--
Robert Haas
EDB: http://www.enterprisedb.com
lly having the amount of backward-compatibility that we say we
want to have.
--
Robert Haas
EDB: http://www.enterprisedb.com
cale_factor is hogwash. Everything I've seen
indicates that, while you do want to wait for a larger number of dead
tuples in a large table than in a small one, it's sublinear. I don't
know whether it's proportional to sqrt(table_size) or table_size^(1/3)
or lg(table_size) or ta
On Mon, Dec 6, 2021 at 9:42 PM Peter Geoghegan wrote:
> On Mon, Dec 6, 2021 at 6:11 PM Robert Haas wrote:
> > This doesn't seem convincing. Launching autovacuum too soon surely has
> > costs that someone might not want to pay. Clearly in the degenerate
> > case where
accept
>
> regression=# select '(1,2)'::point::"char";
> char
> --
> (
> (1 row)
What's wrong with that?
--
Robert Haas
EDB: http://www.enterprisedb.com
ot a value of type t despite the user's best attempt to
decree otherwise. I know PostgreSQL sometimes ... does things like
that. I have no idea why anyone would consider it a desirable
behavior, though.
--
Robert Haas
EDB: http://www.enterprisedb.com
ied in a later,
back-patched commit. I would consider it reasonable to back-patch that
particular bug fix into an unsupported branch to make it testable,
just like we would do for a failure-to-build issue.
--
Robert Haas
EDB: http://www.enterprisedb.com
m I have here is that, with your proposed
fix, it still won't be very consistent. True, row_to_json() and f()
will both see the unaliased column names ... but a straight select *
from t as t(x,y) will show the aliased names. That's unarguably better
than corrupting your data, but it seems "astonishing" in the POLA
sense.
--
Robert Haas
EDB: http://www.enterprisedb.com
> regression=# table t;
> f1
> ----
> (
> (1 row)
>
> I definitely don't think that should have worked without
> any complaint.
Yes, that one's a bridge too far, even for me.
--
Robert Haas
EDB: http://www.enterprisedb.com
heoretical pathological behaviors here (not just
> the ones we know about today).
Sure, but we don't *need* to be less accurate, and I don't think we
even *benefit* from being less accurate. If we do something like count
dead HOT chains instead of dead tuples, let's not call that a
less-accurate count of dead tuples. Let's call it an accurate count of
dead HOT chains.
--
Robert Haas
EDB: http://www.enterprisedb.com
of-not-all-visible-pages > some-threshold, or
alternatively when %-of-index-tuples-thought-to-be-dead >
some-other-threshold.
--
Robert Haas
EDB: http://www.enterprisedb.com
n XLogInsert(), while Insert->fullPageWrites gets updated
> before CleanupAfterArchiveRecovery(). And it may influence
> the value of doPageWrites in the startup process.
But ... so what? All the code that uses it retries if the value that
was tentatively used turns out to be wrong.
--
un-as user. My guess is that most users would prefer the
former behavior to the latter.
--
Robert Haas
EDB: http://www.enterprisedb.com
changes. If I'm right
about that, it seems like a good reason for doing 1+2B first and
leaving 2A for a separate patch.
--
Robert Haas
EDB: http://www.enterprisedb.com
ime understanding why anyone
would consider that an improvement.
--
Robert Haas
EDB: http://www.enterprisedb.com
were
using threads rather than processes, but that day still seems fairly
far off.
But against all that, if these tasks are slowing down checkpoints and
that's avoidable, that seems pretty important too. Interestingly, I
can't say that I've ever seen any of these things be a problem for
c
out trying to prevent people from putting their
system into a state where it won't start.
(To be clear, I also think updating the documentation is sensible,
without taking a view on exactly what that update should look like.)
--
Robert Haas
EDB: http://www.enterprisedb.com
ecause of a couple
of minor preexisting bugs and/or preexisting maybe-bugs.
--
Robert Haas
EDB: http://www.enterprisedb.com
ls anyway, and probably won't have many failures even if
they are. SSI is really for sophisticated applications, and I think
trying to make it "just work" for people with dumb applications will,
well, just not work.
--
Robert Haas
EDB: http://www.enterprisedb.com
gresql.org/message-id/CALj2ACU9cK4pCzcqvey71F57PTPsdxtUGmfUnQ7-GR4pTUgmeA%40mail.gmail.com
Committed.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Dec 7, 2021 at 5:55 PM Robert Haas wrote:
> On Sat, Dec 4, 2021 at 7:44 PM Michael Paquier wrote:
> > My main worry here is that this changes slightly the definition of
> > doPageWrites across stable branches at the end of recovery as there
> > could be records g
hope they
define new stuff instead of encouraging implementations to redefine
what's there already.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Dec 13, 2021 at 10:46 AM Tom Lane wrote:
> Robert Haas writes:
> > I really am glad they haven't. I think it's super-annoying that we
> > need hacks like UINT64_FORMAT all over the place. I think it was a
> > mistake not to nail down the size that each ty
L, because
the first failure 2 days ago shows only this as a recent PostgreSQL
change:
07eee5a0dc Sat Dec 11 19:10:51 2021 UTC Create a new type category
for "internal use" types.
And that doesn't seem like it could cause this.
Any thoughts?
--
Robert Haas
EDB: http://www.enterprisedb.com
nd macOS Monterey (Apple clang 13.0.0).
I think this is great. Thanks for being willing to work on it.
--
Robert Haas
EDB: http://www.enterprisedb.com
t are arguably unrelated to startup and
> checkpointing.
Well sure. But I've never actually seen that happen.
--
Robert Haas
EDB: http://www.enterprisedb.com
tioned tables should never have had relfilenodes, but as it turns
out, they used to have them.
Let me know your thoughts.
--
Robert Haas
EDB: http://www.enterprisedb.com
v7-0001-pg_upgrade-Preserve-relfilenodes-and-tablespace-O.patch
Description: Binary data
Just because we can't
prevent almost-useless vacuuming is not a sufficient reason to
continue allowing entirely-useless vacuuming that we can prevent. And
it seems like we need a bunch of new bookkeeping to do any better than
that, which seems like a lot of work. So maybe it's the most practical
path forward for the time being, but it feels like more of a
special-purpose kludge than a truly high-quality solution.
--
Robert Haas
EDB: http://www.enterprisedb.com
s wrong
with autovacuum. When there's nothing too crazy happening, it actually
does pretty well. But, when resources are tight or other corner cases
occur, really dumb things start to happen. So it's reasonable to think
about how we can install guard rails that prevent complete insanity.
--
Robert Haas
EDB: http://www.enterprisedb.com
ing the code to provide the relation fork -
and it could be the main fork of some new kind of relation, or it
could use some other existing fork number, or it could be an entirely
new fork. But it would be up to the calling code to figure that stuff
out.
--
Robert Haas
EDB: http://www.enterprisedb.com
the Gather Merge
path, it overrides it with 2 * 366 = 732. This cannot be right.
Really, I don't think it should be overriding the row count estimate
at all. But if it is, multiplying by the number of workers can't be
right, because the leader can also do stuff.
--
Robert Haas
EDB: http://www.enterprisedb.com
orkers) calculation.
Ugh. I was hoping this mess wasn't my fault, but it seems that it is. :-(
--
Robert Haas
EDB: http://www.enterprisedb.com
for that kind of thing, but it's unclear to me what would be
any better.
--
Robert Haas
EDB: http://www.enterprisedb.com
single relation, but ON UPDATE
> rules can refer to both OLD and NEW relations. Maybe we could make the
> error message more friendly, but there's not much else to be done,
> I think.
+1 for making the error message more friendly.
(We would certainly have a difficult time making it less friendly.)
--
Robert Haas
EDB: http://www.enterprisedb.com
the opinion that any place the
documentation has a long list of things, which should add ids, so that
people can link to the particular thing in the list to which they want
to draw someone's attention.
--
Robert Haas
EDB: http://www.enterprisedb.com
sebackup, so I have added
> some that are skipped when not compiling the code with ZLIB.
If they don't decompress the backup and run pg_verifybackup on it then
I'm not sure how much they help. Yet, I don't know how to do that
portably.
--
Robert Haas
EDB: http://www.enterprisedb.com
table
partitioning commit -- f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63. I'm
reasonably sure that the reason why those didn't get added to
expression_tree_walker is that they don't seem like something that can
ever appear in an expression. I still don't understand why that's not
true.
--
Robert Haas
EDB: http://www.enterprisedb.com
x27;t know
why it should be legitimate for pg_get_expr() to just assume that any
random node tree it gets handed must be an expression without doing
any sanity checking.
--
Robert Haas
EDB: http://www.enterprisedb.com
elog(ERROR,
"some internal thing") than it would be for to_timestamp() or
date_bin() or whatever to do something similar. And I think that
careful thinking about supported cases makes life easier for both
users (who know that if they see some junk error report, it's a
mistake rather than
t; get an error something like - not a valid option ?
Before sending an email like this, it would be a good idea to read the
documentation for the --server-compression option.
--
Robert Haas
EDB: http://www.enterprisedb.com
ebackup -t server:/tmp/test0 -Xfetch
> [edb@centos7tushar bin]$ ls /tmp/test0
> backup_manifest base.tar
OK, fair enough, I can adjust the error message for that case.
--
Robert Haas
EDB: http://www.enterprisedb.com
equirement for adding
> checks in the compression path, as a first step, though, but I agree
> that it could be extended more.
Oh, well, if we have a working tar available, then it's not so bad. I
was thinking we couldn't really count on that, especially on Windows.
--
Robert Haas
EDB: http://www.enterprisedb.com
mpress=lz4 --compress=gzip --compression-level=2,
and would thus involve conflicting compression method specifications.
--
Robert Haas
EDB: http://www.enterprisedb.com
rst use of the barrier machinery. But I think it would be
good to get something into master, because then we'd actually be using
this procsignalbarrier stuff for something. On a good day we've fixed
a bug. On a bad day we'll learn something new about how
procsignalbarrier needs to work.
--
Robert Haas
EDB: http://www.enterprisedb.com
ion of changes, you could just use the
barrier mechanism from https://commitfest.postgresql.org/36/2962/ to
wait for those files to disappear, because they've got to be
previously-unliked files that Windows is still returning because
they're still opening -- or else they could be a sign of a corrupted
which relation,
but in practice, you always have to double-check in case the table has
ever been rewritten. It doesn't seem worth continuing to contort the
code for a property we can't guarantee anyway.
--
Robert Haas
EDB: http://www.enterprisedb.com
od to compress data\n"));
That seems to show that, post-patch, the argument to -Z would be a
compression level, even if --compression-method were something other
than gzip.
It's possible that I haven't read something carefully enough, but to
me, what I said seems to be a straightfo
s required.
> It's only a problem if you hold the opinion that there should be
> no user-reachable ERRCODE_INTERNAL_ERROR errors. Which is a fine
> ideal, but I fear we're a pretty long way off from that.
I do hold that opinion, and I think we ought to work in that direction
e
m the WAL.
I am not sure what locking is required here and am not taking a
position on that ... but it's definitely not the case that a logical
decoding plugin can decide to just read from any old table it likes.
--
Robert Haas
EDB: http://www.enterprisedb.com
e prioritizing
at any given time, or even some knowledge. But it doesn't, and is
often busy fiddling while Rome burns.
IOW, the time that it takes to freeze that one tuple *in theory* might
be small. But in practice it may be very large, because we won't
necessarily get around to it on any meaningful time frame.
--
Robert Haas
EDB: http://www.enterprisedb.com
ic. The important point
> is that FreezeLimit could plausibly become nothing more than a
> backstop mechanism, with the design from the patch series -- something
> that typically has no effect on what tuples actually get frozen.
I agree that it's OK for this to become a purely backstop mechanism
... but again, I think that the design of such backstop mechanisms
should be done as carefully as we know how, because users seem to hit
the backstop all the time. We want it to be made of, you know, nylon
twine, rather than, say, sharp nails. :-)
--
Robert Haas
EDB: http://www.enterprisedb.com
correctly while
> triggering ERRORs for extensions that are using it incorrectly. I've
> attached a new version of the patch that does it this way.
That's too magical for my taste.
--
Robert Haas
EDB: http://www.enterprisedb.com
and only then release the technology that
requires the additional page space. Since we don't put new features
into back-branches -- and an on-disk format change would be a poor
place to start -- that would make rolling something like this out take
many years. I think we'll be much happier putting all the complexity
in the new release.
--
Robert Haas
EDB: http://www.enterprisedb.com
(and probably some
> initial implementations).
+1. Trying to rush something through to commit is just going to result
in a bunch of bugs. We need to work through the issues carefully and
take the time to do it well.
--
Robert Haas
EDB: http://www.enterprisedb.com
tions. I
don't think we want to try to reason about what consequences that
might have and prove that somehow it's going to be OK; I think we want
to nail the door shut very tightly to make sure that it can't.
--
Robert Haas
EDB: http://www.enterprisedb.com
g a lock on them" feels quite bad. It's not a stretch to imagine
that failing to follow those invariants could take the whole system
down, which is clearly too severe a consequence for the user's failure
to label things properly.
--
Robert Haas
EDB: http://www.enterprisedb.com
e sometimes say that versions < X are unsupported if we
are unable to test whether or not they work. In other words, I think
the relevant question is whether we are able to demonstrate that it
works, not whether it actually does work.
--
Robert Haas
EDB: http://www.enterprisedb.com
s this is just old, crufty
code - either whatever reasons somebody had for doing it that way are
no longer valid, or there wasn't any good reason even at the time.
--
Robert Haas
EDB: http://www.enterprisedb.com
other
SLRU, like pg_multixact or pg_subtrans. In general SLRU pages that are
actually being used are hot enough that we should keep them in cache
almost no matter what else is competing for cache space ... but the
number of such pages can be different from one SLRU to another, and
can change
have too many other things going on.
--
Robert Haas
EDB: http://www.enterprisedb.com
to consider
the solution that I am proposing rather than the patch you've already
got.
--
Robert Haas
EDB: http://www.enterprisedb.com
're
going to have to give up and admit that polling is a failed strategy,
and it's unclear why 150 million XIDs - or probably even 50 million
XIDs - isn't long enough to say that we're not getting the job done
with half measures.
--
Robert Haas
EDB: http://www.enterprisedb.com
nt for marking other functions leakproof.
I think we will be better off leaving this alone.
--
Robert Haas
EDB: http://www.enterprisedb.com
it's
awful so much as just not my first choice. I also don't think it would
be horrid to leave -z, --gzip, and -Z as shorthands for the
--client-compress=gzip with --compression-level also in the last case,
instead of removing all that stuff.
--
Robert Haas
EDB: http://www.enterprisedb.com
using timestamptz is that
it's not so obvious how to get a different output format ... unless, I
guess, we can cram it into DateStyle. And it's also much less obvious
how you get the other functions and operators to do what you want, if
it's different.
--
Robert Haas
EDB: http://www.enterprisedb.com
27;s happening.
--
Robert Haas
EDB: http://www.enterprisedb.com
tside API, because either the
input values[] array is going to get scribbled on, or it's not. We
should either decide we're not OK with it and just do the fill_val()
thing now, or we should decide that we are and not worry about doing
the fill_val() thing later. IMHO, anyway.
--
Ro
is. Now, maybe you don't, because perhaps that doesn't seem so
important with compression methods as with table AMs. I think that's a
defensible position. But, it is at the underlying level, the same
thing.
--
Robert Haas
EDB: http://www.enterprisedb.com
nal module
override the way it gets computed.
--
Robert Haas
EDB: http://www.enterprisedb.com
clearly a sign of a problem
with the split.)
Regarding 0005:
I think ApplyChangesToIndexes() should be renamed to something like
SetIndexStorageProperties(). It's too generic right now.
I think 0004 and 0005 should just be merged into 0003. I can't see
committing them separa
anged without a recompile
are bad news. That's why we have GUCs.
On another note, I cannot say enough bad things about the function
name two_pass_strategy(). I sincerely hope that you're not planning to
create a function which is a major point of control for VACUUM whose
name gi
that inserts it in the exact place
you think it needs to go?
--
Robert Haas
EDB: http://www.enterprisedb.com
ssue on Andrey's machine? If not, it must be
version-dependent or installation-dependent in some way.
--
Robert Haas
EDB: http://www.enterprisedb.com
; child processes' latches ... that doesn't sound terribly safe from the
> standpoint of not allowing the postmaster to mess with shared memory
> state that could cause it to block or crash. If we already do that
> elsewhere, then OK, but I don't think we do.
It should be u
On Fri, Mar 19, 2021 at 10:11 AM Dilip Kumar wrote:
> Also added a test case for vacuum full to recompress the data.
I committed the core patch (0003) with a bit more editing. Let's see
what the buildfarm thinks.
--
Robert Haas
EDB: http://www.enterprisedb.com
ORCE_RELEASE.
Regarding your point, that does look like clutter. We don't annotate
the dump with a storage clause unless it's non-default, so probably we
should do the same thing here. I think I gave Dilip bad advice here...
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, Mar 19, 2021 at 4:38 PM Robert Haas wrote:
> Yes, and prion's got this concerning diff:
>
> Column | Type | Collation | Nullable | Default | Storage |
> Compression | Stats tar
ere's one from me that tries to make the handling of the LZ4 stuff
more like what we already do for zlib, but I'm not sure if it's
correct, or if it's what everyone wants.
Thoughts?
--
Robert Haas
EDB: http://www.enterprisedb.com
redo-lz4-configuration.patch
Description: Binary data
do hope that some day in the bright future, pglz will
no longer be the thing we're shipping as the postgresql.conf default.
So we'd just be postponing the noise until then. I think we need a
better idea than that.
--
Robert Haas
EDB: http://www.enterprisedb.com
s mention
> of compression altogether (comparable to, eg, --no-tablespaces).
> But I think that's optional. In any case, we don't want
> to put people in a position where they should have used such
> an option and now they have no good way to recover their
> dump to the system
x27;d probably say instead: "This method might
decompress the entire datum rather than just a slice, if slicing is
not supported." or something of to that effect. Feel free to commit
something you like.
--
Robert Haas
EDB: http://www.enterprisedb.com
e my names for things. But that's fine by me -- I'm
> usually not very attached to them. I'm happy to change it to whatever
> you prefer.
My taste in names may be debatable, but including the subsystem name
in the function name seems like a pretty bare-minimum requirement,
especially when the other words in the function name could refer to
just about anything.
--
Robert Haas
EDB: http://www.enterprisedb.com
for this
change. I'll look into that, and your remaining patches, next.
--
Robert Haas
EDB: http://www.enterprisedb.com
0006, aside from the note
above, which is a good one, is there any particular reason why this
patch is labelled as WIP? I think this change makes sense and we
should just do it unless there's some problem with it.
--
Robert Haas
EDB: http://www.enterprisedb.com
that they are "considered internal." Apparently, they're SO internal
that they don't even need to be understandable to other developers.
Anyway, this particular macro name was chosen, it seems, for symmetry
with VARDATA_4B_C, but if you want to change it to something else, I'm
OK with that, too.
--
Robert Haas
EDB: http://www.enterprisedb.com
AL might someday have more cases than just
VARATT_IS_1B_E, but that's not looking like a good bet in 2021.
--
Robert Haas
EDB: http://www.enterprisedb.com
s like you added default_toast_compression out of order, so maybe
> you'd fix that at the same time.
You know, I looked at where you had it and said to myself, "surely
this is a silly place to put this, it would make much more sense to
move this up a bit." Now I feel dumb.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Mar 22, 2021 at 12:16 PM Robert Haas wrote:
> But, what about giving the default_toast_compression_method GUC an
> assign hook that sets a global variable of type "char" to the
> appropriate value? Then GetDefaultToastCompression() goes away
> entirely. That mi
On Mon, Mar 22, 2021 at 2:10 PM Tom Lane wrote:
> Robert Haas writes:
> > I think this is significantly cleaner than what we have now, and I
> > also prefer it to your proposal.
>
> +1 in general. However, I suspect that you did not try to compile
> this without --with
s anyone want to opine about the wait event to use? I was thinking
> PG_WAIT_TIMEOUT or WAIT_EVENT_PG_SLEEP ...
I'm not sure if we should back-patch this, but I think if you do you
should just add a wait event, rather than using a generic one.
--
Robert Haas
EDB: http://www.enterprisedb.com
301 - 400 of 8046 matches
Mail list logo
