> On Nov 5, 2021, at 8:56 PM, Tom Lane wrote:
>
> Some of the buildfarm is unimpressed with this --- looks like the test
> output is less stable than you thought.
Yes, it does. I had to play with it a bit to be sure the test itself is
faulty, and I believe that it is.
—
Mark Dilger
Enterpr
Now it is three days before release of VS2022.
I updated to the latest Preview 7 (= RC3) and recompiled PG14 64bit Release
without issues.
There seem to be not many internal differences from previous versions in the
tools used for building Postgres.
My intention for an early support is to catch
Hi Tomas:
This is the exact patch I want, thanks for the patch!
On Thu, Oct 7, 2021 at 3:33 AM Tomas Vondra
wrote:
> 3) estimation by join pairs
>
> At the moment, the estimates are calculated for pairs of relations, so
> for example given a query
>
> explain analyze
> select * from t1 joi
Justin Pryzby writes:
> On Fri, Nov 05, 2021 at 08:27:49PM -0400, Tom Lane wrote:
>> + one more row than requested, so tha it can determine whether the
> A little typo: tha it
> [ etc ]
Ugh. These notes were prepared in a bit more haste than usual,
and I guess it shows :-(. Will fix, tha
On Sat, Nov 06, 2021 at 04:45:19AM +0100, Pavel Stehule wrote:
> st 3. 11. 2021 v 14:05 odesílatel Tomas Vondra
> napsal:
> > 1) Not sure why we need to call this "schema variables". Most objects
> > are placed in a schema, and we don't say "schema tables" for example.
> > And it's CREATE VARIABL
so 6. 11. 2021 v 15:57 odesílatel Justin Pryzby
napsal:
> On Sat, Nov 06, 2021 at 04:45:19AM +0100, Pavel Stehule wrote:
> > st 3. 11. 2021 v 14:05 odesílatel Tomas Vondra <
> tomas.von...@enterprisedb.com> napsal:
> > > 1) Not sure why we need to call this "schema variables". Most objects
> > >
On 11/3/21 16:18, Tomas Vondra wrote:
Hi,
I looked at this patch today - it's pretty simple and in pretty good
shape, I can't think of anything that'd need fixing. Perhaps the test
might also do EXPLAIN like for other types, to verify the new index is
actually used. But that's minor enough to ha
Hi!
On Fri, Nov 5, 2021 at 10:31 AM Kyotaro Horiguchi
wrote:
> At Thu, 4 Nov 2021 01:07:05 +0300, Alexander Korotkov
> wrote in
> > On Wed, Nov 3, 2021 at 8:51 PM Simon Riggs
> > wrote:
> > > It is however, an undocumented modularity violation. I think that is
> > > acceptable because of the
On 11/5/21 22:15, Daniel Gustafsson wrote:
...
1651: GROUP BY optimization
===
This is IMO a desired optimization, and after all the heavy lifting by Tomas
the patch seems to be in pretty good shape.
I agree it's desirable. To move the patch forward, I need some feedbac
I wrote:
> Hm. I think it's not the only list function with O(N) behavior;
> in fact there used to be more such functions than there are now.
> But I could get behind a patch that annotates all of them.
Here's a quick hack at that. Having done it, I'm not sure if it's
really worth the trouble or
On Fri, Nov 5, 2021 at 5:27 PM Tom Lane wrote:
> As usual, please send any comments/corrections by Sunday.
You probably won't miss this, but just in case: Alexander's very
recent "Reset lastOverflowedXid on standby when needed" commit needs
to be listed now.
--
Peter Geoghegan
Peter Geoghegan writes:
> You probably won't miss this, but just in case: Alexander's very
> recent "Reset lastOverflowedXid on standby when needed" commit needs
> to be listed now.
Yup, I saw it.
regards, tom lane
On Fri, Nov 5, 2021 at 8:18 PM Mark Dilger wrote:
> Thanks, Peter, for this analysis.
It's strategically important work. What you've done so far has every
chance of catching corruption involving storage issues, which is
great. But we ought to do more to catch certain known general patterns
of cor
On Fri, Nov 5, 2021 at 7:51 PM Peter Geoghegan wrote:
> Here are some specific checks I have in mind:
One more for the list:
* Validate PageIsAllVisible() for each page.
In other words, pg_visibility should be merged with verify_heapam.c
(or at least pg_visibility 's pg_check_frozen() and pg_ch
Hi,
On 2021-11-06 14:06:12 -0400, Tom Lane wrote:
> I wrote:
> > Hm. I think it's not the only list function with O(N) behavior;
> > in fact there used to be more such functions than there are now.
> > But I could get behind a patch that annotates all of them.
Personally I think the delete first
Andres Freund writes:
> On 2021-11-06 14:06:12 -0400, Tom Lane wrote:
>> + * Note that this takes time proportional to the length of the list,
>> + * since the remaining entries must be moved.
>> */
>> List *
>> list_delete_first(List *list)
> Perhaps we could point to list_delete_last()? But it'
On 2021-11-06 18:32:54 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2021-11-06 14:06:12 -0400, Tom Lane wrote:
> >> + * Note that this takes time proportional to the length of the list,
> >> + * since the remaining entries must be moved.
> >> */
> >> List *
> >> list_delete_first(List *li
Andres Freund writes:
> On 2021-11-06 18:32:54 -0400, Tom Lane wrote:
>> Good point. The note at list_delete_last that it's O(1) isn't really
>> on point --- instead, the text for list_delete_first should be like
>>
>> + * Note that this takes time proportional to the length of the list,
>> + *
On Sun, Oct 24, 2021 at 04:35:02PM -0700, Noah Misch wrote:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=kittiwake&dt=2021-10-24%2012%3A01%3A10
> got an interesting v9.6 failure [...]:
>
> 2021-10-24 14:25:29.263 CEST [34569:175] pgbench ERROR: could not read
> two-phase state from
> Rebased patches attached. I will change status back to "Ready for Committer"
The CI showed a crash on freebsd, which I reproduced.
https://cirrus-ci.com/task/5203060415791104
The crash is evidenced in 0001 - but only ~15% of the time.
I think it's the same thing which was committed and then re
On 2021/11/05 12:17, Kyotaro Horiguchi wrote:
I'm not sure that that distinction is so clear for users. So I feel we
want a notice something like this. But it doesn't seem correct as it
is. When the user name of the session consists of non-ascii
characters, %u is finally seen as a sequence of
On 2021/11/03 0:03, Bossart, Nathan wrote:
On 11/1/21, 9:44 PM, "Fujii Masao" wrote:
What is the main motivation of this patch? I was thinking that
it's for parallelizing WAL archiving. But as far as I read
the patch very briefly, WAL file name is still passed to
the archive callback functio
Ok, subject was a bit philosophical but this message I just found is
quite confusing.
"""
regression=# select cast(null as anyrange) &> cast(null as anymultirange);
ERROR: argument declared anymultirange is not a multirange type but type
anymultirange
"""
--
Jaime Casanova
Director de Servicio
On Saturday, November 6, 2021, Jaime Casanova
wrote:
> Ok, subject was a bit philosophical but this message I just found is
> quite confusing.
>
> """
> regression=# select cast(null as anyrange) &> cast(null as anymultirange);
> ERROR: argument declared anymultirange is not a multirange type bu
24 matches
Mail list logo
