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
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 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 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 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
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
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
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
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
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
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
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:
> 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
--- 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
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
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
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
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
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
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
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
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
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
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 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
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 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
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 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
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 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
31 matches
Mail list logo
