public inbox for [email protected]
help / color / mirror / Atom feed[PATCH] Remove PROC_IN_ANALYZE
3+ messages / 3 participants
[nested] [flat]
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Replacing abort() with __builtin_trap()?
@ 2023-07-02 18:09 Andres Freund <[email protected]>
2023-07-02 21:50 ` Re: Replacing abort() with __builtin_trap()? Tom Lane <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Andres Freund @ 2023-07-02 18:09 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-hackers
Hi,
On 2023-07-02 13:55:53 -0400, Tom Lane wrote:
> Andres Freund <[email protected]> writes:
> > I'd like to propose that we do a configure test for __builtin_trap() and use
> > it, if available, before the abort() in ExceptionalCondition(). Perhaps also
> > for PANIC, but it's not as clear to me whether we should.
>
> Does that still result in the same process exit signal being reported to
> the postmaster?
It does not on linux / x86-64.
2023-07-02 10:52:55.103 PDT [1398197][postmaster][:0][] LOG: server process (PID 1398207) was terminated by signal 4: Illegal instruction
vs today's
2023-07-02 11:08:22.674 PDT [1401801][postmaster][:0][] LOG: server process (PID 1401809) was terminated by signal 6: Aborted
It wouldn't be bad for postmaster to be able to distinguish between PANIC and
Assert(), but I agree that the non-determinism is a bit annoying.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Replacing abort() with __builtin_trap()?
2023-07-02 18:09 Re: Replacing abort() with __builtin_trap()? Andres Freund <[email protected]>
@ 2023-07-02 21:50 ` Tom Lane <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Tom Lane @ 2023-07-02 21:50 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: pgsql-hackers
Andres Freund <[email protected]> writes:
> On 2023-07-02 13:55:53 -0400, Tom Lane wrote:
>> Andres Freund <[email protected]> writes:
>>> I'd like to propose that we do a configure test for __builtin_trap() and use
>>> it, if available, before the abort() in ExceptionalCondition(). Perhaps also
>>> for PANIC, but it's not as clear to me whether we should.
>> Does that still result in the same process exit signal being reported to
>> the postmaster?
> It does not on linux / x86-64.
> 2023-07-02 10:52:55.103 PDT [1398197][postmaster][:0][] LOG: server process (PID 1398207) was terminated by signal 4: Illegal instruction
> vs today's
> 2023-07-02 11:08:22.674 PDT [1401801][postmaster][:0][] LOG: server process (PID 1401809) was terminated by signal 6: Aborted
Hm, I do *not* like "Illegal instruction" in place of SIGABRT;
that looks too much like we vectored off into never-never land.
I'd rather live with the admittedly-ugly stack traces.
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2023-07-02 21:50 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2023-07-02 18:09 Re: Replacing abort() with __builtin_trap()? Andres Freund <[email protected]>
2023-07-02 21:50 ` Re: Replacing abort() with __builtin_trap()? Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox