On Thu, Aug 12, 2021 at 6:24 PM Andres Freund wrote:
>
> On 2021-08-12 05:48:19 -0700, Andres Freund wrote:
> > I think SharedFileSetInit() needs a comment explaining that it needs to be
> > called in a process-lifetime memory context if used without dsm
> > segments. Because otherwise SharedFileS
On Thu, Aug 12, 2021 at 6:18 PM Andres Freund wrote:
>
> Hi,
>
> On 2021-08-12 15:06:23 +0530, Amit Kapila wrote:
> > On Thu, Aug 12, 2021 at 1:52 PM Andres Freund wrote:
> > > I'm not so sure. Why does sharedfileset have its own proc exit hook in the
> > > first place? ISTM that this should be d
Hi,
On 2021-08-12 05:48:19 -0700, Andres Freund wrote:
> I think SharedFileSetInit() needs a comment explaining that it needs to be
> called in a process-lifetime memory context if used without dsm
> segments. Because otherwise SharedFileSetDeleteOnProcExit() will access
> already freed memory (bo
Hi,
On 2021-08-12 15:06:23 +0530, Amit Kapila wrote:
> On Thu, Aug 12, 2021 at 1:52 PM Andres Freund wrote:
> > I'm not so sure. Why does sharedfileset have its own proc exit hook in the
> > first place? ISTM that this should be dealt with using resowners, rathers
> > than
> > a sharedfileset sp
On Thu, Aug 12, 2021 at 1:52 PM Andres Freund wrote:
>
> On 2021-08-12 11:46:09 +0530, Amit Kapila wrote:
> > On Thu, Aug 12, 2021 at 11:38 AM Dilip Kumar wrote:
> > > On Thu, Aug 12, 2021 at 7:39 AM Masahiko Sawada
> > > wrote:
> > > > It seems to me that moving the shared fileset cleanup to
>
Hi,
On 2021-08-12 11:46:09 +0530, Amit Kapila wrote:
> On Thu, Aug 12, 2021 at 11:38 AM Dilip Kumar wrote:
> > On Thu, Aug 12, 2021 at 7:39 AM Masahiko Sawada
> > wrote:
> > > It seems to me that moving the shared fileset cleanup to
> > > before_shmem_exit() is the right approach to fix this pr
On Thu, Aug 12, 2021 at 1:13 PM Masahiko Sawada wrote:
>
> On Thu, Aug 12, 2021 at 3:16 PM Amit Kapila wrote:
> >
> >
> > I have also tested and fix works for me. The fix works because
> > pgstat_initialize() is called before we register clean up in
> > SharedFileSetInit(). I am not sure if we ne
On Thu, Aug 12, 2021 at 1:13 PM Masahiko Sawada wrote:
>
> On Thu, Aug 12, 2021 at 3:16 PM Amit Kapila wrote:
> >
> > On Thu, Aug 12, 2021 at 11:38 AM Dilip Kumar wrote:
> > >
> > > On Thu, Aug 12, 2021 at 7:39 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Wed, Aug 11, 2021 at 10:47 PM Am
On Thu, Aug 12, 2021 at 3:16 PM Amit Kapila wrote:
>
> On Thu, Aug 12, 2021 at 11:38 AM Dilip Kumar wrote:
> >
> > On Thu, Aug 12, 2021 at 7:39 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Aug 11, 2021 at 10:47 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Tue, Aug 10, 2021 at 4:37 PM M
On Thu, Aug 12, 2021 at 11:38 AM Dilip Kumar wrote:
>
> On Thu, Aug 12, 2021 at 7:39 AM Masahiko Sawada wrote:
> >
> > On Wed, Aug 11, 2021 at 10:47 PM Amit Kapila
> > wrote:
> > >
> > > On Tue, Aug 10, 2021 at 4:37 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > The apply worker registers Sh
On Thu, Aug 12, 2021 at 7:39 AM Masahiko Sawada wrote:
>
> On Wed, Aug 11, 2021 at 10:47 PM Amit Kapila wrote:
> >
> > On Tue, Aug 10, 2021 at 4:37 PM Masahiko Sawada
> > wrote:
> > >
> > > The apply worker registers SharedFileSetDeleteOnProcExit() when
> > > creating a file set to serialize th
On Wed, Aug 11, 2021 at 10:47 PM Amit Kapila wrote:
>
> On Tue, Aug 10, 2021 at 4:37 PM Masahiko Sawada wrote:
> >
> > The apply worker registers SharedFileSetDeleteOnProcExit() when
> > creating a file set to serialize the changes. When it raises an error
> > due to conflict during applying the
On Tue, Aug 10, 2021 at 4:37 PM Masahiko Sawada wrote:
>
> The apply worker registers SharedFileSetDeleteOnProcExit() when
> creating a file set to serialize the changes. When it raises an error
> due to conflict during applying the change, the callback eventually
> reports the temp file statistic
Hi,
On Sun, Aug 8, 2021 at 11:24 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-08-07 12:01:31 -0700, Andres Freund wrote:
> > Attached is a patch showing how this could look like. Note that the PANIC
> > should likely not be that but a WARNING, but the PANIC more useful for
> > running
> > some in
Hi,
On 2021-08-09 11:46:30 -0400, Robert Haas wrote:
> I think that subsystems like "memory" and "files" really ought to be
> the lowest-level things we have, and should be shut down last.
I don't disagree with that - but there's a difference between having that as
an abstract goal, and having it
On Sat, Aug 7, 2021 at 11:43 AM Tom Lane wrote:
> Intuitively it seems like temp file management should be a low-level,
> backend-local function and therefore should be okay to run after
> shmem disconnection. I do not have a warm feeling about reversing that
> module layering --- what's to stop
Hi,
On 2021-08-07 12:01:31 -0700, Andres Freund wrote:
> Attached is a patch showing how this could look like. Note that the PANIC
> should likely not be that but a WARNING, but the PANIC more useful for running
> some initial tests...
I pushed a slightly evolved version of this. As the commit me
Hi,
On 2021-08-07 15:12:38 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2021-08-07 13:37:16 -0400, Tom Lane wrote:
> >> Depends what you want to define as a bug. What I am not happy about
> >> is the prospect of random assertion failures for the next six months
> >> while you finish red
Andres Freund writes:
> On 2021-08-07 13:37:16 -0400, Tom Lane wrote:
>> Depends what you want to define as a bug. What I am not happy about
>> is the prospect of random assertion failures for the next six months
>> while you finish redesigning half of the system. The rest of us
>> have work we
Hi,
On 2021-08-07 09:48:50 -0700, Andres Freund wrote:
> I'm somewhat inclined to split InitFileAccess() into two by separating out
> InitTemporaryFileAccess() or such. InitFileAccess() would continue to happen
> early and register a proc exit hook that errors out when there's a temp file
> (as a
Hi,
On 2021-08-07 13:37:16 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2021-08-07 13:06:47 -0400, Tom Lane wrote:
> >> Fair. But I suggest that the first cut should look more like what
> >> I suggest above, ie just be willing to lose events during shutdown.
> >> The downsides of that a
Andres Freund writes:
> On 2021-08-07 13:06:47 -0400, Tom Lane wrote:
>> Fair. But I suggest that the first cut should look more like what
>> I suggest above, ie just be willing to lose events during shutdown.
>> The downsides of that are not so enormous that we should be willing
>> to undertake
Hi,
On 2021-08-07 13:06:47 -0400, Tom Lane wrote:
> The bigger picture here is that anyplace anybody ever wants to add stats
> collection in suddenly becomes a "must run before shmem disconnection"
> module. I think that way madness lies --- we can't have the entire
> backend shut down before shm
Andres Freund writes:
> On 2021-08-07 11:43:07 -0400, Tom Lane wrote:
>> Intuitively it seems like temp file management should be a low-level,
>> backend-local function and therefore should be okay to run after
>> shmem disconnection. I do not have a warm feeling about reversing that
>> module la
Hi,
On 2021-08-07 11:43:07 -0400, Tom Lane wrote:
> So if I have the lay of the land correctly:
>
> 1. Somebody decided it'd be a great idea for temp file cleanup to send
> stats collector messages.
>
> 2. Temp file cleanup happens after shmem disconnection.
>
> 3. This accidentally worked, up
Andres Freund writes:
> On 2021-08-06 21:49:52 -0700, Andres Freund wrote:
>> Not yet really sure what the best way to deal with this is. Presumably this
>> issue would be fixed if AtProcExit_Files()/CleanupTempFiles() were scheduled
>> via before_shmem_exit(). And perhaps it's not too off to sche
Hi,
On 2021-08-06 21:49:52 -0700, Andres Freund wrote:
> The temp file is created by InitializeBackupManifest(). In the !OSX case, we
> first abort via an ERROR, which triggers the cleanup via
> WalSndResourceCleanup(). On OSX however, we immediately error out with FATAL
> for some reason (timing?
Hi,
On 2021-08-06 23:22:36 -0400, Tom Lane wrote:
> I wrote:
> > Guessing the common factor is "macOS", but that's just a guess.
> > I can poke into it tomorrow.
>
> I did try it real quick on my Mac laptop, and that fails too.
> Here's a more accurate backtrace, in case that helps.
Thanks!
I no
I wrote:
> Guessing the common factor is "macOS", but that's just a guess.
> I can poke into it tomorrow.
I did try it real quick on my Mac laptop, and that fails too.
Here's a more accurate backtrace, in case that helps.
(lldb) bt
* thread #1, stop reason = signal SIGSTOP
* frame #0: 0x7ff
Hi,
On 2021-08-06 23:13:28 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Not sure why it's your two animals that report this issue, but not others?
> > Why
> > would a backend doing SendBaseBackup() previously have allocated temp files?
>
> Guessing the common factor is "macOS", but that's
Andres Freund writes:
> Not sure why it's your two animals that report this issue, but not others? Why
> would a backend doing SendBaseBackup() previously have allocated temp files?
Guessing the common factor is "macOS", but that's just a guess.
I can poke into it tomorrow.
Hi,
On 2021-08-06 22:44:07 -0400, Tom Lane wrote:
> Andres Freund writes:
> > pgstat: Bring up pgstat in BaseInit() to fix uninitialized use of pgstat by
> > AV.
>
> sifaka took exception to this, or at least I guess it was this one out
> of the four you pushed at once:
Longfin as well. It's t
Andres Freund writes:
> pgstat: Bring up pgstat in BaseInit() to fix uninitialized use of pgstat by
> AV.
sifaka took exception to this, or at least I guess it was this one out
of the four you pushed at once:
TRAP: FailedAssertion("pgstat_is_initialized && !pgstat_is_shutdown", File:
"pgstat.c
pgstat: Bring up pgstat in BaseInit() to fix uninitialized use of pgstat by AV.
Previously pgstat_initialize() was called in InitPostgres() and
AuxiliaryProcessMain(). As it turns out there was at least one case where we
reported stats before pgstat_initialize() was called, see
AutoVacWorkerMain()
34 matches
Mail list logo
