agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedAn easier way to upgrade (Was: Lots 'o patches)
8+ messages / 7 participants
[nested] [flat]
* An easier way to upgrade (Was: Lots 'o patches)
@ 1998-06-02 09:22 Mattias Kregert <matti@algonet.se>
0 siblings, 3 replies; 8+ messages in thread
From: Mattias Kregert @ 1998-06-02 09:22 UTC (permalink / raw)
To: pgsql-hackers
David Gould wrote:
>
> >
> > >
> > > That is going to be difficult to do. We used to have some SQL scripts
> > > that could make the required database changes, but when system table
> > > structure changes, I can't imagine how we would migrate that without a
> > > dump/reload. I suppose we could keep the data/index files with user data,
> > > run initdb, and move the data files back, but we need the system table
> > > info reloaded into the new system tables.
> >
> > If the tuple header info doesn't change, this doesn't seem that tough.
> > Just do a dump the pg_* tables and reload them. The system tables are
> > "small" compared to the size of user data/indexes, no?
>
> I like this idea.
>
> > Or is there some extremely obvious reason that this is harder than it
> > seems?
> >
> > But then again, what are the odds that changes for a release will only
> > affect system tables so not to require a data dump? Not good I'd say.
>
> Hmmm, not bad either, especially if we are a little bit careful not to
> break existing on disk structures, or to make things downward compatible.
>
> For example, if we added a b-tree clustered index access method, this should
> not invalidate all existing tables and indexes, they just couldn't take
> advantage of it until rebuilt.
>
> On the other hand, if we decided to change to say 64 bit oids, I can see
> a reload being required.
>
> I guess that in our situation we will occassionally have changes that require
> a dump/load. But this should really only be required for the addition of a
> major feature that offers enough benifit to the user that they can see that
> it is worth the pain.
>
> Without knowing the history, the impression I have formed is that we have
> sort of assumed that each release will require a dump/load to do the upgrade.
> I would like to see us adopt a policy of trying to avoid this unless there
> is a compelling reason to make an exception.
How about making a file specifying what to do when upgrading from one
version of pg to another? Then a program, let's call it 'pgconv', would
read this file and do the conversions from the old to the new format
using pg_dump and psql and/or some other helper programs.
pgconv should be able to skip versions (upgrade from 6.2 to 6.4 for
example, skipping 6.2.1, 6.3 and 6.3.2) by simply going through all
steps from version to version.
Wouldn't this be much easier than having to follow instructions
written in HRF? Nobody could mess up their data, because the
program would always do the correct conversions.
Btw, does pg_dump quote identifiers? CREATE TABLE "table"
("int" int, "char" char) for example? I know it did not
use to, but perhaps it does now?
(Very simplified example follows):
----------------------------------
% cd /usr/src/pgsql6.4
% pgconv /usr/local/pgsql -y
-- PgConv1.0 - PostgreSQL data conversion program --
Found old version 6.3 in /usr/local/pgsql/
Convert to 6.4 (y/n)? (yes)
>> Converting 6.3->6.3.2
> Creating shadow passwords
>> Converting 6.3.2->6.3.4
> System tables converted
> Data files converted
PgConv done. Now delete the old binaries, install
the new binaries with 'make install' and make sure
you have your PATH set correctly.
Please don't forget to run 'ldconfig' after
installing the new libraries.
(pgconv.data):
--------------
#From To What to do
#
epoch 6.2 ERROR("Can not upgrade - too old version")
6.2 6.3 SQL("some-sql-commands-here")
DELETE("obsolete-file")
OLDVER_DUMPALL() # To temp file
NEWVER_LOADALL() # From temp file
6.3 6.3.2 PRINT("Creating shadow passwords")
SQL("create-pg_shadow")
SYSTEM("chmod go-rwx pg_user")
SQL("some-sql-commands")
6.3.2 6.4 SQL("some-commands")
SYSTEM("chmod some-files")
PRINT("System tables converted")
SQL("some-other-commands")
PRINT("Data files converted")
/* m */
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [HACKERS] An easier way to upgrade (Was: Lots 'o patches)
@ 1998-06-02 14:04 Goran Thyni <goran@bildbasen.se>
parent: Mattias Kregert <matti@algonet.se>
2 siblings, 1 reply; 8+ messages in thread
From: Goran Thyni @ 1998-06-02 14:04 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Mattias Kregert <matti@algonet.se>
Mattias Kregert wrote:
> How about making a file specifying what to do when upgrading from one
> version of pg to another? Then a program, let's call it 'pgconv', would
> read this file and do the conversions from the old to the new format
> using pg_dump and psql and/or some other helper programs.
I think what is needed is a replication program, since pgsql uses
socket comunication it is quiet easy to run 2 concurrent systems
say one each of 6.3.2 and 6.4 and copy beteewn them at run-time.
The easiest way would be to use dump&load but as David pointed out in
a case where dump&load takes 20 hours it means 20 hours downtime unless
we want inconsistent data (data inserted/updated while copying).
A smarter replication would make the downtime shorter since most data
would be upto date and only latest changes need to be transfer during
"update downtime".
Such a mechanism would be even more useful for other proposes like
clustering/backup/redundancy etc.
Has anyone looked as this?
The only thing I have seen is the Mariposa project which seems to be
somewhat overkill for most applications.
--
---------------------------------------------
Göran Thyni, sysadm, JMS Bildbasen, Kiruna
Attachments:
[application/x-pkcs7-signature] smime.p7s (3.0K, ../../35740662.A12290FC@bildbasen.se/2-smime.p7s)
download
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [HACKERS] An easier way to upgrade (Was: Lots 'o patches)
@ 1998-06-02 14:11 The Hermit Hacker <scrappy@hub.org>
parent: Goran Thyni <goran@bildbasen.se>
0 siblings, 0 replies; 8+ messages in thread
From: The Hermit Hacker @ 1998-06-02 14:11 UTC (permalink / raw)
To: Goran Thyni <goran@bildbasen.se>; +Cc: pgsql-hackers; Mattias Kregert <matti@algonet.se>
On Tue, 2 Jun 1998, Goran Thyni wrote:
> Mattias Kregert wrote:
> > How about making a file specifying what to do when upgrading from one
> > version of pg to another? Then a program, let's call it 'pgconv', would
> > read this file and do the conversions from the old to the new format
> > using pg_dump and psql and/or some other helper programs.
>
> I think what is needed is a replication program, since pgsql uses
> socket comunication it is quiet easy to run 2 concurrent systems
> say one each of 6.3.2 and 6.4 and copy beteewn them at run-time.
>
> The easiest way would be to use dump&load but as David pointed out in
> a case where dump&load takes 20 hours it means 20 hours downtime unless
> we want inconsistent data (data inserted/updated while copying).
>
> A smarter replication would make the downtime shorter since most data
> would be upto date and only latest changes need to be transfer during
> "update downtime".
>
> Such a mechanism would be even more useful for other proposes like
> clustering/backup/redundancy etc.
>
> Has anyone looked as this?
> The only thing I have seen is the Mariposa project which seems to be
> somewhat overkill for most applications.
Someone had scripts for this that they were going to submit, but I
never heard further on it :(
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [HACKERS] An easier way to upgrade (Was: Lots 'o patches)
@ 1998-06-02 14:12 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Mattias Kregert <matti@algonet.se>
2 siblings, 1 reply; 8+ messages in thread
From: Thomas G. Lockhart @ 1998-06-02 14:12 UTC (permalink / raw)
To: Mattias Kregert <matti@algonet.se>; Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: pgsql-hackers
> > ... if we are a little bit careful not to
> > break existing on disk structures, or to make things downward
> > compatible.
> > For example, if we added a b-tree clustered index access method,
> > this should not invalidate all existing tables and indexes, they
> > just couldn't take advantage of it until rebuilt.
> > On the other hand, if we decided to change to say 64 bit oids, I can
> > see a reload being required.
> > I guess that in our situation we will occassionally have changes
> > that require a dump/load. But this should really only be required
> > for the addition of a major feature that offers enough benifit to
> > the user that they can see that it is worth the pain.
> > Without knowing the history, the impression I have formed is that we
> > have sort of assumed that each release will require a dump/load to
> > do the upgrade. I would like to see us adopt a policy of trying to
> > avoid this unless there is a compelling reason to make an exception.
We tried pretty hard to do this at the start of the v6.x releases, and
failed. A few of the reasons as I recall:
1) most changes/improvements involve changes to one or more system
catalogs
2) postgres does not allow updates/inserts to at least some system
catalogs (perhaps because of interactions with the compiled catalog
cache?).
3) system catalogs appear in every database directory, so all databases
would need to be upgraded
> How about making a file specifying what to do when upgrading from one
> version of pg to another? Then a program, let's call it 'pgconv',
> would read this file and do the conversions from the old to the new
> format using pg_dump and psql and/or some other helper programs.
>
> pgconv should be able to skip versions (upgrade from 6.2 to 6.4 for
> example, skipping 6.2.1, 6.3 and 6.3.2) by simply going through all
> steps from version to version.
>
> Wouldn't this be much easier than having to follow instructions
> written in HRF? Nobody could mess up their data, because the
> program would always do the correct conversions.
This will be a good bit of work, and would be nice to have but we'd
probably need a few people to take this on as a project. Right now, the
most active developers are already spending more time than they should
working on Postgres :)
I haven't been too worried about this, but then I don't run big
databases which need to be upgraded. Seems the dump/reload frees us to
make substantial improvements with each release without a huge burden of
ensuring backward compatibility. At the prices we charge, it might be a
good tradeoff for users...
> Btw, does pg_dump quote identifiers? CREATE TABLE "table"
> ("int" int, "char" char) for example? I know it did not
> use to, but perhaps it does now?
If it doesn't yet (I assume it doesn't), I'm planning on looking at it
for v6.4. Or do you want to look at it Bruce? We should be looking to
have all identifiers double-quoted, to preserve case, reserved words,
and weird characters in names.
- Tom
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [HACKERS] An easier way to upgrade (Was: Lots 'o patches)
@ 1998-06-02 17:08 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Mattias Kregert <matti@algonet.se>
2 siblings, 0 replies; 8+ messages in thread
From: Bruce Momjian @ 1998-06-02 17:08 UTC (permalink / raw)
To: Mattias Kregert <matti@algonet.se>; +Cc: pgsql-hackers
1> How about making a file specifying what to do when upgrading from one
> version of pg to another? Then a program, let's call it 'pgconv', would
> read this file and do the conversions from the old to the new format
> using pg_dump and psql and/or some other helper programs.
We already have the migration directory, but it only text, no scripts
currently. During 1.*, we did supply script for the upgrade, but the
feature changes were small.
>
> (pgconv.data):
> --------------
> #From To What to do
> #
> epoch 6.2 ERROR("Can not upgrade - too old version")
> 6.2 6.3 SQL("some-sql-commands-here")
> DELETE("obsolete-file")
> OLDVER_DUMPALL() # To temp file
> NEWVER_LOADALL() # From temp file
> 6.3 6.3.2 PRINT("Creating shadow passwords")
> SQL("create-pg_shadow")
> SYSTEM("chmod go-rwx pg_user")
> SQL("some-sql-commands")
> 6.3.2 6.4 SQL("some-commands")
> SYSTEM("chmod some-files")
> PRINT("System tables converted")
> SQL("some-other-commands")
> PRINT("Data files converted")
Interesting ideas, but in fact, all installs will probably require a new
initdb. Because of the interdependent nature of the system tables, it
is hard to make changes to them using SQL statements. What we could try
is doing a pg_dump_all -schema-only, moving all the non pg_* files to a
separate directory, running initdb, loading the pg_dumped schema, then
moving the data files back into place.
That may work. But if we change the on-disk layout of the data, like we
did when we made varchar() variable length, a dump-reload would be
required. Vadim made on-disk data improvements for many releases.
We could make it happen even for complex cases, but then we come up on
the problem of whether it is wise to allocate limited development time
to migration issues.
I think the requirement of running the new initdb, and moving the data
files back into place is our best bet.
I would be intested to see if that works. Does someone want to try
doing this with the regression test database? Do a pg_dump with data
before and after the operation, and see if it the same. This is a good
way to test pg_dump too.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [HACKERS] An easier way to upgrade (Was: Lots 'o patches)
@ 1998-06-02 17:26 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 0 replies; 8+ messages in thread
From: Bruce Momjian @ 1998-06-02 17:26 UTC (permalink / raw)
To: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; +Cc: matti@algonet.se; pgsql-hackers
> If it doesn't yet (I assume it doesn't), I'm planning on looking at it
> for v6.4. Or do you want to look at it Bruce? We should be looking to
> have all identifiers double-quoted, to preserve case, reserved words,
> and weird characters in names.
Would someone research this, and I can add it to the todo list. Never
used quoted identifiers.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 8+ messages in thread
* [PATCH 5/7] pg_xlogdump: Add NLS
@ 2016-10-15 16:00 Peter Eisentraut <peter_e@gmx.net>
0 siblings, 0 replies; 8+ messages in thread
From: Peter Eisentraut @ 2016-10-15 16:00 UTC (permalink / raw)
---
src/bin/pg_xlogdump/nls.mk | 6 ++++
src/bin/pg_xlogdump/pg_xlogdump.c | 75 ++++++++++++++++++++-------------------
2 files changed, 44 insertions(+), 37 deletions(-)
create mode 100644 src/bin/pg_xlogdump/nls.mk
diff --git a/src/bin/pg_xlogdump/nls.mk b/src/bin/pg_xlogdump/nls.mk
new file mode 100644
index 0000000..2b254c3
--- /dev/null
+++ b/src/bin/pg_xlogdump/nls.mk
@@ -0,0 +1,6 @@
+# src/bin/pg_xlogdump/nls.mk
+CATALOG_NAME = pg_xlogdump
+AVAIL_LANGUAGES =
+GETTEXT_FILES = pg_xlogdump.c
+GETTEXT_TRIGGERS = fatal_error
+GETTEXT_FLAGS = fatal_error:1:c-format
diff --git a/src/bin/pg_xlogdump/pg_xlogdump.c b/src/bin/pg_xlogdump/pg_xlogdump.c
index 7490398..d070312 100644
--- a/src/bin/pg_xlogdump/pg_xlogdump.c
+++ b/src/bin/pg_xlogdump/pg_xlogdump.c
@@ -79,9 +79,9 @@ fatal_error(const char *fmt,...)
fflush(stdout);
- fprintf(stderr, "%s: FATAL: ", progname);
+ fprintf(stderr, _("%s: FATAL: "), progname);
va_start(args, fmt);
- vfprintf(stderr, fmt, args);
+ vfprintf(stderr, _(fmt), args);
va_end(args);
fputc('\n', stderr);
@@ -670,27 +670,27 @@ XLogDumpDisplayStats(XLogDumpConfig *config, XLogDumpStats *stats)
static void
usage(void)
{
- printf("%s decodes and displays PostgreSQL transaction logs for debugging.\n\n",
+ printf(_("%s decodes and displays PostgreSQL transaction logs for debugging.\n\n"),
progname);
- printf("Usage:\n");
- printf(" %s [OPTION]... [STARTSEG [ENDSEG]] \n", progname);
- printf("\nOptions:\n");
- printf(" -b, --bkp-details output detailed information about backup blocks\n");
- printf(" -e, --end=RECPTR stop reading at log position RECPTR\n");
- printf(" -f, --follow keep retrying after reaching end of WAL\n");
- printf(" -n, --limit=N number of records to display\n");
- printf(" -p, --path=PATH directory in which to find log segment files\n");
- printf(" (default: ./pg_wal)\n");
- printf(" -r, --rmgr=RMGR only show records generated by resource manager RMGR\n");
- printf(" use --rmgr=list to list valid resource manager names\n");
- printf(" -s, --start=RECPTR start reading at log position RECPTR\n");
- printf(" -t, --timeline=TLI timeline from which to read log records\n");
- printf(" (default: 1 or the value used in STARTSEG)\n");
- printf(" -V, --version output version information, then exit\n");
- printf(" -x, --xid=XID only show records with TransactionId XID\n");
- printf(" -z, --stats[=record] show statistics instead of records\n");
- printf(" (optionally, show per-record statistics)\n");
- printf(" -?, --help show this help, then exit\n");
+ printf(_("Usage:\n"));
+ printf(_(" %s [OPTION]... [STARTSEG [ENDSEG]] \n"), progname);
+ printf(_("\nOptions:\n"));
+ printf(_(" -b, --bkp-details output detailed information about backup blocks\n"));
+ printf(_(" -e, --end=RECPTR stop reading at log position RECPTR\n"));
+ printf(_(" -f, --follow keep retrying after reaching end of WAL\n"));
+ printf(_(" -n, --limit=N number of records to display\n"));
+ printf(_(" -p, --path=PATH directory in which to find log segment files\n"
+ " (default: ./pg_wal)\n"));
+ printf(_(" -r, --rmgr=RMGR only show records generated by resource manager RMGR\n"
+ " use --rmgr=list to list valid resource manager names\n"));
+ printf(_(" -s, --start=RECPTR start reading at log position RECPTR\n"));
+ printf(_(" -t, --timeline=TLI timeline from which to read log records\n"
+ " (default: 1 or the value used in STARTSEG)\n"));
+ printf(_(" -V, --version output version information, then exit\n"));
+ printf(_(" -x, --xid=XID only show records with TransactionId XID\n"));
+ printf(_(" -z, --stats[=record] show statistics instead of records\n"
+ " (optionally, show per-record statistics)\n"));
+ printf(_(" -?, --help show this help, then exit\n"));
}
int
@@ -725,6 +725,7 @@ main(int argc, char **argv)
int option;
int optindex = 0;
+ set_pglocale_pgservice(argv[0], PG_TEXTDOMAIN("pg_xlogdump"));
progname = get_progname(argv[0]);
memset(&private, 0, sizeof(XLogDumpPrivate));
@@ -748,7 +749,7 @@ main(int argc, char **argv)
if (argc <= 1)
{
- fprintf(stderr, "%s: no arguments specified\n", progname);
+ fprintf(stderr, _("%s: no arguments specified\n"), progname);
goto bad_argument;
}
@@ -763,7 +764,7 @@ main(int argc, char **argv)
case 'e':
if (sscanf(optarg, "%X/%X", &xlogid, &xrecoff) != 2)
{
- fprintf(stderr, "%s: could not parse end log position \"%s\"\n",
+ fprintf(stderr, _("%s: could not parse end log position \"%s\"\n"),
progname, optarg);
goto bad_argument;
}
@@ -779,7 +780,7 @@ main(int argc, char **argv)
case 'n':
if (sscanf(optarg, "%d", &config.stop_after_records) != 1)
{
- fprintf(stderr, "%s: could not parse limit \"%s\"\n",
+ fprintf(stderr, _("%s: could not parse limit \"%s\"\n"),
progname, optarg);
goto bad_argument;
}
@@ -808,7 +809,7 @@ main(int argc, char **argv)
if (config.filter_by_rmgr == -1)
{
- fprintf(stderr, "%s: resource manager \"%s\" does not exist\n",
+ fprintf(stderr, _("%s: resource manager \"%s\" does not exist\n"),
progname, optarg);
goto bad_argument;
}
@@ -817,7 +818,7 @@ main(int argc, char **argv)
case 's':
if (sscanf(optarg, "%X/%X", &xlogid, &xrecoff) != 2)
{
- fprintf(stderr, "%s: could not parse start log position \"%s\"\n",
+ fprintf(stderr, _("%s: could not parse start log position \"%s\"\n"),
progname, optarg);
goto bad_argument;
}
@@ -827,7 +828,7 @@ main(int argc, char **argv)
case 't':
if (sscanf(optarg, "%d", &private.timeline) != 1)
{
- fprintf(stderr, "%s: could not parse timeline \"%s\"\n",
+ fprintf(stderr, _("%s: could not parse timeline \"%s\"\n"),
progname, optarg);
goto bad_argument;
}
@@ -839,7 +840,7 @@ main(int argc, char **argv)
case 'x':
if (sscanf(optarg, "%u", &config.filter_by_xid) != 1)
{
- fprintf(stderr, "%s: could not parse \"%s\" as a valid xid\n",
+ fprintf(stderr, _("%s: could not parse \"%s\" as a valid xid\n"),
progname, optarg);
goto bad_argument;
}
@@ -854,7 +855,7 @@ main(int argc, char **argv)
config.stats_per_record = true;
else if (strcmp(optarg, "rmgr") != 0)
{
- fprintf(stderr, "%s: unrecognised argument to --stats: %s\n",
+ fprintf(stderr, _("%s: unrecognised argument to --stats: %s\n"),
progname, optarg);
goto bad_argument;
}
@@ -868,7 +869,7 @@ main(int argc, char **argv)
if ((optind + 2) < argc)
{
fprintf(stderr,
- "%s: too many command-line arguments (first is \"%s\")\n",
+ _("%s: too many command-line arguments (first is \"%s\")\n"),
progname, argv[optind + 2]);
goto bad_argument;
}
@@ -879,7 +880,7 @@ main(int argc, char **argv)
if (!verify_directory(private.inpath))
{
fprintf(stderr,
- "%s: path \"%s\" cannot be opened: %s\n",
+ _("%s: path \"%s\" cannot be opened: %s\n"),
progname, private.inpath, strerror(errno));
goto bad_argument;
}
@@ -917,7 +918,7 @@ main(int argc, char **argv)
else if (!XLByteInSeg(private.startptr, segno))
{
fprintf(stderr,
- "%s: start log position %X/%X is not inside file \"%s\"\n",
+ _("%s: start log position %X/%X is not inside file \"%s\"\n"),
progname,
(uint32) (private.startptr >> 32),
(uint32) private.startptr,
@@ -961,7 +962,7 @@ main(int argc, char **argv)
private.endptr != (segno + 1) * XLogSegSize)
{
fprintf(stderr,
- "%s: end log position %X/%X is not inside file \"%s\"\n",
+ _("%s: end log position %X/%X is not inside file \"%s\"\n"),
progname,
(uint32) (private.endptr >> 32),
(uint32) private.endptr,
@@ -973,7 +974,7 @@ main(int argc, char **argv)
/* we don't know what to print */
if (XLogRecPtrIsInvalid(private.startptr))
{
- fprintf(stderr, "%s: no start log position given.\n", progname);
+ fprintf(stderr, _("%s: no start log position given.\n"), progname);
goto bad_argument;
}
@@ -998,7 +999,7 @@ main(int argc, char **argv)
* a segment (e.g. we were used in file mode).
*/
if (first_record != private.startptr && (private.startptr % XLogSegSize) != 0)
- printf("first record is after %X/%X, at %X/%X, skipping over %u bytes\n",
+ printf(_("first record is after %X/%X, at %X/%X, skipping over %u bytes\n"),
(uint32) (private.startptr >> 32), (uint32) private.startptr,
(uint32) (first_record >> 32), (uint32) first_record,
(uint32) (first_record - private.startptr));
@@ -1057,6 +1058,6 @@ main(int argc, char **argv)
return EXIT_SUCCESS;
bad_argument:
- fprintf(stderr, "Try \"%s --help\" for more information.\n", progname);
+ fprintf(stderr, _("Try \"%s --help\" for more information.\n"), progname);
return EXIT_FAILURE;
}
--
2.10.1
--------------F63CA2B6EA5DB9011C5FC998
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--------------F63CA2B6EA5DB9011C5FC998--
^ permalink raw reply [nested|flat] 8+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 8+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2025-11-14 16:28 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1998-06-02 09:22 An easier way to upgrade (Was: Lots 'o patches) Mattias Kregert <matti@algonet.se>
1998-06-02 14:04 ` Goran Thyni <goran@bildbasen.se>
1998-06-02 14:11 ` The Hermit Hacker <scrappy@hub.org>
1998-06-02 14:12 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-06-02 17:26 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-06-02 17:08 ` Bruce Momjian <maillist@candle.pha.pa.us>
2016-10-15 16:00 [PATCH 5/7] pg_xlogdump: Add NLS Peter Eisentraut <peter_e@gmx.net>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox