On Wed, Aug 3, 2022 12:06 PM Masahiko Sawada wrote:
>
> I've attached updated patches that incorporated the above comments as
> well as the comments from Shi yu. Please review them.
>
Thanks for updating the patch.
I noticed that in SnapBuildXidSetCatalogChanges(), "i" is initialized in the if
On Wed, Aug 3, 2022 at 1:51 PM Amit Kapila wrote:
>
> On Sat, Jul 30, 2022 at 12:25 PM Amit Kapila wrote:
> >
> > On Thu, Jul 28, 2022 at 6:37 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Jul 27, 2022 at 7:08 PM shiy.f...@fujitsu.com
> > > wrote:
> > >
> > > I've attached updated patches
On Wed, Aug 3, 2022 at 11:28 AM Dilip Kumar wrote:
>
> On Wed, Aug 3, 2022 at 3:53 AM Andres Freund wrote:
> >
> > On 2022-08-02 17:04:16 -0500, Justin Pryzby wrote:
> > > I got this interesting looking thing.
> > >
> > > ==11628== Invalid write of size 8
> > > ==11628==at 0x1D12B3A: smgrseto
At Wed, 3 Aug 2022 08:51:40 +0530, Amit Kapila wrote
in
> On Wed, Aug 3, 2022 at 7:05 AM Masahiko Sawada wrote:
> > Looking at other codes in snapbuild.c, we call CloseTransientFile()
> > before erroring out in SnapBuildSerialize(). I think it's better to
> > keep it consistent with nearby code
At Wed, 3 Aug 2022 14:02:08 +1200, Thomas Munro wrote
in
> On Wed, Aug 3, 2022 at 12:56 PM Tom Lane wrote:
> > Maybe it would help if you run the strings through normalize() first?
> > I'm not sure if that can combine combining characters.
>
> I think the similarity between Latin combining cha
On Wed, Jul 13, 2022 at 12:34 AM Peter Eisentraut
wrote:
>
I have a question related to commit 964d01ae90. Today, after getting
the latest code, when I compiled it on my windows machine, it lead to
a compilation error because the outfuncs.funcs.c was not regenerated.
I did the usual steps which I
On Wed, Aug 3, 2022 at 3:53 AM Andres Freund wrote:
>
> On 2022-08-02 17:04:16 -0500, Justin Pryzby wrote:
> > I got this interesting looking thing.
> >
> > ==11628== Invalid write of size 8
> > ==11628==at 0x1D12B3A: smgrsetowner (smgr.c:213)
> > ==11628==by 0x1C7C224: RelationGetSmgr (re
> On 2 Aug 2022, at 20:18, Simon Riggs wrote:
>
> On Tue, 2 Aug 2022 at 12:32, Andrey Borodin wrote:
>
>> KnownAssignedXidsRemoveTree() only compress with probability 1/8, but it is
>> still O(N*N).
>
> Currently it is O(NlogS), not quite as bad as O(N^2).
Consider workload when we have a
On Wed, Aug 3, 2022 at 6:43 AM Nathan Bossart
wrote:
> Just under half of the callers in 0002 require the offset, but I don't
know
> if any of those are worth optimizing in the first place. I'll change it
> for now. It's easy enough to add it back in the future if required.
Yeah, some of those
Hi,
Another thing I noticed while working on the "Fast COPY FROM based on
batch insert" patch is: batch inserts vs. WITH CHECK OPTION
constraints from parent views. Here is an example on a normal build
producing incorrect results.
CREATE TABLE base_tbl (a int, b int);
CREATE FUNCTION row_before_
On Tue, Aug 2, 2022 at 11:53 PM Nathan Bossart
wrote:
> I did a bit of cross-checking, and AFAICT this is a reasonable starting
> point. emmintrin.h appears to be sufficient for one of my patches that
> makes use of SSE2 instructions. That being said, I imagine it'll be
> especially important to
On Sat, Jul 30, 2022 at 6:59 PM houzj.f...@fujitsu.com
wrote:
>
> On Saturday, July 30, 2022 7:25 PM Amit Kapila
> wrote:
> >
> > On Fri, Jul 29, 2022 at 3:55 PM Amit Kapila wrote:
> > >
> > > On Fri, Jul 29, 2022 at 3:29 PM Alvaro Herrera
> > wrote:
> > > >
> > > > Well, I checked the commit
On Sat, Jul 30, 2022 at 12:25 PM Amit Kapila wrote:
>
> On Thu, Jul 28, 2022 at 6:37 AM Masahiko Sawada wrote:
> >
> > On Wed, Jul 27, 2022 at 7:08 PM shiy.f...@fujitsu.com
> > wrote:
> >
> > I've attached updated patches that incorporated the above comments as
> > well as the comment from Amit.
On Tue, Aug 2, 2022 at 5:31 PM shiy.f...@fujitsu.com
wrote:
>
> On Mon, Aug 1, 2022 10:31 PM Amit Kapila wrote:
> >
> > On Mon, Aug 1, 2022 at 7:46 AM Masahiko Sawada
> > wrote:
> > >
> > > On Fri, Jul 29, 2022 at 3:45 PM Amit Kapila
> > wrote:
> > > >
> > >
> > > I've attached updated patches
On Wed, 3 Aug 2022 at 07:04, Jacob Champion wrote:
> This entry has been waiting on author input for a while (our current
> threshold is roughly two weeks), so I've marked it Returned with
> Feedback.
Thanks for taking care of this. You dealt with this correctly based on
the fact that I'd failed
On Wed, Aug 3, 2022 at 7:05 AM Masahiko Sawada wrote:
>
> On Wed, Aug 3, 2022 at 10:20 AM Kyotaro Horiguchi
> wrote:
> >
> > At Tue, 2 Aug 2022 13:54:43 +0530, Amit Kapila
> > wrote in
> > > On Tue, Aug 2, 2022 at 12:00 PM Kyotaro Horiguchi
> > > wrote:
> > > >
> > > > + {
> > > > +
On Wed, 3 Aug 2022 at 14:40, Zhihong Yu wrote:
> For array_agg_combine():
>
> + if (state1->alen < reqsize)
> + {
> + /* Use a power of 2 size rather than allocating just reqsize */
> + state1->alen = pg_nextpower2_32(reqsize);
> ...
> + state1->nelems = reqsi
Hi,
On Tue, Aug 02, 2022 at 03:55:28PM -0700, Jacob Champion wrote:
> [Trying -hackers rather than -www this time, since the impacted users are
> here.]
>
> There are occasionally patches that are dutifully rebased by a
> responsive author, all feedback implemented... but there have been no
> rev
On Tue, Aug 2, 2022 at 4:46 PM David Rowley wrote:
> On Wed, 20 Jun 2018 at 19:08, David Rowley
> wrote:
> > I'll submit it again when there more consensus that we want this.
>
> Waking up this old thread again. If you don't have a copy, the entire
> thread is in [1].
>
> The remaining item that
At Tue, 2 Aug 2022 16:03:42 -0500, Don Seiler wrote in
> On Tue, Aug 2, 2022 at 10:01 AM David Steele wrote:
>
> >
> > > That makes sense. Each iteration of the restartpoint recycle loop has a
> > 1/N
> > > chance of failing. Recovery adds >N files between restartpoints.
> > Hence, the
> > >
Tom Lane writes:
> I do not think it's a great idea to create random dependencies
> between modules like the pgstattuple -> bloom dependency you
> casually added here.
I agree with your option.
Is there no problem with selecting all the columns during SELECT statements?
I thought there might be
On Wed, Aug 3, 2022 at 12:56 PM Tom Lane wrote:
> Maybe it would help if you run the strings through normalize() first?
> I'm not sure if that can combine combining characters.
I think the similarity between Latin combining characters and these
ideographic variations might end there. I don't thi
Hi.
Suppose on master, I run a *multi-query* using PQexec and save the value
returned by pg_current_wal_insert_lsn:
master_lsn = query(master, "INSERT INTO some VALUES (...); SELECT
pg_current_wal_insert_lsn()")
Then I run a PQexec query on a replica and save the value returned by
pg_last_wal_re
On Wed, 3 Aug 2022 at 12:18, Tom Lane wrote:
> Now as against that, if the underlying relation scan is parallelized
> then you already have unpredictable input ordering and thus unpredictable
> aggregate results. So anyone who cares about that has already had
> to either disable parallelism or in
On Wed, Aug 3, 2022 at 10:20 AM Kyotaro Horiguchi
wrote:
>
> At Tue, 2 Aug 2022 13:54:43 +0530, Amit Kapila
> wrote in
> > On Tue, Aug 2, 2022 at 12:00 PM Kyotaro Horiguchi
> > wrote:
> > >
> > > + {
> > > + int save_errno = errno;
> > > +
> > > +
On Tue, Aug 02, 2022 at 08:44:04AM +0200, Alvaro Herrera wrote:
> On 2022-Aug-01, Jacob Champion wrote:
>
> > On Mon, Aug 1, 2022 at 10:34 AM Alvaro Herrera
> > wrote:
>
> > > I hate to suggest even more work, but it would be excellent to have some
> > > sort of write-up of what you did here, a
At Tue, 2 Aug 2022 13:54:43 +0530, Amit Kapila wrote
in
> On Tue, Aug 2, 2022 at 12:00 PM Kyotaro Horiguchi
> wrote:
> >
> > + {
> > + int save_errno = errno;
> > +
> > + CloseTransientFile(fd);
> > +
> > + if (readBytes < 0)
>
At Tue, 2 Aug 2022 16:18:44 +0100, Simon Riggs
wrote in
> On Tue, 2 Aug 2022 at 12:32, Andrey Borodin wrote:
>
> > KnownAssignedXidsRemoveTree() only compress with probability 1/8, but it is
> > still O(N*N).
>
> Currently it is O(NlogS), not quite as bad as O(N^2).
>
> Since each xid in th
Thomas Munro writes:
> So you want to match only strings that contain U&'\+003436' *not*
> followed by a variation selector (as we also discussed at [1]). I'm
> pretty sure that everything in PostgreSQL considers variation
> selectors to be separate characters.
There might be something that does
On Wed, Aug 3, 2022 at 12:09 PM 荒井元成 wrote:
> D209007=# create table ivstest ( moji text collate "ja-x-icu" CONSTRAINT
> firstkey PRIMARY KEY );
> D209007=# insert into ivstest (moji) values ( U&'\+003436' || U&'\+0E0101' ||
> U&'\+00304D');
> D209007=# insert into ivstest (moji) values ( U&'\+
David Rowley writes:
> Waking up this old thread again. If you don't have a copy, the entire
> thread is in [1].
> The remaining item that seemed to cause this patch to be rejected was
> raised in [2].
Hmm. My estimate of the percentages of users who will be pleased or
not hasn't really changed
Hi, I hope supported Unicode Variation Selector on collate.
I will resend it because there was a typo.
D209007=# create table ivstest ( moji text collate "ja-x-icu" CONSTRAINT
firstkey PRIMARY KEY );
D209007=# insert into ivstest (moji) values ( U&'\+003436' || U&'\+0E0101' ||
U&'\+00304D');
Hi, I hope supported Unicode Variation Selector on collate.
D209007=# create table ivstesticu (
D209007(# moji text
D209007(# );
D209007=# create table ivstest (
D209007(# moji text collate "ja-x-icu" CONSTRAINT firstkey PRIMARY KEY
D209007(# );
D209007=# insert into ivstest (moji) values ( U&'
On Wed, Sep 30, 2020 at 04:41:51PM +0900, Michael Paquier wrote:
> This feedback has not been answered after two weeks, so I have marked
> the patch as returned with feedback.
I've rebased this patch and will register it in the next commitfest
shortly.
--
Nathan Bossart
Amazon Web Services: http
On Wed, 20 Jun 2018 at 19:08, David Rowley wrote:
> I'll submit it again when there more consensus that we want this.
Waking up this old thread again. If you don't have a copy, the entire
thread is in [1].
The remaining item that seemed to cause this patch to be rejected was
raised in [2]. The s
On Tue, Aug 02, 2022 at 03:55:39PM -0700, Andres Freund wrote:
> FWIW, I'd split the introduction of the helper and the use of it in snapmgr
> into separate patches.
Will do.
> On 2022-08-02 15:13:01 -0700, Nathan Bossart wrote:
>> diff --git a/src/include/c.h b/src/include/c.h
>> index d35405f19
The effective_multixact_freeze_max_age mechanism added by commit
53bb309d2d forces aggressive VACUUMs to take place earlier, as
protection against wraparound of the MultiXact member space SLRU.
There was also a follow-up bugfix several years later -- commit
6bda2af039 -- which made sure that the MX
Hi!
Attached a rebased version of the patch.
Regards
Arne
From: Arne Roland
Sent: Monday, January 31, 2022 19:14
To: Amit Langote
Cc: Zhihong Yu; Alvaro Herrera; Julien Rouhaud; pgsql-hackers
Subject: Re: missing indexes in indexlist with partitioned tables
H
Jacob Champion writes:
> ...and Dinesh's email has just bounced back undelivered. :(
> Anybody interested in running with this? If no one speaks up, I think we
> should return this as "needs more interest" before the next CF starts.
Meh ... the last versions of the patch were far too invasive fo
Hi,
FWIW, I'd split the introduction of the helper and the use of it in snapmgr
into separate patches.
On 2022-08-02 15:13:01 -0700, Nathan Bossart wrote:
> diff --git a/src/include/c.h b/src/include/c.h
> index d35405f191..2c1a47bc28 100644
> --- a/src/include/c.h
> +++ b/src/include/c.h
> @@ -
On Tue, Aug 02, 2022 at 03:31:14PM -0700, Jacob Champion wrote:
> Apologies for dropping entries from cfbot temporarily; that should all be
> fixed now (and I've made a note in the wiki for the next CFM).
Actually, I think that might happen every CF, no matter what you do.
cfbot indexes on (commi
On Tue, Aug 2, 2022 at 6:57 PM Amit Kapila wrote:
>
> On Mon, Jul 25, 2022 at 1:27 PM Peter Smith wrote:
> >
> > On Sat, Dec 11, 2021 at 12:24 AM Alvaro Herrera
> > wrote:
> > >
> > > On 2021-Dec-10, Peter Eisentraut wrote:
> > >
> > ...
> > >
> > > > There was no documentation, so I wrote a bi
On 8/1/22 16:08, Jacob Champion wrote:
> "Today" was slightly optimistic. I'm down to the final stretch of forty
> patches; I'll come back to those tomorrow with fresh eyes.
All right, every entry from July has been closed out or moved! Apologies
for dropping entries from cfbot temporarily; that s
On 2022-08-02 17:04:16 -0500, Justin Pryzby wrote:
> I got this interesting looking thing.
>
> ==11628== Invalid write of size 8
> ==11628==at 0x1D12B3A: smgrsetowner (smgr.c:213)
> ==11628==by 0x1C7C224: RelationGetSmgr (rel.h:572)
> ==11628==by 0x1C7C224: RelationCopyStorageUsingBuff
On Fri, Jul 29, 2022 at 10:38:11PM -0700, Nathan Bossart wrote:
> On Sat, Jul 30, 2022 at 12:02:02PM +0700, John Naylor wrote:
>> I'll be the first to say it's not committable and needs some thought. Since
>> there are several recently proposed patches that take advantage of SSE2, it
>> seems time
On 8/2/22 15:09, Jacob Champion wrote:
> I've carried it forward, but it needs some help to keep from stalling
> out. Definitely make sure it's rebased and up to date by the time the
> next CF starts, to give it the best chance at getting additional review
> (if you haven't received any by then).
>From looking at this patch and its history [1, 2], I think momentum was
probably lost during the January CF, where this patch was unregistered
(presumably by accident).
I've carried it forward, but it needs some help to keep from stalling
out. Definitely make sure it's rebased and up to date by t
Hi Jacob,
On Tue, Aug 2, 2022 at 2:48 PM Jacob Champion
wrote:
> [CFM hat] Okay, either way you look at it, this patchset needs author
> work before any further review can be done. Peter has given some
> additional feedback on next steps, Stephen has asked for clarification
> on the goals of the
On Tue, Aug 02, 2022 at 05:46:34PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > WARNING: problem in alloc set PortalContext: req size > alloc size for
> > chunk 0x7f99508911f0 in block 0x7f9950890800
>
> This looks like nothing so much as the fallout from something scribbling
> past the end
On 6/22/22 06:31, Drouvot, Bertrand wrote:
> FWIW, I just created a new thread to expose the port->authn_id through
> the SYSTEM_USER sql reserved word.
Review for both seems to have dried up a bit. I'm not particularly
invested in my code, but I do want to see *a* solution go in. So if it
helps
On Wed, 3 Aug 2022 at 07:31, Zhihong Yu wrote:
> On Tue, Aug 2, 2022 at 11:02 AM Zhihong Yu wrote:
>> I was looking at the final patch and noticed that setno field in
>> agg_presorted_distinctcheck struct is never used.
> Looks like setoff field is not used either.
Thanks for the report. It se
[CFM hat] Okay, either way you look at it, this patchset needs author
work before any further review can be done. Peter has given some
additional feedback on next steps, Stephen has asked for clarification
on the goals of the patchset, etc. I feel pretty confident in marking
this Returned with Feed
Robert Haas writes:
> WARNING: problem in alloc set PortalContext: req size > alloc size
> for chunk 0x7f99508911f0 in block 0x7f9950890800
> WARNING: problem in alloc set PortalContext: bad size 0 for chunk
> 0x7f99508911f0 in block 0x7f9950890800
> WARNING: problem in alloc set PortalContext:
On 6/30/22 16:16, Jacob Champion wrote:
> [CFM hat] Since you feel strongly about the patch, and we're short on
> time before the commitfest starts, I have re-registered this. That way
> there can be an explicit decision as opposed to a pocket veto by me.
[CFM hat] Okay, with another CF come and g
On Tue, Aug 2, 2022 at 1:50 PM Justin Pryzby wrote:
> Unfortunately, that isn't very consistent, and you have have to run it a bunch
> of times...
I was eventually able to reproduce this in part by using the
interactive psql method you describe. It didn't crash, but it did spit
out a bunch of fun
As discussed in [1], we're taking this opportunity to return some
patchsets that don't appear to be getting enough reviewer interest.
This is not a rejection, since we don't necessarily think there's
anything unacceptable about the entry, but it differs from a standard
"Returned with Feedback" in
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
On Tue, Aug 2, 2022 at 10:01 AM David Steele wrote:
>
> > That makes sense. Each iteration of the restartpoint recycle loop has a
> 1/N
> > chance of failing. Recovery adds >N files between restartpoints.
> Hence, the
> > WAL directory grows without bound. Is that roughly the theory in mind?
>
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
On 8/2/22 4:20 PM, Jonathan S. Katz wrote:
On 8/2/22 3:51 PM, Tom Lane wrote:
"Jonathan S. Katz" writes:
On 8/2/22 3:39 PM, Tom Lane wrote:
I am not in favor of disabling autovacuum in the test: ordinary
users are not going to do that while pg_upgrade'ing, so it'd make
the test less represent
> Right, same thing I'm saying. I also think we should discourage
> people from doing cowboy CCIs inside their OAT hooks, because that
> makes the testability problem even worse. Maybe that means we
> need to uniformly move the CREATE hooks to after a system-provided
> CCI, but I've not thought h
On 8/2/22 3:51 PM, Tom Lane wrote:
"Jonathan S. Katz" writes:
On 8/2/22 3:39 PM, Tom Lane wrote:
I am not in favor of disabling autovacuum in the test: ordinary
users are not going to do that while pg_upgrade'ing, so it'd make
the test less representative of real-world usage, which seems like
On Sun, Jul 31, 2022 at 3:46 PM Thomas Munro wrote:
> On Sun, Jul 31, 2022 at 2:37 AM Tom Lane wrote:
> > Alvaro Herrera writes:
> > > WFM, pushed that way.
> >
> > Looks like conchuela is still intermittently unhappy.
> >
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela&dt=
"Jonathan S. Katz" writes:
> On 8/2/22 3:39 PM, Tom Lane wrote:
>>> I am not in favor of disabling autovacuum in the test: ordinary
>>> users are not going to do that while pg_upgrade'ing, so it'd make
>>> the test less representative of real-world usage, which seems like
>>> a bad idea. We could
On 8/2/22 3:39 PM, Tom Lane wrote:
"Jonathan S. Katz" writes:
On 8/2/22 3:23 PM, Robert Haas wrote:
I'm not quite sure how to rule that theory in or out, though.
Without overcomplicating this, are we able to check to see if autovacuum
ran during the course of the test?
Looks like we're al
"Jonathan S. Katz" writes:
> On 8/2/22 3:23 PM, Robert Haas wrote:
>> I'm not quite sure how to rule that theory in or out, though.
> Without overcomplicating this, are we able to check to see if autovacuum
> ran during the course of the test?
Looks like we're all thinking along the same lines.
On Tue, Aug 2, 2022 at 11:02 AM Zhihong Yu wrote:
>
>> Hi, David:
>
> I was looking at the final patch and noticed that setno field
> in agg_presorted_distinctcheck struct is never used.
>
> Looks like it was copied from neighboring struct.
>
> Can you take a look at the patch ?
>
> Thanks
>
>>
>
"Jonathan S. Katz" writes:
> On 8/2/22 1:12 PM, Tom Lane wrote:
>> Sadly, we're still not out of the woods. I see three buildfarm
>> failures in this test since Robert resolved the "-X" problem [1][2][3]:
> Looking at the test code, is there anything that could have changed the
> relfrozenxid o
On 8/2/22 3:23 PM, Robert Haas wrote:
On Tue, Aug 2, 2022 at 1:12 PM Tom Lane wrote:
Not sure what to make of this, except that maybe the test is telling
us about an actual bug of exactly the kind it's designed to expose.
That could be, but what would the bug be exactly? It's hard to think
of
On Tue, Aug 2, 2022 at 1:12 PM Tom Lane wrote:
> Not sure what to make of this, except that maybe the test is telling
> us about an actual bug of exactly the kind it's designed to expose.
That could be, but what would the bug be exactly? It's hard to think
of a more direct way of setting relminmx
On 8/2/22 1:12 PM, Tom Lane wrote:
"Jonathan S. Katz" writes:
Given this appears to be resolved, I have removed this from "Open
Items". Thanks!
Sadly, we're still not out of the woods. I see three buildfarm
failures in this test since Robert resolved the "-X" problem [1][2][3]:
Not sure wha
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
On Tue, Aug 2, 2022 at 3:25 AM Bharath Rupireddy
wrote:
> ereport_startup_progress infrastructure added by commit 9ce346e [1]
> will be super-useful for reporting progress of any long-running server
> operations, not just the startup process operations. For instance,
> postmaster can use it for re
"Jonathan S. Katz" writes:
> Given this appears to be resolved, I have removed this from "Open
> Items". Thanks!
Sadly, we're still not out of the woods. I see three buildfarm
failures in this test since Robert resolved the "-X" problem [1][2][3]:
grassquit reported
[19:34:15.249](0.001s) not
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
On Mon, Aug 1, 2022 at 10:38 AM Tom Lane wrote:
> > I can't see this on cfbot - either I don't know how to use it
> > properly, which is quite possible, or the results aren't showing up
> > because of the close of the July CommitFest.
>
> I think the latter --- the cfbot thinks the July CF is no l
Robert Haas writes:
> Yeah, I feel like it was a mistake to allow the list of permutations
> to be unspecified. It encourages people to just run them all, which is
> almost never a thoughtful decision. Maybe there's something to be said
> for running these tests in one successful permutation and o
On Tue, Mar 29, 2022 at 11:55:05AM -0400, Robert Haas wrote:
> On Mon, Mar 28, 2022 at 3:08 PM Robert Haas wrote:
> > smgrcreate() as we would for most WAL records or whether it should be
> > adopting the new system introduced by
> > 49d9cfc68bf4e0d32a948fe72d5a0ef7f464944e. I wrote about this con
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
On Tue, Aug 2, 2022 at 11:38 AM Tom Lane wrote:
> I've complained before that the snapshot_too_old TAP tests seem
> ridiculously slow --- close to a minute of runtime even on very fast
> machines. Today I happened to look closer and realized that there's
> an absolutely trivial way to cut that.
>
>
> Hi, David:
I was looking at the final patch and noticed that setno field
in agg_presorted_distinctcheck struct is never used.
Looks like it was copied from neighboring struct.
Can you take a look at the patch ?
Thanks
>
drop-setno-from-agg_presorted_distinctcheck.patch
Description: Bin
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
On Tue, Aug 02, 2022 at 05:22:52PM +0700, John Naylor wrote:
> Given all this, the anti-climax is: it seems we can start with something
> like src/include/port/simd.h with:
>
> #if (defined(__x86_64__) || defined(_M_AMD64))
> #include
> #define USE_SSE2
> #endif
>
> (plus a comment summarizing t
I've complained before that the snapshot_too_old TAP tests seem
ridiculously slow --- close to a minute of runtime even on very fast
machines. Today I happened to look closer and realized that there's
an absolutely trivial way to cut that. The core of the slow runtime
is that there's a "pg_sleep(
Hi,
On 2022-08-02 09:15:12 +0300, Nikita Malakhov wrote:
> Attach includes:
> v11-0002-toaster-interface.patch - contains TOAST API with default Toaster
> left as-is (reference implementation) and Dummy toaster as an example
> (will be removed later as a part of refactoring?).
>
> v11-0003-toaste
1 - 100 of 143 matches
Mail list logo
