Every once in awhile we get failures like this one:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gull&dt=2019-11-05%2008%3A27%3A27
diff -U3
/home/pgsql/build-farm/buildroot-clang/HEAD/pgsql.build/../pgsql/src/test/regress/expected/vacuum.out
/home/pgsql/build-farm/buildroot-clang/HE
Hi,
On 2019-11-06 16:54:38 -0500, Tom Lane wrote:
> Every once in awhile we get failures like this one:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gull&dt=2019-11-05%2008%3A27%3A27
>
> diff -U3
> /home/pgsql/build-farm/buildroot-clang/HEAD/pgsql.build/../pgsql/src/test/regress/
On Wed, Nov 06, 2019 at 03:01:11PM -0800, Andres Freund wrote:
> I don't know what lead us to doing so, but it doesn't seem reasonable to
> allow the user to see whether the table has actually been vacuumed. I
> would assume that one uses SKIP_LOCKED partially to avoid unnecessary
> impacts in prod
Michael Paquier writes:
> On Wed, Nov 06, 2019 at 03:01:11PM -0800, Andres Freund wrote:
>> I don't know what lead us to doing so, but it doesn't seem reasonable to
>> allow the user to see whether the table has actually been vacuumed. I
>> would assume that one uses SKIP_LOCKED partially to avoid
On Thu, Nov 07, 2019 at 11:50:25AM -0500, Tom Lane wrote:
> Michael Paquier writes:
>> Good question. That's a historical choice, still I have seen cases
>> where those warnings are helpful while not making the logs too
>> verbose to see some congestion in the jobs.
>
> I kind of feel that NOTIC
I wrote:
> Michael Paquier writes:
>> Good question. That's a historical choice, still I have seen cases
>> where those warnings are helpful while not making the logs too
>> verbose to see some congestion in the jobs.
> I kind of feel that NOTICE is more semantically appropriate, but
> perhaps t
Hi,
On 2019-11-14 13:37:44 -0500, Tom Lane wrote:
> I wrote:
> > Michael Paquier writes:
> >> Good question. That's a historical choice, still I have seen cases
> >> where those warnings are helpful while not making the logs too
> >> verbose to see some congestion in the jobs.
>
> > I kind of f
Andres Freund writes:
> On 2019-11-14 13:37:44 -0500, Tom Lane wrote:
>> As for the SKIP_LOCKED tests in vacuum.sql, what I now propose is that
>> we just remove them. I do not see that they're offering any coverage
>> that's not completely redundant with this isolation test. We don't
>> need to
On Thu, Nov 14, 2019 at 03:20:09PM -0500, Tom Lane wrote:
> If we're going to keep them in vacuum.sql, we should use the
> client_min_messages fix there, as that's a full solution not just
> reducing the window. But I don't agree that these tests are worth
> the cycles, given the coverage elsewher
Michael Paquier writes:
> I would rather keep the solution with client_min_messages, and the
> tests in vacuum.sql to keep those checks for the grammar parsing. So
> this basically brings us back to use the patch I proposed here:
> https://www.postgresql.org/message-id/20191107013942.ga1...@paqui
On Fri, Nov 15, 2019 at 11:22:20AM -0500, Tom Lane wrote:
> Michael Paquier writes:
>> I would rather keep the solution with client_min_messages, and the
>> tests in vacuum.sql to keep those checks for the grammar parsing. So
>> this basically brings us back to use the patch I proposed here:
>> h
11 matches
Mail list logo