On Thu, May 6, 2021 at 9:23 AM Andrew Dunstan wrote:
> On 5/5/21 5:12 PM, Thomas Munro wrote:
> > On Thu, May 6, 2021 at 8:58 AM Andrew Dunstan wrote:
> >> this is an open item for release 14 . The discussion seems to have gone
> >> silent for a couple of weeks. Are we in a position to make any
>
On 5/5/21 5:12 PM, Thomas Munro wrote:
> On Thu, May 6, 2021 at 8:58 AM Andrew Dunstan wrote:
>> this is an open item for release 14 . The discussion seems to have gone
>> silent for a couple of weeks. Are we in a position to make any
>> decisions? I hear what Andres says, but is anyone acting o
On Thu, May 6, 2021 at 8:58 AM Andrew Dunstan wrote:
> this is an open item for release 14 . The discussion seems to have gone
> silent for a couple of weeks. Are we in a position to make any
> decisions? I hear what Andres says, but is anyone acting on it?
I'm going to revert this and resubmit f
On 4/21/21 4:28 PM, Andres Freund wrote:
> Hi,
>
> On 2021-04-20 12:05:27 +1200, Thomas Munro wrote:
>> I'll hold off reverting for a few more days to see if anyone has any
>> other thoughts on that, because there doesn't seem to be any advantage
>> in being too hasty about it.
> I'm not really c
Hi,
On 2021-04-20 12:05:27 +1200, Thomas Munro wrote:
> I'll hold off reverting for a few more days to see if anyone has any
> other thoughts on that, because there doesn't seem to be any advantage
> in being too hasty about it.
I'm not really convinced that this is warranted, and that it isn't
b
On Tue, Apr 20, 2021 at 1:48 PM Julien Rouhaud wrote:
> On Tue, Apr 20, 2021 at 12:05:27PM +1200, Thomas Munro wrote:
> > Yeah, that runs directly into non-trivial locking problems. I felt
> > like some of the other complaints could conceivably be addressed in
> > time, including dumb stuff like
On Mon, Apr 19, 2021 at 07:27:24PM -0700, Peter Geoghegan wrote:
> On Mon, Apr 19, 2021 at 6:45 PM Julien Rouhaud wrote:
> > > This argument seems completely absurd to me.
> >
> > I'm not sure why? For glibc at least, I don't see how we could not end up
> > raising false positive as you have a si
On Mon, Apr 19, 2021 at 6:45 PM Julien Rouhaud wrote:
> > This argument seems completely absurd to me.
>
> I'm not sure why? For glibc at least, I don't see how we could not end up
> raising false positive as you have a single glibc version for all its
> collations. If a user has say en_US and f
On Tue, Apr 20, 2021 at 12:05:27PM +1200, Thomas Munro wrote:
>
> Yeah, that runs directly into non-trivial locking problems. I felt
> like some of the other complaints could conceivably be addressed in
> time, including dumb stuff like Windows default locale string format
> and hopefully some ex
On Mon, Apr 19, 2021 at 11:13:37AM -0700, Peter Geoghegan wrote:
> On Sun, Apr 18, 2021 at 4:23 AM Julien Rouhaud wrote:
> > So IIUC the issue here is that the code could previously record useless
> > collation version dependencies in somes cases, which could lead to false
> > positive possible co
On Tue, Apr 20, 2021 at 8:21 AM Tom Lane wrote:>
> Thomas Munro writes:
> > For example, if you think there actually is a potential better
> > plan than using pg_depend for this, that'd definitely be good to know
> > about.
>
> I really dislike using pg_depend, for a couple of reasons:
>
> * You'
Thomas Munro writes:
> ... The question
> on my mind is whether reverting the feature and trying again for 15
> could produce anything fundamentally better at a design level, or
> would just fix problems in the analyser code that we could fix right
> now.
Well, as I said, I think what we ought to
On Tue, Apr 20, 2021 at 5:53 AM Tom Lane wrote:
> I think that the real fundamental bug is supposing that static analysis
> can give 100% correct answers. ...
Well, the goal was to perform analysis to the extent possible
statically since that would cover the vast majority of cases and is
practic
On Mon, Apr 19, 2021 at 11:49 AM Tom Lane wrote:
> I didn't mean to imply that it's necessarily theoretically impossible,
> but given our lack of visibility into what a function or operator
> will do, plus the way that the collation feature was bolted on
> with minimal system-level redesign, it's
Peter Geoghegan writes:
> On Mon, Apr 19, 2021 at 10:53 AM Tom Lane wrote:
>> I think that the real fundamental bug is supposing that static analysis
>> can give 100% correct answers.
> Is it really the case that static analysis of the kind that you'd need
> to make this 100% robust is fundament
On Sun, Apr 18, 2021 at 4:23 AM Julien Rouhaud wrote:
> So IIUC the issue here is that the code could previously record useless
> collation version dependencies in somes cases, which could lead to false
> positive possible corruption messages (and of course additional bloat on
> pg_depend). False
On Mon, Apr 19, 2021 at 10:53 AM Tom Lane wrote:
> I think that the real fundamental bug is supposing that static analysis
> can give 100% correct answers. Even if it did do so in a given state
> of the database, consider this counterexample:
>
> create type myrow as (f1 int, f2 int);
> create ta
Andres Freund writes:
> On 2021-04-18 11:29:42 -0400, Tom Lane wrote:
>> I'm not sure that an error in this direction is all that much more
>> problematic than the other direction. If it's okay to claim that
>> indexes need to be rebuilt when they don't really, then we could just
>> drop this ent
Hi,
On 2021-04-18 11:29:42 -0400, Tom Lane wrote:
> I'm not sure that an error in this direction is all that much more
> problematic than the other direction. If it's okay to claim that
> indexes need to be rebuilt when they don't really, then we could just
> drop this entire overcomplicated infr
Julien Rouhaud writes:
> On Sat, Apr 17, 2021 at 10:01:53AM +1200, Thomas Munro wrote:
>> It seems to me that there are two things that would be needed to
>> salvage this for PG14: (1) deciding that we're unlikely to come up
>> with a better idea than using pg_depend for this (following the
>> arg
On Sat, Apr 17, 2021 at 10:01:53AM +1200, Thomas Munro wrote:
> On Sat, Apr 17, 2021 at 8:39 AM Tom Lane wrote:
> > Per the changes in collate.icu.utf8.out, this gets rid of
> > a lot of imaginary collation dependencies, but it also gets
> > rid of some arguably-real ones. In particular, calls of
On Fri, Apr 16, 2021 at 10:24:21PM -0400, Tom Lane wrote:
> Thomas Munro writes:
> > On Sat, Apr 17, 2021 at 10:47 AM Tom Lane wrote:
> >> Although there are only a few buildfarm members complaining, I don't
> >> really want to leave them red all weekend. I could either commit the
> >> patch I j
On Fri, Apr 16, 2021 at 01:07:52PM -0400, Tom Lane wrote:
> I wrote:
> > ... or maybe not just yet. Andres' buildfarm critters seem to have
> > a different opinion than my machine about what the output of
> > collate.icu.utf8 ought to be. I wonder what the prevailing LANG
> > setting is for them,
Thomas Munro writes:
> On Sat, Apr 17, 2021 at 10:47 AM Tom Lane wrote:
>> Although there are only a few buildfarm members complaining, I don't
>> really want to leave them red all weekend. I could either commit the
>> patch I just presented, or revert ef387bed8 ... got a preference?
> +1 for c
On Sat, Apr 17, 2021 at 10:47 AM Tom Lane wrote:
> Thomas Munro writes:
> > I'll look into the details some more on Monday.
>
> Fair enough.
>
> Although there are only a few buildfarm members complaining, I don't
> really want to leave them red all weekend. I could either commit the
> patch I j
Thomas Munro writes:
> I'll look into the details some more on Monday.
Fair enough.
Although there are only a few buildfarm members complaining, I don't
really want to leave them red all weekend. I could either commit the
patch I just presented, or revert ef387bed8 ... got a preference?
On Sat, Apr 17, 2021 at 8:39 AM Tom Lane wrote:
> Per the changes in collate.icu.utf8.out, this gets rid of
> a lot of imaginary collation dependencies, but it also gets
> rid of some arguably-real ones. In particular, calls of
> record_eq and its siblings will be considered not to have
> any col
I wrote:
> I feel like this is telling us that there's a fundamental
> misunderstanding in find_expr_references_walker about which
> collation dependencies to report. It's reporting all the
> leaf-node collations, and ignoring the ones that actually
> count semantically, that is the inputcollid fi
I wrote:
> Oh, I bet it's "C.utf8", because I can reproduce the failure with that.
> This crystallizes a nagging feeling I'd had that you were misdescribing
> the collate.icu.utf8 test as not being run under --no-locale. Actually,
> it's only skipped if the encoding isn't UTF8, not the same thing.
Andres Freund writes:
> On 2021-04-16 12:55:28 -0400, Tom Lane wrote:
>> ... or maybe not just yet. Andres' buildfarm critters seem to have
>> a different opinion than my machine about what the output of
>> collate.icu.utf8 ought to be. I wonder what the prevailing LANG
>> setting is for them, a
I wrote:
> ... or maybe not just yet. Andres' buildfarm critters seem to have
> a different opinion than my machine about what the output of
> collate.icu.utf8 ought to be. I wonder what the prevailing LANG
> setting is for them, and which ICU version they're using.
Oh, I bet it's "C.utf8", beca
Hi,
On 2021-04-16 12:55:28 -0400, Tom Lane wrote:
> I wrote:
> >> That's what I ended up with too, so LGTM!
>
> > Pushed, thanks for review! (and I'll update the open items list in a
> > sec)
>
> ... or maybe not just yet. Andres' buildfarm critters seem to have
> a different opinion than my m
I wrote:
>> That's what I ended up with too, so LGTM!
> Pushed, thanks for review! (and I'll update the open items list in a
> sec)
... or maybe not just yet. Andres' buildfarm critters seem to have
a different opinion than my machine about what the output of
collate.icu.utf8 ought to be. I wo
Julien Rouhaud writes:
> On Fri, Apr 16, 2021 at 10:03:42AM -0400, Tom Lane wrote:
>> So I propose that we do 0001 below, which is my first patch plus your
>> suggestion about fixing up create_index.sql. This passes check-world
>> for me under both C and en_US.utf8 prevailing locales.
> That's w
On Fri, Apr 16, 2021 at 10:03:42AM -0400, Tom Lane wrote:
>
> Since the proposed patch removes the dependency code's special-case
> handling of the default collation, I don't feel like we need to jump
> through hoops to prove that the default collation is tracked the
> same as other collations. A
Julien Rouhaud writes:
> On Thu, Apr 15, 2021 at 10:06:24AM -0400, Tom Lane wrote:
>> 0001 fails for me :-(. I think that requires default collation to be C.
> Oh right, adding --no-locale to the regress opts I see that create_index is
> failing, and that's not the one I was expecting.
> We cou
On Thu, Apr 15, 2021 at 10:06:24AM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
> > On Wed, Apr 14, 2021 at 01:18:07PM -0400, Tom Lane wrote:
> >> (To be clear: 0002 passes check-world as-is, while 0001 is not
> >> committable without some regression-test fiddling.)
>
> > I'm probably missing
Julien Rouhaud writes:
> On Wed, Apr 14, 2021 at 01:18:07PM -0400, Tom Lane wrote:
>> (To be clear: 0002 passes check-world as-is, while 0001 is not
>> committable without some regression-test fiddling.)
> I'm probably missing something obvious but both 0001 and 0002 pass check-world
> for me, on
On Wed, Apr 14, 2021 at 01:18:07PM -0400, Tom Lane wrote:
>
> One question here is whether it's correct that the domain's dependency
> on collation "aa_DJ" is unversioned. Maybe that's intentional, but it
> seems worth asking.
This is intentional I think, we should record collation version only
I noticed some broken-looking logic in recordMultipleDependencies
concerning how it records collation versions. It was a bit harder
than I expected to demonstrate the bugs, but I eventually succeeded
with
u8=# create function foo(varchar) returns bool language sql return false;
CREATE FUNCTION
u8
40 matches
Mail list logo
