From: | Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: TAP tests aren't using the magic words for Windows file access |
Date: | 2019-11-22 08:55:46 |
Message-ID: | CAC+AXB30i3aG7-tbq46Jo573R5ZT8zrjF03KA2aUjbjq+HiwNw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 22, 2019 at 9:00 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Thu, Nov 21, 2019 at 08:09:38PM +0100, Juan José Santamaría Flecha
> wrote:
> > I think Perl's open() is a bad candidate for an overload, so I will
> update
> > the previous patch that only touches slurp_file().
>
> FWIW, I don't like much the approach of patching only slurp_file().
> What gives us the guarantee that we won't have this discussion again
> in a couple of months or years once a new caller of open() is added
> for some new TAP tests, and that it has the same problems with
> multi-process concurrency?
>
>
I agree on that, from a technical stand point, overloading open() is
probably the best solution for the reasons above mentioned. My doubts come
from the effort such a solution will take and its maintainability, also
taking into account that there are not that many calls to open() in
"src/test/perl".
Regards,
Juan José Santamaría Flecha
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2019-11-22 09:19:06 | Re: [HACKERS] Block level parallel vacuum |
Previous Message | Konstantin Knizhnik | 2019-11-22 08:15:51 | Re: Why overhead of SPI is so large? |