On 2021/02/17 13:52, Michael Paquier wrote:
On Tue, Feb 16, 2021 at 11:47:52PM +0900, Fujii Masao wrote:
On 2021/02/16 15:50, Michael Paquier wrote:
+ /*
+* Read "writtenUpto" without holding a spinlock. So it may not be
+* consistent with other WAL receiver's shared variables prot
On Tue, Feb 16, 2021 at 11:47:52PM +0900, Fujii Masao wrote:
> On 2021/02/16 15:50, Michael Paquier wrote:
>> + /*
>> +* Read "writtenUpto" without holding a spinlock. So it may not be
>> +* consistent with other WAL receiver's shared variables protected by a
>> +* spinlock. This is O
On 2021/02/16 15:50, Michael Paquier wrote:
On Tue, Feb 16, 2021 at 12:43:42PM +0900, Fujii Masao wrote:
On 2021/02/16 6:28, Andres Freund wrote:
So what? It's just about free to initialize a spinlock, whether it's
using the fallback implementation or not. Initializing upon walsender
startup
On Tue, Feb 16, 2021 at 12:43:42PM +0900, Fujii Masao wrote:
> On 2021/02/16 6:28, Andres Freund wrote:
>> So what? It's just about free to initialize a spinlock, whether it's
>> using the fallback implementation or not. Initializing upon walsender
>> startup adds a lot of complications, because e.
On 2021/02/16 6:28, Andres Freund wrote:
Hi,
On 2021-02-15 19:45:21 +0900, Michael Paquier wrote:
On Mon, Feb 15, 2021 at 10:47:05PM +1300, Thomas Munro wrote:
Why not initialise it in WalRcvShmemInit()?
I was thinking about doing that as well, but we have no real need to
initialize this s
Hi,
On 2021-02-15 19:45:21 +0900, Michael Paquier wrote:
> On Mon, Feb 15, 2021 at 10:47:05PM +1300, Thomas Munro wrote:
> > Why not initialise it in WalRcvShmemInit()?
>
> I was thinking about doing that as well, but we have no real need to
> initialize this stuff in most cases, say standalone d
On 2021/02/15 19:45, Michael Paquier wrote:
On Mon, Feb 15, 2021 at 10:47:05PM +1300, Thomas Munro wrote:
Why not initialise it in WalRcvShmemInit()?
I was thinking about doing that as well, but we have no real need to
initialize this stuff in most cases, say standalone deployments. In
par
On Mon, Feb 15, 2021 at 10:47:05PM +1300, Thomas Munro wrote:
> Why not initialise it in WalRcvShmemInit()?
I was thinking about doing that as well, but we have no real need to
initialize this stuff in most cases, say standalone deployments. In
particular for the fallback implementation of atomic
On Mon, Feb 15, 2021 at 9:27 PM Michael Paquier wrote:
> On Thu, Feb 11, 2021 at 11:30:13PM +0900, Fujii Masao wrote:
> > Yes, so what about the attached patch?
>
> I see. So the first error triggering the spinlock error would cause
> a transaction failure because the fallback implementation of a
On Thu, Feb 11, 2021 at 11:30:13PM +0900, Fujii Masao wrote:
> Yes, so what about the attached patch?
I see. So the first error triggering the spinlock error would cause
a transaction failure because the fallback implementation of atomics
uses a spinlock for this variable, and it may not initiali
On 2021/02/11 21:55, Michael Paquier wrote:
Hi Fujii-san,
On Tue, Feb 09, 2021 at 11:17:04PM +0900, Fujii Masao wrote:
ISTM that the commit 2c8dd05d6c caused this issue. The commit changed
pg_stat_get_wal_receiver() so that it reads "writtenUpto" by using
pg_atomic_read_u64(). But since "writ
Hi Fujii-san,
On Tue, Feb 09, 2021 at 11:17:04PM +0900, Fujii Masao wrote:
> ISTM that the commit 2c8dd05d6c caused this issue. The commit changed
> pg_stat_get_wal_receiver() so that it reads "writtenUpto" by using
> pg_atomic_read_u64(). But since "writtenUpto" is initialized only when
> walrece
12 matches
Mail list logo
