On 2022-06-13 Mo 22:50, Michael Paquier wrote:
> On Fri, Jun 10, 2022 at 05:45:11PM -0400, Andrew Dunstan wrote:
>> The module is already a noop if there's a TAP test for pg_upgrade. So I
>> don't understand the point of the PR at all.
> Oh. I thought that the old path was still taken as long as
On Fri, Jun 10, 2022 at 05:45:11PM -0400, Andrew Dunstan wrote:
> The module is already a noop if there's a TAP test for pg_upgrade. So I
> don't understand the point of the PR at all.
Oh. I thought that the old path was still taken as long as
--enable-tap-tests was not used. I was wrong, then.
On 2022-06-08 We 20:53, Michael Paquier wrote:
> On Wed, Jun 08, 2022 at 04:13:37PM -0500, Justin Pryzby wrote:
>> On Wed, Jun 08, 2022 at 10:55:29AM +0900, Michael Paquier wrote:
>>> And applied, to take care of this open item.
>> Shouldn't this wait for the buildfarm to be updated again ?
> The
On Wed, Jun 08, 2022 at 04:13:37PM -0500, Justin Pryzby wrote:
> On Wed, Jun 08, 2022 at 10:55:29AM +0900, Michael Paquier wrote:
>> And applied, to take care of this open item.
>
> Shouldn't this wait for the buildfarm to be updated again ?
The TAP logic is able to find any logs by itself on fai
On Wed, Jun 08, 2022 at 10:55:29AM +0900, Michael Paquier wrote:
> And applied, to take care of this open item.
Shouldn't this wait for the buildfarm to be updated again ?
--
Justin
On Mon, Jun 06, 2022 at 10:11:48PM -0500, Justin Pryzby wrote:
> tather => rather
> is charge => in charge
Thanks for the extra read. Fixed. There was an extra one in the
comments, as of s/thier/their/.
> I think it's better with a dot (HHMMSS.ms) rather than underscore (HHMMSS_ms).
>
> The ISO
tather => rather
is charge => in charge
On Mon, Jun 06, 2022 at 01:17:52PM +0900, Michael Paquier wrote:
> but something like %Y%m%d_%H%M%S.%03d (3-digit ms for last part) would
On Tue, Jun 07, 2022 at 08:30:47AM +0900, Michael Paquier wrote:
> I would reduce the format to be MMDDTHHMMSS_ms (
On Tue, Jun 07, 2022 at 08:30:47AM +0900, Michael Paquier wrote:
> If we don't split by the millisecond, we would come back to the
> problems of the original report. On my laptop, the --check phase
> that passes takes more than 1s, but the one that fails takes 0.1s, so
> a follow-up run would comp
On Mon, Jun 06, 2022 at 01:53:35PM -0500, Justin Pryzby wrote:
> It seems important to use a format in most-significant-parts-first which sorts
> nicely by filename, but otherwise anything could be okay.
Agreed.
> Apparently, that's ISO 8601, which can optionally use separators
> (-MM-DDTHH:M
On Mon, Jun 06, 2022 at 07:43:53PM +0200, Daniel Gustafsson wrote:
> > On 6 Jun 2022, at 06:17, Michael Paquier wrote:
> > On Mon, Jun 06, 2022 at 02:38:03AM +0200, Daniel Gustafsson wrote:
> >> On 5 Jun 2022, at 11:19, Michael Paquier wrote:
>
> >>> I have been toying with the idea of a sub-dir
> On 6 Jun 2022, at 06:17, Michael Paquier wrote:
> On Mon, Jun 06, 2022 at 02:38:03AM +0200, Daniel Gustafsson wrote:
>> On 5 Jun 2022, at 11:19, Michael Paquier wrote:
>>> I have been toying with the idea of a sub-directory named with a
>>> timestamp (Unix time, like log_line_prefix's %n but t
On Mon, Jun 06, 2022 at 02:38:03AM +0200, Daniel Gustafsson wrote:
> On 5 Jun 2022, at 11:19, Michael Paquier wrote:
>> On Sun, Jun 05, 2022 at 09:24:25AM +0900, Michael Paquier wrote:
>>> Well, another error that could happen in the early code paths is
>>> EACCES on a custom socket directory spec
> On 5 Jun 2022, at 11:19, Michael Paquier wrote:
>
> On Sun, Jun 05, 2022 at 09:24:25AM +0900, Michael Paquier wrote:
>> Well, another error that could happen in the early code paths is
>> EACCES on a custom socket directory specified, and we'd still face the
>> same problem on a follow-up resta
On Sun, Jun 05, 2022 at 09:24:25AM +0900, Michael Paquier wrote:
> Well, another error that could happen in the early code paths is
> EACCES on a custom socket directory specified, and we'd still face the
> same problem on a follow-up restart. Using a sub-directory structure
> as Daniel and Tom me
On Sat, Jun 04, 2022 at 09:13:46AM -0500, Justin Pryzby wrote:
> Maybe that's easy enough to fix just be rearranging verify_directories() or
> make_outputdirs().
For the case, I mentioned, yes.
> But actually it seems annoying to have to remove the failed outputdir.
> It's true that those logs *c
On Sat, Jun 04, 2022 at 06:48:19PM +0900, Michael Paquier wrote:
> I would suggest the attached patch then, to add a --check command in
> the test suite, with a change to clean up the logs when --check is
> used without --retain.
This doesn't address one of the problems that I already enumerated.
On Fri, Jun 03, 2022 at 10:32:27PM -0500, Justin Pryzby wrote:
> On Sat, Jun 04, 2022 at 12:13:19PM +0900, Michael Paquier wrote:
>> I am not so sure. My first reaction was actually to bypass the
>> creation of the directories on EEXIST.
>
> But that breaks the original motive behind the patch I
On Sat, Jun 04, 2022 at 12:13:19PM +0900, Michael Paquier wrote:
> On Fri, Jun 03, 2022 at 06:55:28PM +0200, Daniel Gustafsson wrote:
> > On 3 Jun 2022, at 18:26, Tom Lane wrote:
> >> How about inserting an additional level of subdirectory?
> >>
> >> pg_upgrade_output.d/20220603122528/foo.log
> >
On Fri, Jun 03, 2022 at 06:55:28PM +0200, Daniel Gustafsson wrote:
> On 3 Jun 2022, at 18:26, Tom Lane wrote:
>> How about inserting an additional level of subdirectory?
>>
>> pg_upgrade_output.d/20220603122528/foo.log
>>
>> Then code doing "rm -rf pg_upgrade_output.d" needs no changes.
>
> Off
> On 3 Jun 2022, at 18:26, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> Or we could revisit Tom's proposal in the thread that implemented the
>> feature:
>> to have timestamped directory names to get around this very problem? I think
>> we should be able to figure out a way to make it easy
Daniel Gustafsson writes:
> Or we could revisit Tom's proposal in the thread that implemented the feature:
> to have timestamped directory names to get around this very problem? I think
> we should be able to figure out a way to make it easy enough for the BF code
> to
> figure out (and clean up
> On 3 Jun 2022, at 15:53, Justin Pryzby wrote:
>
> On Fri, Jun 03, 2022 at 02:01:18PM +0200, Daniel Gustafsson wrote:
>>> On 3 Jun 2022, at 13:19, tushar wrote:
>>
>>> This behavior was not there in earlier released versions, i guess.
>>> Is it expected behavior now onwards?
>>
>> That's an
On Fri, Jun 03, 2022 at 02:01:18PM +0200, Daniel Gustafsson wrote:
> > On 3 Jun 2022, at 13:19, tushar wrote:
>
> > This behavior was not there in earlier released versions, i guess.
> > Is it expected behavior now onwards?
>
> That's an unfortunate side effect which AFAICT was overlooked in th
> On 3 Jun 2022, at 13:19, tushar wrote:
> This behavior was not there in earlier released versions, i guess.
> Is it expected behavior now onwards?
That's an unfortunate side effect which AFAICT was overlooked in the original
thread. Having a predictable name was defined as important for CI/B
Hi,
While performing pg_upgrade from v15Beta binaries/source,
I got this error below error
could not create directory "d2/pg_upgrade_output.d": File exists
Failure, exiting
*Steps to reproduce *
v15 Beta sources
initalize a cluster ( ./initdb -D d1)
initalize another cluster ( ./initdb -D d2)
25 matches
Mail list logo
