On Tue, Jul 26, 2022 at 01:00:41PM +, houzj.f...@fujitsu.com wrote:
> Thanks for the suggestion. I have removed the default and found some missed
> subcommands in 0003 patch. Attach the new version patch here
> (The 0001 and 0002 is unchanged).
I have reviewed what you have here, and I found t
On Thu, Jul 28, 2022 at 12:47:10PM -0400, Tom Lane wrote:
> Actually, on further thought, I do like the resultset idea, because
> it'd remove the need for a complex rewrite of nextval_internal.
> Assuming the SRF is written in ValuePerCall style, each iteration
> can just call nextval_internal with
On Fri, Jul 29, 2022 at 04:15:26PM -0500, Justin Pryzby wrote:
> This was using the old psql rather than the new one.
> Before v10, psql didn't have \if.
# Note that upgrade_adapt.sql from the new version is used, to
# cope with an upgrade to this version.
- $oldnode->command
Hi,
On Tue, Jul 19, 2022 at 03:13:12PM +0900, Michael Paquier wrote:
> On Mon, Jul 18, 2022 at 03:11:51PM +0800, Julien Rouhaud wrote:
>
> > I'm not really sure what should be done here. The best compromise I can
> > think
> > of is to split the tests in 3 parts:
> >
> > 1) view reporting with v
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 and the functions I was talking about look OK
> > now. However, looking again, pg_relation_is_publishable is in the wrong
> > place (should be right
On 2022-Jul-30, Dilip Kumar wrote:
> On Thu, Jul 28, 2022 at 9:29 PM Alvaro Herrera
> wrote:
> > Please don't do this; rather use %llu and cast to (long long).
> > Otherwise the string becomes mangled for translation.
>
> Okay, actually I did not understand the clear logic of when to use
> %ll
On 2022-Jul-30, Michael Paquier wrote:
> PG_VERSION would be simpler. Looking at postmaster.pid would require
> a lookup at external_pid_file, and as it is not set by default you
> would need to add some extra logic in the tests where
> external_pid_file = NULL <=> PGDATA/postmaster.pid.
Hmm, no
Hi,
On Fri, Jun 24, 2022 at 08:16:06PM +0300, Ekaterina Sokolova wrote:
>
> We started discussion about overheads and how to calculate it correctly.
>
> Julien Rouhaud wrote:
> > Can you give a bit more details on your bench scenario?
> > [...]
> > Ideally you would need a custom scenario with a s
On Saturday, July 30, 2022 3:15 PM Michael Paquier wrote:
> On Tue, Jul 26, 2022 at 01:00:41PM +, houzj.f...@fujitsu.com wrote:
> > Thanks for the suggestion. I have removed the default and found some
> > missed subcommands in 0003 patch. Attach the new version patch here
> > (The 0001 and 000
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 and the functions I was talking about
> > > look OK now. However, looking again, p
Alvaro Herrera writes:
> On 2022-Jul-30, Michael Paquier wrote:
>> PG_VERSION would be simpler. Looking at postmaster.pid would require
>> a lookup at external_pid_file, and as it is not set by default you
>> would need to add some extra logic in the tests where
>> external_pid_file = NULL <=> PG
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=2022-07-30%2004%3A57%3A51
regards, tom lane
Noah Misch writes:
> The pg_backend_pid is from "SELECT pg_catalog.pg_backend_pid();" in ~/.psqlrc,
> so the lack of -X caused that. The latest commit fixes things on a normal
> GNU/Linux box, so I bet it will fix wrasse.
Yup, looks like we're all good now. Thanks!
rega
Richard Guo writes:
> [ v4-0001-Using-each-rel-as-both-outer-and-inner-for-anti-j.patch ]
I took a quick look through this. The executor changes are indeed
impressively short, but that's largely because you've paid zero
attention to updating obsoleted comments. For example, in
nodeHashjoin.c th
I wrote:
> Looks like conchuela is still intermittently unhappy.
BTW, quite aside from stability, is it really necessary for this test to
be so freakin' slow? florican for instance reports
[12:43:38] t/025_stuck_on_old_timeline.pl ... ok49010 ms ( 0.00 usr
0.00 sys + 3.64 cusr 2.49 c
Antonin Houska writes:
> I'm going to set the CF entry to "ready for committer'".
I pushed this with some editorialization:
* Grepping found another caller of generate_useful_gather_paths
with the exact same bug, in geqo_eval.c. (A wise man once said
that the most powerful bug-finding heuristic
Justin Pryzby writes:
> On Wed, Jun 29, 2022 at 02:38:12PM +0900, Dong Wook Lee wrote:
>> I wrote a test for pg_prewarm extension. and I wrote it with the aim of
>> improving test coverage, and feedback is always welcome.
> The test fails when USE_PREFETCH isn't defined.
> You can accommodate th
--- Original Message ---
On Friday, July 29th, 2022 at 19:53, Tom Lane t...@sss.pgh.pa.us wrote:
> I wonder if we can combine ideas from the two patches to get a
> better tradeoff of code coverage vs. runtime.
I was checking the Pavel patch and notice that he was using the fillfactor
para
Dong Wook Lee writes:
> I just wrote a test code for the `pg_buffercache` extension which
> doesn't not have test code.
Pushed with minor adjustments. Some notes:
* A .gitignore file is needed so that "git status" won't whine after
running the test. This tends to be pretty much boilerplate; I
Matheus Alcantara writes:
> On Friday, July 29th, 2022 at 19:53, Tom Lane t...@sss.pgh.pa.us wrote:
>> I wonder if we can combine ideas from the two patches to get a
>> better tradeoff of code coverage vs. runtime.
> I was checking the Pavel patch and notice that he was using the fillfactor
> par
Dong Wook Lee writes:
> On 22/06/18 12:07오후, Michael Paquier wrote:
>> As a whole, I am not sure that this is really worth spending cycles on
>> when running check-world or similar, and the code of the extension is
>> trivial.
> Even though it is trivial, I think it would be better if there was a
Dong Wook Lee writes:
> I just wrote test about pg_rowlocks extension.
> I added sql and spec test for locking state.
I think this could be cut down quite a bit. Do we really need
both a SQL test and an isolation test? Seems like you could
easily do everything in the isolation test.
Also, it i
I've been annoyed several times lately by having to update
the list of node types embodied in test_oat_hooks.c's
nodetag_to_string(). I got around to looking at that more
closely, and realized that it is only used for utility
statements, which (a) are a very small subset of the node
types that tha
On Sun, Jul 31, 2022 at 4:51 AM Tom Lane wrote:
> BTW, quite aside from stability, is it really necessary for this test to
> be so freakin' slow? florican for instance reports
>
> [12:43:38] t/025_stuck_on_old_timeline.pl ... ok49010 ms ( 0.00 usr
> 0.00 sys + 3.64 cusr 2.49 csys = 6
Having spent much of the day looking at regression tests for
different bits of contrib, I was inspired to do a quick
finger exercise to add a test for contrib/tcn. When that
module was written, we didn't have a nice way to create a
test case with stable output. But now, the isolationtester
can do
Thomas Munro writes:
> I noticed this is a 32 bit FBSD system. Is it running on UFS, perhaps
> on slow storage? Are soft updates enabled (visible as options in
> output of "mount")?
It's an ancient (2006) mac mini with 5400RPM spinning rust.
"mount" says
/dev/ada0s2a on / (ufs, local, soft-upd
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=2022-07-30%2004%3A57%3A51
And here's one from CI that failed on Li
On Sat, Jul 30, 2022 at 08:54:33PM +0800, Julien Rouhaud wrote:
>
> It turns out that having pg_stat_statements with INSTRUMENT_EXTRA indirectly
> requested by INSTRUMENT_ALL adds a ~27% overhead.
>
> I'm not sure that I actually believe these results, but they're really
> consistent, so maybe that
On Sat, Jul 30, 2022 at 01:13:52PM +, houzj.f...@fujitsu.com wrote:
> I am not against returning the objaddr for cases related to RLS and RelOption.
> But just to confirm, do you have a use case to use the returned
> address(relation itself)
> for RLS or RelOptions in event trigger ? I asked t
On Tue, Jul 26, 2022 at 07:21:29AM -0400, David Steele wrote:
> On 6/19/21 16:39, Noah Misch wrote:
> >On Tue, Feb 02, 2021 at 07:14:16AM -0800, Noah Misch wrote:
> >>Recycling and preallocation are wasteful during archive recovery, because
> >>KeepFileRestoredFromArchive() unlinks every entry in i
On Fri, Jul 08, 2022 at 09:54:50AM -0700, Nathan Bossart wrote:
> Since it's okay to return true or false in the identical/persisted file
> case, I didn't think it deserved emphasis.
I think returning false is not-okay:
> --- a/doc/src/sgml/backup.sgml
> +++ b/doc/src/sgml/backup.sgml
> @@ -681,1
31 matches
Mail list logo
