On 4/12/24 12:15, Robert Haas wrote:
On Thu, Apr 11, 2024 at 5:48 PM David Steele wrote:
But they'll try because it is a new pg_basebackup feature and they'll
assume it is there to be used. Maybe it would be a good idea to make it
clear in the documentation that significant tooling will be r
I wrote:
> ... But Robert's question remains: how does
> PANIC'ing after awhile make anything better? I flat out don't
> believe the idea that having a backend stuck on a spinlock
> would otherwise go undetected.
Oh, wait. After thinking a bit longer I believe I recall the argument
for this beha
On Sun, Apr 7, 2024 at 10:42 PM Tomas Vondra
wrote:
> create table t (a int, b int) with (fillfactor=10);
> insert into t select mod((i/22),2), (i/22) from generate_series(0,1000)
> S(i);
> create index on t(a);
> vacuum analyze t;
>
> set enable_indexonlyscan = off;
> set enable_seqscan = off;
>
jian he 于2024年4月12日周五 10:12写道：
> On Thu, Apr 11, 2024 at 10:48 PM Alvaro Herrera
> wrote:
> >
> >
> > I'm still not ready with this -- still not convinced about the new AT
> > pass. Also, I want to add a test for the pg_dump behavior, and there's
> > an XXX comment.
> >
> Now I am more confused
On Thu, Apr 11, 2024 at 5:04 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Thursday, April 11, 2024 12:11 PM Amit Kapila
> wrote:
>
> >
> > 2.
> > - if (remote_slot->restart_lsn < slot->data.restart_lsn)
> > + if (remote_slot->confirmed_lsn < slot->data.confirmed_flush)
> > elog(ERROR,
> > "cannot s
Hi,
On 2024-04-11 23:15:38 -0400, Tom Lane wrote:
> I wrote:
> > ... But Robert's question remains: how does
> > PANIC'ing after awhile make anything better? I flat out don't
> > believe the idea that having a backend stuck on a spinlock
> > would otherwise go undetected.
>
> Oh, wait. After th
Andres Freund writes:
> On 2024-04-11 23:15:38 -0400, Tom Lane wrote:
>> On the third hand, it's still true that we have no comparable
>> behavior for any other source of system lockups, and it's difficult
>> to make a case that stuck spinlocks really need more concern than
>> other kinds of bugs.
(moved to a new thread)
On Thu, Mar 21, 2024 at 04:31:45PM -0400, Tom Lane wrote:
> I wrote:
>> ... I still see the problematic GRANT taking ~250ms, compared
>> to 5ms in v15. roles_is_member_of is clearly on the hook for that.
>
> Ah: looks like that is mainly the fault of the list_append_uniqu
Hi,
On 2024-04-11 20:47:37 -0700, Andres Freund wrote:
> > So there's that. But that's not an argument that we need to be in a
> > hurry to timeout; if the built-in reaction time is less than perhaps
> > 10 minutes you're still miles ahead of the manual solution.
>
> The current timeout is of a
Hi Andres,
12.04.2024 07:41, Andres Freund wrote:
FWIW, I just reproduced the scenario with signals. I added tracking of the
total time actually slept and lost to SpinDelayStatus, and added a function to
trigger a wait on a spinlock.
To wait less, I set max_standby_streaming_delay=0.1, but tha
On 4/12/24 06:44, Tom Lane wrote:
If this patch were producing better results I'd be more excited
about putting more work into it. But on the basis of what I'm
seeing right now, I think maybe we ought to give up on it.
First, thanks for the deep review - sometimes, only a commit gives us a
chan
Hi,
On 2024-04-11 21:41:39 -0700, Andres Freund wrote:
> FWIW, I just reproduced the scenario with signals. I added tracking of the
> total time actually slept and lost to SpinDelayStatus, and added a function to
> trigger a wait on a spinlock.
>
> To wait less, I set max_standby_streaming_delay=0
Alvaro Herrera 于2024年4月11日周四 22:48写道：
> On 2024-Apr-11, Alvaro Herrera wrote:
>
> > Well, I think you were right that we should try to handle the situation
> > of unmarking attnotnull as much as possible, to decrease the chances
> > that the problematic situation occurs. That means, we can use t
On 4/11/24 20:26, Tomas Vondra wrote:
On 4/11/24 03:52, David Steele wrote:
On 4/11/24 10:23, Tom Kincaid wrote:
The extensive Beta process we have can be used to build confidence we
need in a feature that has extensive review and currently has no known
issues or outstanding objections.
I di
101 - 114 of 114 matches
Mail list logo
