Mark Dilger writes:
> On Mar 12, 2021, at 10:22 PM, Tom Lane wrote:
>> Coping with both endiannesses might be painful.
> Not too bad if the bigint value is zero, as both the low and high 32bits will
> be zero, regardless of endianness. The question is whether that gives up
Mark Dilger writes:
> On Mar 12, 2021, at 10:36 PM, Tom Lane wrote:
>> You might think about using some symmetric-but-not-zero value,
>> 0x01010101 or the like.
> I thought about that, but I'm not sure that it proves much more than just
> using zero.
Perhaps not.
Noah Misch writes:
> On Sat, Mar 13, 2021 at 01:36:11AM -0500, Tom Lane wrote:
>> I don't mind updating the perl installations on prairiedog and gaur,
>> but Noah might have some difficulty with his AIX flotilla, as I believe
>> he's not sysadmin there.
>
ctly swap the two 32-bit words. Hence, any value in
which upper and lower halves are the same should work, say
0x1234567812345678.
regards, tom lane
cript is running under unusual conditions.
regards, tom lane
subtests
These animals have somewhat weird alignment properties: MAXALIGN is 8
but ALIGNOF_DOUBLE is only 4. I speculate that that is affecting their
choices about whether an out-of-line TOAST value is needed, breaking
this test case.
regards, tom lane
at
would also reduce the pressure to duplicate all the test cases.
(I don't intend this complaint as a deal-breaker; Peter may well
have considered this alternative already and rejected it for good
reasons.)
regards, tom lane
[ getting back to this, after a bit of procrastination ]
Andrew Dunstan writes:
> On 2/11/21 1:32 PM, Tom Lane wrote:
>> Noah Misch writes:
>>> On Tue, Feb 09, 2021 at 05:34:37PM -0500, Tom Lane wrote:
>>>> * A case could be made for tightening things up a l
Mark Dilger writes:
> On Mar 15, 2021, at 10:04 AM, Tom Lane wrote:
>> These animals have somewhat weird alignment properties: MAXALIGN is 8
>> but ALIGNOF_DOUBLE is only 4. I speculate that that is affecting their
>> choices about whether an out-of-line TOAST value is nee
k we're better advised
to keep our options open about how REFRESH might be implemented
in future.
regards, tom lane
e; it'd render the context message nearly
useless.) A different idea is to try to get the column names out
of the query's rangetable instead of going to the catalogs.
regards, tom lane
ng plan node --- but that doesn't really get you any closer
to being able to say which one it is exactly. The input is either not
ordered at all, or ordered by something like a Sort node, which itself
is not going to make any promises about which one of a group of peers
is delivered first.
regards, tom lane
x27;s suggestion for that at some point.
I started to look at this, and immediately began to wonder where is the
previous discussion you're evidently referring to. Can you dig up an
archives link?
regards, tom lane
Justin Pryzby writes:
> On Mon, Mar 15, 2021 at 06:45:49PM -0400, Tom Lane wrote:
>> I started to look at this, and immediately began to wonder where is the
>> previous discussion you're evidently referring to. Can you dig up an
>> archives link?
> I think I wa
n functions, like citext_cmp, but that wouldn't
affect the grouping logic that is going to save aside one of the
group of peer values.
regards, tom lane
regards, tom lane
this a bit clearer, and pushed it.
regards, tom lane
y mac laptop. This rules out the theory that
> autovacuum is propogating corruptions into pg_statistic, and also the theory
> that it is architecture dependent.
I wonder whether amcheck is confused by the declaration of those columns
as "anyarray".
regards, tom lane
at might be from mis-decoding
a TOAST-referencing datum. (Too bad the message doesn't report the
TOAST OID it probed for, so we can see if that's sane or not.)
regards, tom lane
its credibility. I now
believe the theory that the triggering condition is an auto-analyze
happening at the right time, and populating pg_statistic with
some data that other runs don't see.
regards, tom lane
tents to be different/wrong on the
replica.
regards, tom lane
Mark Dilger writes:
> On Mar 16, 2021, at 10:48 AM, Tom Lane wrote:
>> (Too bad the message doesn't report the
>> TOAST OID it probed for, so we can see if that's sane or not.)
> I've added that and now get the toast pointer's va_valueid in the message
Robert Haas writes:
> On Tue, Mar 16, 2021 at 1:48 PM Tom Lane wrote:
>> No. What should be happening there is that some arrays in the column
>> get larger alignment than they actually need, but that shouldn't cause
>> a problem (and has not done so, AFAIK, in the deca
ng with the problem. These days it looks like it's actually
toast_tuple_init() that takes care of dereferencing previously-toasted
values during an INSERT.
regards, tom lane
uses of the pattern you postulated originally. It's more that
we've designed some valgrind-unfriendly data structures. We need to
improve that situation to make much progress here.
regards, tom lane
diff --git a/src/backend/libpq/pqcomm.c b/src/backend/libpq/pqc
structing the scan-clause selectivity because
(at least in all normal cases) that selectivity would have been
cached in the RestrictInfo. Thus we not only save cycles but can be
sure we are cancelling out exactly the right amount of selectivity.
I would not propo
ely assuming that that would happen.
regards, tom lane
, that seems wrong. I'd just remove HEAP_TABLE_AM_HANDLER_OID.
As long as we're not back-patching the change, it seems like a very
minor thing to fix, if anyone outside core is referencing the old name.
regards, tom lane
be I'm wrong) that it's clear enough that you can run
whichever test case(s) you want, but this behavior of generating a
partial coverage report is less clear. Maybe instead of
The "make" commands also work in subdirectories.
we could say
You can run the "make coverage-html" command in a subdirectory
if you want a coverage report for only a portion of the code tree.
regards, tom lane
vior would change for pathnames containing spaces or the
like, but it is probably kinda broken for such cases today anyway.
In any case, Michael had promised to test this aspect before committing.
regards, tom lane
arm, but it works for me on
both 64-bit and 32-bit machines, so probably it's OK.
regards, tom lane
diff --git a/src/test/regress/expected/join.out b/src/test/regress/expected/join.out
index a46b1573bd..6c9a5e26dd 100644
--- a/src/test/regress/expected/join.out
l in the most common case wasn't a good reason
for leaving the bug in place. I'm not excited about the test case
ced138e8cba added though, so I think your proposed patch is fine.
Will push shortly.
regards, tom lane
Tomas Vondra writes:
> On Tue, Oct 27, 2020 at 01:58:56PM -0400, Tom Lane wrote:
>>> Attached is a patch series that attacks it that way.
> The patch sems fine to me, thanks for investigating and fixing this.
Thanks for looking at it!
> I find it
Alvaro Herrera writes:
> On 2020-Oct-27, Tom Lane wrote:
>> * Changing the set of fields in ForeignKeyOptInfo is an ABI break.
>> We could minimize the risk by adding the new fields at the end in
>> the back branches, but it still wouldn't be zero-risk.
> It'
YOID
and then getting rid of the oid_symbol entries. (Or perhaps we
could just up and nuke CASHOID too? It's somewhat dubious that
any outside code is really using that macro.)
May not be worth the trouble, but if we're anal enough to do this
patch maybe we should do that too.
regards, tom lane
SNOID available as aliases, and renaming
the rest.
regards, tom lane
thout a wholesale redefinition of
how auto-analyze is supposed to work. As a close analogy, we
don't make any effort to force an immediate auto-analyze after
CREATE STATISTICS.
I don't see anything in the CREATE STATISTICS man page pointing
that out, either. But there's probably room for "Notes" entries
about it in both places.
regards, tom lane
and then your "simple" patch isn't so simple
anymore. (Not that it was simple anyway. What if the CREATE is
inside a transaction block, for instance? There's no use in
kicking autovacuum before commit.)
regards, tom lane
Andres Freund writes:
> On 2020-10-28 14:49:06 -0400, Tom Lane wrote:
>> Moreover, this clearly shows the
>> effect John mentioned that people have been copying the style of adjacent
>> entries rather than making use of the standard oid_symbol convention like
>> th
Andres Freund writes:
> I assume you plan to error out if oid_symbol is defined for pg_type
> going forward?
Right, just like we just did for pg_proc.
regards, tom lane
sideration to
expend effort on. You shouldn't be killing the postmaster that way.
If you do, you'll soon learn not to, for plenty of reasons besides
this one.
regards, tom lane
#x27;t distinguish
postmaster states that don't allow starting a bgworker right
this moment, but probably will allow it later, from states in
which it never will be allowed and we need to fail the request
not just postpone it indefinitely.
regards, tom lane
PGOPTIONS through from the client?
regards, tom lane
Magnus Hagander writes:
> On Thu, Oct 29, 2020 at 4:45 PM Tom Lane wrote:
>> I don't think it's really obsolete ... don't we use that to pass
>> PGOPTIONS through from the client?
> That said, I don't think we do, or I'm misunderstanding what you
anyway? That wouldn't fix anything except autovacuum,
but if you're right that that's a primary pain point then it'd help.
regards, tom lane
John Naylor writes:
> Here is a quick patch implementing this much.
Pushed with a couple cosmetic tweaks.
regards, tom lane
paths for this
purpose is a fine way to add bugs we'll never catch.
The if-we're-going-to-delay-anyway path in vacuum_delay_point seems
OK to add a touch more overhead to, though.
regards, tom lane
on changing this. Maybe it's really a bug, but maybe there are good
reasons.
regards, tom lane
Jimmy Angelakos writes:
> Please find attached my first patch (the tiniest of doc patches) :
> I found the wording around convalidated in pg_catalog documentation a bit
> confusing/ambiguous.
Seems reasonable; pushed.
regards, tom lane
for the repetitiveness, we could just say "This view ...", in one or
even both paras.
regards, tom lane
t Naylor is working
on cleaning that up, maybe it will become less useless.
regards, tom lane
"This view ..." so we don't have to have
this discussion again the next time somebody wants to add a para here.
regards, tom lane
Justin Pryzby writes:
> Not sure if Tom saw this yet.
Indeed, I'd not been paying attention. Fix looks good, pushed.
regards, tom lane
robably not
worth the cycles.)
regards, tom lane
construct the tuple, but it doesn't seem like it'd be much.
regards, tom lane
the get_variable_numdistinct
result to be not more than that. But I still would not want to
trust an exact zero result.
regards, tom lane
ing the number of GROUP BY
groups, it seems like that would be correct. There might be some
callers that don't want it though.
regards, tom lane
DISPLAY_XXX, to make this less confusing.
Another bit of follow-up work we could contemplate is to get rid of
the SQLValueFunction node type, since there's nothing it does that
we couldn't do with regular FuncExpr nodes and COERCE_SQL_SYNTAX.
But that's just cleanup, and I don't
an additional benefit, we can generate macros for all the bootstrap
pg_proc entries, not only ones that are for C functions; that fixes
another issue noted in [1].
Hence, I propose the attached. Any objections?
regards, tom lane
[1] https://www.postgresql.org/message-id/29
function NNN called as normal function".
That doesn't really seem like a problem.
The attached patch is a delta over the one in [1].
regards, tom lane
[1] https://www.postgresql.org/message-id/472274.1604258384%40sss.pgh.pa.us
diff --git a/src/backend/c
isolation and run check or installcheck there.
regards, tom lane
SQL-NULL (or for some
> other unexpected situations.).
Isn't the comment just above there wrong?
/* these could be nulls */
I wonder just when that became outdated.
regards, tom lane
master, that implements the approach as
> described
> in that discussion.
Please add an entry to the upcoming commitfest, to make sure we don't
lose track of this:
https://commitfest.postgresql.org/30/
regards, tom lane
Isaac Morland writes:
> On Sun, 1 Nov 2020 at 15:47, Tom Lane wrote:
>> Anyway, this saves about 3KB in fmgrtab.o, without any downside
>> that I can see. If someone accidentally called an aggregate as
>> a normal function, they'd now get a different error message,
&g
Heikki Linnakangas writes:
> On 01/11/2020 22:47, Tom Lane wrote:
>> With that, we don't actually need aggregate_dummy() to exist at
>> all, because it's never referenced. Having "aggregate_dummy"
>> as the prosrc value for an aggregate function is n
pose to backpatch this.
LGTM
regards, tom lane
parate search paths for
relation lookup and function/operator lookup. We have sort of stuck
our toe in that pond already by discriminating against pg_temp for
function/operator lookup, but we could make that more formalized and
controllable if there were distinct settings. I'm not sure offhand
how much of a compatibility problem that produces.
regards, tom lane
d for (some?) non-C locales on
Windows. Could be something as dumb as spaces in the locale name
being problematic.
regards, tom lane
emoryContext, but removing the dynamic parts?
I'd be inclined to keep it as-is for now. It's not adding any significant
amount of cycles compared to the process fork, so we might as well
preserve flexibility.
Is it really possible to not include miscadmin.h in postmaster.c?
I find that a bit surprising.
regards, tom lane
t seems
reasonable, since this function previously had what looked like sane
handling for that case.
Anyway, I adjusted Kyotaro-san's patch a bit (including fixing the
near identical code in make_viewdef) and pushed it.
regards, tom lane
s
100% hostile to that.
* Still waiting for comments on whether to rename CoercionForm.
regards, tom lane
diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
index 530aac68a7..3031c52991 100644
--- a/src/backend/nodes/copyfuncs.c
+++ b/s
(.
Yeah. In the short run, though, it'd be nice to un-break the buildfarm.
Maybe we could push David's code or something similar, and then
contemplate better ways at leisure?
regards, tom lane
o value except adding confusion: there are no zero-argument
functions named "position" in pg_catalog.
I feel like this is committable at this point --- any objections?
regards, tom lane
diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
inde
Magnus Hagander writes:
> [ remove_option_o_2.patch ]
This seems committable to me now, although ...
> On Mon, Nov 2, 2020 at 6:58 PM Tom Lane wrote:
>> Magnus Hagander writes:
>>> Initially I kept the dynamic argv/argc in even though it's now
>>> hardcoded,
just neuter the feature if Windows
> decides it can't understand a locale names that it gave us. It should
> still work fine with something like initdb --lc-collate=en-US. Here's
> an untested patch. Thoughts?
Works for me, at least as a short-term solution.
regards, tom lane
d.
Arguably, the whole point of doing something here is to make ALTER
SYSTEM handle this variable more sensibly. In that context,
'/tmp/sock1, /tmp/sock2' *should* be taken as one item IMO.
We can't change the behavior without, um, changing the behavior.
regards, tom lane
I wrote:
> Heikki Linnakangas writes:
>> On 01/11/2020 22:47, Tom Lane wrote:
>>> With that, we don't actually need aggregate_dummy() to exist at
>>> all, because it's never referenced. Having "aggregate_dummy"
>>> as the prosrc value for a
Pavel Stehule writes:
> út 22. 9. 2020 v 2:33 odesílatel Tom Lane napsal:
>> Anyway, attached find
>> 0001 - updates Vik's original patch to HEAD and tweaks the
>> grammar in the docs a bit.
>> 0002 - add-on patch to convert array_append, array_prepe
rphic function, but I'm not quite sure what a good candidate
would be.
regards, tom lane
ycompatible) returns anycompatible as
'select $1' language sql;
CREATE FUNCTION
regression=# select foo('bar');
foo
-
bar
(1 row)
regression=# select pg_typeof(foo('bar'));
pg_typeof
-------
text
(1 row)
So even if we decide that changing the rules for "anyelement" is
too scary, I think switching to_json to anycompatible would be
preferable to switching it to "any".
regards, tom lane
See
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=c66a3225e07b5098a796f24588a6b81bfdedd2fd
Please send any corrections by Sunday.
regards, tom lane
Tomas Vondra writes:
> We should probably include instructions what to do about the BRIN
> data corruption fixed by 7577dd8480 - a query to list might be
> affected by the bug and should be rebuilt.
Do you have some suggested text?
regards, tom lane
e-id/flat/BL0PR1901MB1985F219C46C61EDE7036C34ED8E0%40BL0PR1901MB1985.namprd19.prod.outlook.com
regards, tom lane
low it if either
the calling user or the view owner has the needed permission". This
seems generally pretty messy and so I don't much like it, but we
should consider as many solutions as we can think of.
Thoughts?
regards, tom lane
[1]
https://www.postgresql.org/message-id/flat/16703-e348f58aab3cf6cc%40postgresql.org
to an existing test. Other than that, looks good, pushed.
regards, tom lane
Tomas Vondra writes:
> On 11/7/20 3:52 AM, Tom Lane wrote:
>> Do you have some suggested text?
> I think this might work:
I dunno ... given that we have zero field reports, I doubt this is
something we need to tell every BRIN user to do. The text I put in
earlier today jus
quot; fixes into those branches. I got my
fingers burned today, and so did Peter. Don't follow our example ;-)
regards, tom lane
d need to back port this commit on 12 and 13.
Yeah, this is sufficient reason why we must use the more invasive
patch on those branches. What I'm wondering now is if there's a
way to break even-older branches based on failure to handle dropped
columns here.
regards, tom lane
to deal with
an on-disk tuple rather than one constructed by the executor.
So I'll go see about back-patching 20d3fe900.
regards, tom lane
so, could we prioritize getting that committed? It's annoying
to have the buildfarm failures page so full of this one issue.
regards, tom lane
Ouch. Get well soon, and don't overstress your hand --- that's a
good recipe for long-term problems.
regards, tom lane
-record, so we don't need
the operation to be array_cat() specifically. So I propose the attached
patches to un-break the xversion tests.
I'll hold off pushing this till after this week's wraps, though.
regards, tom lane
diff --git a/src/test/regress/expe
ssages as-is
and add explicit "(int)" casts to the arguments. There are some
fraction of these that are like that already.
regards, tom lane
Magnus Hagander writes:
> On Wed, Nov 4, 2020 at 2:10 AM Tom Lane wrote:
>> ... looking at this again, BackendRun certainly looks ridiculously
>> over-engineered for what it still does.
> Yeah, looking at it again, I agree. PFA an updated patch, which I'll
> go ahe
embedding some strings, as
I suggested upthread, seems like it'd go far in that direction.
Yeah, you could spend a lot of effort to make it a bit more user
friendly, but is the effort really going to be repaid? The use
case for this isn't that large, I don't think.
regards, tom lane
msec not usec. I think the
comment about "clock skew" is complete BS, and the Min() calculation was
put in as a workaround by somebody observing that the sleep waited too
long, but not understanding why.
regards, tom lane
Alexey Kondratov writes:
> On 2020-11-09 21:53, Tom Lane wrote:
>> 0002 seems like a pretty clear bug fix, though I wonder if this is exactly
>> what we want to do going forward. It seems like a very large fraction of
>> the callers of TimestampDifference would like to h
performance changes up to a couple percent with
no apparent change to the relevant code.
regards, tom lane
Do we really need exclusive lock on the ProcArray to make this flag
change? That seems pretty bad from a concurrency standpoint.
regards, tom lane
Michael Paquier writes:
> On Mon, Nov 09, 2020 at 08:32:13PM -0500, Tom Lane wrote:
>> Do we really need exclusive lock on the ProcArray to make this flag
>> change? That seems pretty bad from a concurrency standpoint.
> Any place where we update vacuumFlags acquires an e
501 - 600 of 17703 matches
Mail list logo
