On Tue, May 04, 2021 at 11:38:09AM -0400, Tom Lane wrote:
> I believe the attached will do the trick, but I'm running the test
> with debug_invalidate_system_caches_always turned on to verify
> that. Should be done in an hour or so...
Thanks for taking care of that!
--
Michael
signature.asc
Des
On Tue, May 4, 2021 at 9:08 PM Tom Lane wrote:
>
> Bharath Rupireddy writes:
> > On Tue, May 4, 2021 at 4:12 AM Tom Lane wrote:
> >> The buildfarm is showing that one of these test queries is not stable
> >> under CLOBBER_CACHE_ALWAYS:
>
> > I can reproduce the issue with the failing case. Issue
Bharath Rupireddy writes:
> On Tue, May 4, 2021 at 4:12 AM Tom Lane wrote:
>> The buildfarm is showing that one of these test queries is not stable
>> under CLOBBER_CACHE_ALWAYS:
> I can reproduce the issue with the failing case. Issue is that the
> backend pid will be null in the pg_stat_activi
On Tue, May 4, 2021 at 7:05 PM Tom Lane wrote:
>
> Michael Paquier writes:
> > (Worth noting that I am out this week for Golden Week, so if this can
> > wait until Monday, that would be nice. I am not willing to take my
> > chances with the buildfarm now :p)
>
> I will see to it. I think it's i
Michael Paquier writes:
> (Worth noting that I am out this week for Golden Week, so if this can
> wait until Monday, that would be nice. I am not willing to take my
> chances with the buildfarm now :p)
I will see to it. I think it's important to get a fix in in the next
couple of days, because
On Tue, May 04, 2021 at 12:43:53PM +0530, Bharath Rupireddy wrote:
> And having a retry test case with clobber cache enabled doesn't make
> sense because all the cache entries are removed/invalidated for each
> query, but the test case covers the code on non-clobber cache
> platforms, so I would li
On Tue, May 4, 2021 at 4:12 AM Tom Lane wrote:
> The buildfarm is showing that one of these test queries is not stable
> under CLOBBER_CACHE_ALWAYS:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hyrax&dt=2021-05-01%2007%3A44%3A47
>
> of which the relevant part is:
>
> diff -U3
> /ho
Michael Paquier writes:
> On Tue, Apr 13, 2021 at 04:39:58PM +0900, Michael Paquier wrote:
>> Looks fine to me. Let's wait a bit first to see if Fujii-san has any
>> objections to this cleanup as that's his code originally, from
>> 32a9c0bd.
> And hearing nothing, done. The tests of postgres_fd
On Tue, Apr 13, 2021 at 04:39:58PM +0900, Michael Paquier wrote:
> Looks fine to me. Let's wait a bit first to see if Fujii-san has any
> objections to this cleanup as that's his code originally, from
> 32a9c0bd.
And hearing nothing, done. The tests of postgres_fdw are getting much
faster for me
On Mon, Apr 12, 2021 at 11:29:28AM +0530, Bharath Rupireddy wrote:
> I changed to 5min. If at all there's any server that would take more
> than 5min to remove a process from the system processes list, then it
> would see a warning on timeout.
Looks fine to me. Let's wait a bit first to see if Fu
On Mon, Apr 12, 2021 at 11:18 AM Michael Paquier wrote:
>
> On Fri, Apr 09, 2021 at 04:53:01PM +0530, Bharath Rupireddy wrote:
> > I feel that we can provide a high timeout value (It can be 1hr on the
> > similar lines of using pg_sleep(3600) for crash tests in
> > 013_crash_restart.pl with the as
On Fri, Apr 09, 2021 at 04:53:01PM +0530, Bharath Rupireddy wrote:
> I feel that we can provide a high timeout value (It can be 1hr on the
> similar lines of using pg_sleep(3600) for crash tests in
> 013_crash_restart.pl with the assumption that the backend running that
> command will get killed wi
On Thu, Apr 8, 2021 at 6:27 PM Bharath Rupireddy
wrote:
>
> On Thu, Apr 8, 2021 at 5:28 PM Michael Paquier wrote:
> >
> > On Thu, Apr 08, 2021 at 04:55:22PM +0530, Bharath Rupireddy wrote:
> > > With the recent commit aaf0432572 which introduced a waiting/timeout
> > > capability for pg_teriminat
On Fri, Apr 9, 2021 at 7:29 AM Michael Paquier wrote:
>
> On Fri, Apr 09, 2021 at 06:53:21AM +0530, Bharath Rupireddy wrote:
> > I didn't think of the warning cases, my bad. How about using SET
> > client_min_messages = 'ERROR'; before we call
> > pg_wait_for_backend_termination? We can only depen
At Fri, 9 Apr 2021 10:59:44 +0900, Michael Paquier wrote
in
> On Fri, Apr 09, 2021 at 06:53:21AM +0530, Bharath Rupireddy wrote:
> > I didn't think of the warning cases, my bad. How about using SET
> > client_min_messages = 'ERROR'; before we call
> > pg_wait_for_backend_termination? We can only
On Fri, Apr 09, 2021 at 06:53:21AM +0530, Bharath Rupireddy wrote:
> I didn't think of the warning cases, my bad. How about using SET
> client_min_messages = 'ERROR'; before we call
> pg_wait_for_backend_termination? We can only depend on the return
> value of pg_wait_for_backend_termination, when
On Fri, Apr 9, 2021 at 5:51 AM Michael Paquier wrote:
>
> On Thu, Apr 08, 2021 at 06:27:56PM +0530, Bharath Rupireddy wrote:
> > Agree. Please see the attached patch, I removed a fixed waiting time.
> > Instead of relying on pg_stat_activity, pg_sleep and
> > pg_stat_clear_snapshot, now it depends
On Thu, Apr 08, 2021 at 06:27:56PM +0530, Bharath Rupireddy wrote:
> Agree. Please see the attached patch, I removed a fixed waiting time.
> Instead of relying on pg_stat_activity, pg_sleep and
> pg_stat_clear_snapshot, now it depends on pg_terminate_backend and
> pg_wait_for_backend_termination. T
On Thu, Apr 8, 2021 at 5:28 PM Michael Paquier wrote:
>
> On Thu, Apr 08, 2021 at 04:55:22PM +0530, Bharath Rupireddy wrote:
> > With the recent commit aaf0432572 which introduced a waiting/timeout
> > capability for pg_teriminate_backend function, I would like to do
> > $subject. Attaching a patc
On Thu, Apr 08, 2021 at 04:55:22PM +0530, Bharath Rupireddy wrote:
> With the recent commit aaf0432572 which introduced a waiting/timeout
> capability for pg_teriminate_backend function, I would like to do
> $subject. Attaching a patch, please have a look.
+-- Terminate the remote backend having t
20 matches
Mail list logo
