agora inbox for [email protected]
help / color / mirror / Atom feedWin32 max connections bug (causing crashes)
15+ messages / 6 participants
[nested] [flat]
* Win32 max connections bug (causing crashes)
@ 2006-08-09 23:17 Joshua D. Drake <[email protected]>
0 siblings, 2 replies; 15+ messages in thread
From: Joshua D. Drake @ 2006-08-09 23:17 UTC (permalink / raw)
To: pgsql-hackers
Hello,
I had a customer call in today they are running Win2003 with 22 gig of
ram (that may be a mistype on their end, it may be 32gigs of ram).
They cranked up their postgresql max_connections to 500.
When PostgreSQL hits above 400, it dies and I don't mean a slow crawl
type death. A death where all connections close and the database does a
rollback and restart.
I was able to reproduce with a simple pgbench on my own win32 environment.
I wasn't able to go above 300 with mine.
Any thoughts?
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Win32 max connections bug (causing crashes)
@ 2006-08-10 03:38 Joshua D. Drake <[email protected]>
parent: Joshua D. Drake <[email protected]>
1 sibling, 1 reply; 15+ messages in thread
From: Joshua D. Drake @ 2006-08-10 03:38 UTC (permalink / raw)
To: Joshua D. Drake <[email protected]>; +Cc: pgsql-hackers
Joshua D. Drake wrote:
> Hello,
>
> I had a customer call in today they are running Win2003 with 22 gig of
> ram (that may be a mistype on their end, it may be 32gigs of ram).
>
> They cranked up their postgresql max_connections to 500.
>
> When PostgreSQL hits above 400, it dies and I don't mean a slow crawl
> type death. A death where all connections close and the database does a
> rollback and restart.
>
> I was able to reproduce with a simple pgbench on my own win32 environment.
>
> I wasn't able to go above 300 with mine.
Further on this with Debug 5:
Client:
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 19299/1/0, nestlvl: 1, children: <>
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 19299/1/0, nestlvl: 1, children: <>
DEBUG: StartTransactionCommand
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 19300/1/0, nestlvl: 1, children: <>
DEBUG: ProcessUtility
DEBUG: CommitTransactionCommand
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 19300/1/0, nestlvl: 1, children: <>
Connection to database 'bench' failed.
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
jd@scratch:/usr/local/pgsql/bin$
Server to follow in next message.
Joshua D. Drake
>
> Any thoughts?
>
> Joshua D. Drake
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Win32 max connections bug (causing crashes)
@ 2006-08-10 03:40 Joshua D. Drake <[email protected]>
parent: Joshua D. Drake <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Joshua D. Drake @ 2006-08-10 03:40 UTC (permalink / raw)
To: Joshua D. Drake <[email protected]>; +Cc: pgsql-hackers
Server:
> Event Type: Information
> Event Source: PostgreSQL
> Event Category: None
> Event ID: 0
> Date: 8/9/2006
> Time: 8:36:52 PM
> User: N/A
> Computer: DAD
> Description:
> 2006-08-09 20:36:52 DEBUG: InitPostgres
>
> Event Type: Information
> Event Source: PostgreSQL
> Event Category: None
> Event ID: 0
> Date: 8/9/2006
> Time: 8:36:52 PM
> User: N/A
> Computer: DAD
> Description:
> 2006-08-09 20:36:52 DEBUG: StartTransaction
>
> Event Type: Information
> Event Source: PostgreSQL
> Event Category: None
> Event ID: 0
> Date: 8/9/2006
> Time: 8:36:52 PM
> User: N/A
> Computer: DAD
> Description:
> 2006-08-09 20:36:52 DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 19215/1/0, nestlvl: 1, children: <>
>
> Client:
>
>
> DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
> xid/subid/cid: 19299/1/0, nestlvl: 1, children: <>
> DEBUG: CommitTransaction
> DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
> xid/subid/cid: 19299/1/0, nestlvl: 1, children: <>
> DEBUG: StartTransactionCommand
> DEBUG: StartTransaction
> DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
> xid/subid/cid: 19300/1/0, nestlvl: 1, children: <>
> DEBUG: ProcessUtility
> DEBUG: CommitTransactionCommand
> DEBUG: CommitTransaction
> DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
> xid/subid/cid: 19300/1/0, nestlvl: 1, children: <>
> Connection to database 'bench' failed.
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> jd@scratch:/usr/local/pgsql/bin$
>
>
> Server to follow in next message.
>
> Joshua D. Drake
>
>
>
>
>
>
>
>
>>
>> Any thoughts?
>>
>> Joshua D. Drake
>>
>
>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Win32 max connections bug (causing crashes)
@ 2006-08-10 14:55 Merlin Moncure <[email protected]>
parent: Joshua D. Drake <[email protected]>
0 siblings, 2 replies; 15+ messages in thread
From: Merlin Moncure @ 2006-08-10 14:55 UTC (permalink / raw)
To: Joshua D. Drake <[email protected]>; +Cc: pgsql-hackers
what version postgresql?
merlin
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Win32 max connections bug (causing crashes)
@ 2006-08-10 15:14 Merlin Moncure <[email protected]>
parent: Merlin Moncure <[email protected]>
1 sibling, 1 reply; 15+ messages in thread
From: Merlin Moncure @ 2006-08-10 15:14 UTC (permalink / raw)
To: Joshua D. Drake <[email protected]>; +Cc: pgsql-hackers
I confirmed the problem on a fairly recent 8.2devel
merlin
On 8/10/06, Merlin Moncure <[email protected]> wrote:
> what version postgresql?
>
> merlin
>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Win32 max connections bug (causing crashes)
@ 2006-08-10 15:53 William ZHANG <[email protected]>
parent: Merlin Moncure <[email protected]>
0 siblings, 2 replies; 15+ messages in thread
From: William ZHANG @ 2006-08-10 15:53 UTC (permalink / raw)
To: pgsql-hackers
Maybe this article can help:
Windows and the ClearCase process limit: Understanding the desktop heap
http://www-128.ibm.com/developerworks/rational/library/05/1220_marechal/
""Merlin Moncure"" [email protected]
>I confirmed the problem on a fairly recent 8.2devel
>
> merlin
>
> On 8/10/06, Merlin Moncure <[email protected]> wrote:
>> what version postgresql?
>>
>> merlin
>>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Win32 max connections bug (causing crashes)
@ 2006-08-10 16:10 Tom Lane <[email protected]>
parent: William ZHANG <[email protected]>
1 sibling, 1 reply; 15+ messages in thread
From: Tom Lane @ 2006-08-10 16:10 UTC (permalink / raw)
To: William ZHANG <[email protected]>; +Cc: pgsql-hackers
"William ZHANG" <[email protected]> writes:
> Maybe this article can help:
> Windows and the ClearCase process limit: Understanding the desktop heap
> http://www-128.ibm.com/developerworks/rational/library/05/1220_marechal/
So the short answer is "get a real operating system"?
I'm not sure I believe that article though, since it claims that the
default maximum number of noninteractive processes is only 79.
I thought from what was said upthread that we could get up to a couple
hundred before seeing a problem.
regards, tom lane
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Win32 max connections bug (causing crashes)
@ 2006-08-10 16:11 Merlin Moncure <[email protected]>
parent: William ZHANG <[email protected]>
1 sibling, 1 reply; 15+ messages in thread
From: Merlin Moncure @ 2006-08-10 16:11 UTC (permalink / raw)
To: William ZHANG <[email protected]>; Joshua D. Drake <[email protected]>; +Cc: pgsql-hackers
On 8/10/06, William ZHANG <[email protected]> wrote:
> Maybe this article can help:
>
> Windows and the ClearCase process limit: Understanding the desktop heap
> http://www-128.ibm.com/developerworks/rational/library/05/1220_marechal/
>
i doubled all my heap settings and was able to roughly double the -c
on pgbench from ~158 (stock) to ~330 (modified). so this is
definately the problem.
windows. meh :)
merlin
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Win32 max connections bug (causing crashes)
@ 2006-08-10 16:25 Merlin Moncure <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Merlin Moncure @ 2006-08-10 16:25 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: William ZHANG <[email protected]>; pgsql-hackers
On 8/10/06, Tom Lane <[email protected]> wrote:
> "William ZHANG" <[email protected]> writes:
> > Maybe this article can help:
> > Windows and the ClearCase process limit: Understanding the desktop heap
> > http://www-128.ibm.com/developerworks/rational/library/05/1220_marechal/
>
> So the short answer is "get a real operating system"?
changing a registry setting is not terrible in and of itself, akin to
manually manipluating procfs, but the behavior is in a failure
condition is. other than that, no comment. personally all my servers
are running mixture of gentoo and centos and i'm moving my desktop to
mac os x.
> I'm not sure I believe that article though, since it claims that the
> default maximum number of noninteractive processes is only 79.
> I thought from what was said upthread that we could get up to a couple
> hundred before seeing a problem.
that would depend on various factors, especially exactly how many
resources the ibm server software ate up for each connection. pg seems
to be leaner and meaner fwiw. anyways, i confirmed the fix.
merlin
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Win32 max connections bug (causing crashes)
@ 2006-08-10 16:40 Tom Lane <[email protected]>
parent: Merlin Moncure <[email protected]>
0 siblings, 0 replies; 15+ messages in thread
From: Tom Lane @ 2006-08-10 16:40 UTC (permalink / raw)
To: Merlin Moncure <[email protected]>; +Cc: William ZHANG <[email protected]>; pgsql-hackers
"Merlin Moncure" <[email protected]> writes:
> On 8/10/06, Tom Lane <[email protected]> wrote:
>> So the short answer is "get a real operating system"?
> changing a registry setting is not terrible in and of itself, akin to
> manually manipluating procfs, but the behavior is in a failure
> condition is. other than that, no comment.
Right. Nothing wrong with having an upper limit on how many processes
you can run, but reaching the limit should result in "fork failed"
(or local equivalent), not crashes.
Actually ... have any of the win32 hackers tested our win32 code path
that's equivalent to Unix fork failure? Maybe this is just a
garden-variety bug in our own code.
regards, tom lane
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Win32 max connections bug (causing crashes)
@ 2006-08-10 19:47 Joshua D. Drake <[email protected]>
parent: Merlin Moncure <[email protected]>
1 sibling, 0 replies; 15+ messages in thread
From: Joshua D. Drake @ 2006-08-10 19:47 UTC (permalink / raw)
To: Merlin Moncure <[email protected]>; +Cc: pgsql-hackers
Merlin Moncure wrote:
> what version postgresql?
8.1.4
>
> merlin
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Win32 max connections bug (causing crashes)
@ 2006-08-18 08:23 Magnus Hagander <[email protected]>
parent: Joshua D. Drake <[email protected]>
1 sibling, 0 replies; 15+ messages in thread
From: Magnus Hagander @ 2006-08-18 08:23 UTC (permalink / raw)
To: Joshua D. Drake <[email protected]>; pgsql-hackers
> Hello,
>
> I had a customer call in today they are running Win2003 with 22 gig
> of ram (that may be a mistype on their end, it may be 32gigs of
> ram).
>
> They cranked up their postgresql max_connections to 500.
>
> When PostgreSQL hits above 400, it dies and I don't mean a slow
> crawl type death. A death where all connections close and the
> database does a rollback and restart.
>
> I was able to reproduce with a simple pgbench on my own win32
> environment.
>
> I wasn't able to go above 300 with mine.
>
> Any thoughts?
A followup question - does this happen both when the server is started
as a service and when it's started manually? Any difference in when it
dies?
//Magnus
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Win32 max connections bug (causing crashes)
@ 2006-08-18 10:46 Magnus Hagander <[email protected]>
parent: Merlin Moncure <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Magnus Hagander @ 2006-08-18 10:46 UTC (permalink / raw)
To: Merlin Moncure <[email protected]>; William ZHANG <[email protected]>; Joshua D. Drake <[email protected]>; +Cc: pgsql-hackers
> > Maybe this article can help:
> >
> > Windows and the ClearCase process limit: Understanding the
> desktop
> > heap
> > http://www-
> 128.ibm.com/developerworks/rational/library/05/1220_marecha
> > l/
> >
>
> i doubled all my heap settings and was able to roughly double the -
> c
> on pgbench from ~158 (stock) to ~330 (modified). so this is
> definately the problem.
If you try decreasing max_files_per_process to a significantly lower
value (say, try 100 instead of 1000), does the number of processes you
can run change noticeably?
(I don't have a box around ATM that I can try to reproduce on. Will try
to set up a VM for it soon.)
//Magnus
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Win32 max connections bug (causing crashes)
@ 2006-08-23 17:33 Merlin Moncure <[email protected]>
parent: Magnus Hagander <[email protected]>
0 siblings, 0 replies; 15+ messages in thread
From: Merlin Moncure @ 2006-08-23 17:33 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: William ZHANG <[email protected]>; Joshua D. Drake <[email protected]>; pgsql-hackers
On 8/18/06, Magnus Hagander <[email protected]> wrote:
> > i doubled all my heap settings and was able to roughly double the -
> > c
> > on pgbench from ~158 (stock) to ~330 (modified). so this is
> > definately the problem.
>
> If you try decreasing max_files_per_process to a significantly lower
> value (say, try 100 instead of 1000), does the number of processes you
> can run change noticeably?
>
> (I don't have a box around ATM that I can try to reproduce on. Will try
> to set up a VM for it soon.)
per Magnus's request, I set my machine to 25 max_files (the minimum)
and saw no appreciable gain in the number of connections requred to
make it crash (I tested at 400). The first time I ran it I almost
hosed my machine...it was doing all kinds of irrational beeping and
all the windows were flickering and blinking. It did not do this
following the max_file reduction, although I have no desire to run
this test again on my development box ;)
merlin
^ permalink raw reply [nested|flat] 15+ messages in thread
* [PATCH v55 1/2] Rename cluster.c/h -> repack.c/h
@ 2026-03-31 16:55 Álvaro Herrera <[email protected]>
0 siblings, 0 replies; 15+ messages in thread
From: Álvaro Herrera @ 2026-03-31 16:55 UTC (permalink / raw)
---
src/backend/commands/Makefile | 2 +-
src/backend/commands/matview.c | 2 +-
src/backend/commands/meson.build | 2 +-
src/backend/commands/{cluster.c => repack.c} | 6 +++---
src/backend/commands/tablecmds.c | 2 +-
src/backend/commands/vacuum.c | 6 +++---
src/backend/storage/ipc/procsignal.c | 1 +
src/backend/tcop/postgres.c | 1 +
src/backend/tcop/utility.c | 2 +-
src/include/commands/{cluster.h => repack.h} | 12 ++++++------
10 files changed, 19 insertions(+), 17 deletions(-)
rename src/backend/commands/{cluster.c => repack.c} (99%)
rename src/include/commands/{cluster.h => repack.h} (90%)
diff --git a/src/backend/commands/Makefile b/src/backend/commands/Makefile
index c10fdba2bbb..fe1bba3a9b9 100644
--- a/src/backend/commands/Makefile
+++ b/src/backend/commands/Makefile
@@ -18,7 +18,6 @@ OBJS = \
amcmds.o \
analyze.o \
async.o \
- cluster.o \
collationcmds.o \
comment.o \
constraint.o \
@@ -51,6 +50,7 @@ OBJS = \
proclang.o \
propgraphcmds.o \
publicationcmds.o \
+ repack.o \
schemacmds.o \
seclabel.o \
sequence.o \
diff --git a/src/backend/commands/matview.c b/src/backend/commands/matview.c
index d3be8939011..5db4fe75dce 100644
--- a/src/backend/commands/matview.c
+++ b/src/backend/commands/matview.c
@@ -24,8 +24,8 @@
#include "catalog/namespace.h"
#include "catalog/pg_am.h"
#include "catalog/pg_opclass.h"
-#include "commands/cluster.h"
#include "commands/matview.h"
+#include "commands/repack.h"
#include "commands/tablecmds.h"
#include "commands/tablespace.h"
#include "executor/executor.h"
diff --git a/src/backend/commands/meson.build b/src/backend/commands/meson.build
index 90c7e37a429..f624aae74af 100644
--- a/src/backend/commands/meson.build
+++ b/src/backend/commands/meson.build
@@ -6,7 +6,6 @@ backend_sources += files(
'amcmds.c',
'analyze.c',
'async.c',
- 'cluster.c',
'collationcmds.c',
'comment.c',
'constraint.c',
@@ -39,6 +38,7 @@ backend_sources += files(
'proclang.c',
'propgraphcmds.c',
'publicationcmds.c',
+ 'repack.c',
'schemacmds.c',
'seclabel.c',
'sequence.c',
diff --git a/src/backend/commands/cluster.c b/src/backend/commands/repack.c
similarity index 99%
rename from src/backend/commands/cluster.c
rename to src/backend/commands/repack.c
index f241e18b153..20f0a572236 100644
--- a/src/backend/commands/cluster.c
+++ b/src/backend/commands/repack.c
@@ -1,6 +1,6 @@
/*-------------------------------------------------------------------------
*
- * cluster.c
+ * repack.c
* REPACK a table; formerly known as CLUSTER. VACUUM FULL also uses
* parts of this code.
*
@@ -10,7 +10,7 @@
*
*
* IDENTIFICATION
- * src/backend/commands/cluster.c
+ * src/backend/commands/repack.c
*
*-------------------------------------------------------------------------
*/
@@ -33,9 +33,9 @@
#include "catalog/pg_am.h"
#include "catalog/pg_inherits.h"
#include "catalog/toasting.h"
-#include "commands/cluster.h"
#include "commands/defrem.h"
#include "commands/progress.h"
+#include "commands/repack.h"
#include "commands/tablecmds.h"
#include "commands/vacuum.h"
#include "miscadmin.h"
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 0ce2e81f9c2..e2882a50b3b 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -57,10 +57,10 @@
#include "catalog/storage.h"
#include "catalog/storage_xlog.h"
#include "catalog/toasting.h"
-#include "commands/cluster.h"
#include "commands/comment.h"
#include "commands/defrem.h"
#include "commands/event_trigger.h"
+#include "commands/repack.h"
#include "commands/sequence.h"
#include "commands/tablecmds.h"
#include "commands/tablespace.h"
diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index 0ed363d1c85..b179b62b5c8 100644
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -9,7 +9,7 @@
*
* VACUUM for heap AM is implemented in vacuumlazy.c, parallel vacuum in
* vacuumparallel.c, ANALYZE in analyze.c, and VACUUM FULL is a variant of
- * CLUSTER, handled in cluster.c.
+ * REPACK, handled in repack.c.
*
*
* Portions Copyright (c) 1996-2026, PostgreSQL Global Development Group
@@ -38,9 +38,9 @@
#include "catalog/pg_database.h"
#include "catalog/pg_inherits.h"
#include "commands/async.h"
-#include "commands/cluster.h"
#include "commands/defrem.h"
#include "commands/progress.h"
+#include "commands/repack.h"
#include "commands/vacuum.h"
#include "miscadmin.h"
#include "nodes/makefuncs.h"
@@ -2293,7 +2293,7 @@ vacuum_rel(Oid relid, RangeVar *relation, VacuumParams params,
if ((params.options & VACOPT_VERBOSE) != 0)
cluster_params.options |= CLUOPT_VERBOSE;
- /* VACUUM FULL is a variant of REPACK; see cluster.c */
+ /* VACUUM FULL is a variant of REPACK; see repack.c */
cluster_rel(REPACK_COMMAND_VACUUMFULL, rel, InvalidOid,
&cluster_params);
/* cluster_rel closes the relation, but keeps lock */
diff --git a/src/backend/storage/ipc/procsignal.c b/src/backend/storage/ipc/procsignal.c
index f1ab3aa3fe0..02d28df1c6a 100644
--- a/src/backend/storage/ipc/procsignal.c
+++ b/src/backend/storage/ipc/procsignal.c
@@ -19,6 +19,7 @@
#include "access/parallel.h"
#include "commands/async.h"
+#include "commands/repack.h"
#include "miscadmin.h"
#include "pgstat.h"
#include "port/pg_bitutils.h"
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index 10be60011ad..9fbaa5c00f0 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -39,6 +39,7 @@
#include "commands/event_trigger.h"
#include "commands/explain_state.h"
#include "commands/prepare.h"
+#include "commands/repack.h"
#include "common/pg_prng.h"
#include "jit/jit.h"
#include "libpq/libpq.h"
diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
index 2b609bfc824..5f8c766c4be 100644
--- a/src/backend/tcop/utility.c
+++ b/src/backend/tcop/utility.c
@@ -26,7 +26,6 @@
#include "catalog/toasting.h"
#include "commands/alter.h"
#include "commands/async.h"
-#include "commands/cluster.h"
#include "commands/collationcmds.h"
#include "commands/comment.h"
#include "commands/conversioncmds.h"
@@ -46,6 +45,7 @@
#include "commands/proclang.h"
#include "commands/propgraphcmds.h"
#include "commands/publicationcmds.h"
+#include "commands/repack.h"
#include "commands/schemacmds.h"
#include "commands/seclabel.h"
#include "commands/sequence.h"
diff --git a/src/include/commands/cluster.h b/src/include/commands/repack.h
similarity index 90%
rename from src/include/commands/cluster.h
rename to src/include/commands/repack.h
index d6b62c747e8..85061158b0c 100644
--- a/src/include/commands/cluster.h
+++ b/src/include/commands/repack.h
@@ -1,17 +1,17 @@
/*-------------------------------------------------------------------------
*
- * cluster.h
- * header file for postgres cluster command stuff
+ * repack.h
+ * header file for the REPACK command
*
* Portions Copyright (c) 1996-2026, PostgreSQL Global Development Group
* Portions Copyright (c) 1994-5, Regents of the University of California
*
- * src/include/commands/cluster.h
+ * src/include/commands/repack.h
*
*-------------------------------------------------------------------------
*/
-#ifndef CLUSTER_H
-#define CLUSTER_H
+#ifndef REPACK_H
+#define REPACK_H
#include "nodes/parsenodes.h"
#include "parser/parse_node.h"
@@ -52,4 +52,4 @@ extern void finish_heap_swap(Oid OIDOldHeap, Oid OIDNewHeap,
MultiXactId cutoffMulti,
char newrelpersistence);
-#endif /* CLUSTER_H */
+#endif /* REPACK_H */
--
2.47.3
--k3knmf76cw7vbhar
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v55-0002-Add-CONCURRENTLY-option-to-REPACK-command.patch"
^ permalink raw reply [nested|flat] 15+ messages in thread
end of thread, other threads:[~2026-03-31 16:55 UTC | newest]
Thread overview: 15+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-08-09 23:17 Win32 max connections bug (causing crashes) Joshua D. Drake <[email protected]>
2006-08-10 03:38 ` Joshua D. Drake <[email protected]>
2006-08-10 03:40 ` Joshua D. Drake <[email protected]>
2006-08-10 14:55 ` Merlin Moncure <[email protected]>
2006-08-10 15:14 ` Merlin Moncure <[email protected]>
2006-08-10 15:53 ` William ZHANG <[email protected]>
2006-08-10 16:10 ` Tom Lane <[email protected]>
2006-08-10 16:25 ` Merlin Moncure <[email protected]>
2006-08-10 16:40 ` Tom Lane <[email protected]>
2006-08-10 16:11 ` Merlin Moncure <[email protected]>
2006-08-18 10:46 ` Magnus Hagander <[email protected]>
2006-08-23 17:33 ` Merlin Moncure <[email protected]>
2006-08-10 19:47 ` Joshua D. Drake <[email protected]>
2006-08-18 08:23 ` Magnus Hagander <[email protected]>
2026-03-31 16:55 [PATCH v55 1/2] Rename cluster.c/h -> repack.c/h Álvaro Herrera <[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