Re: [PATCHES] add build utilities in default install
Dear patchers, > Subject: [PATCHES] add build utilities in default install I withdraw this submission, which was not yet considered for inclusion anyway. I'll send a more complete patch, which includes this one, but also provide a working infrastructure for extensions, sometimes later. I've something working that needs some finalization and tests. -- Fabien. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Tuple sampling
On Sun, 23 May 2004 17:32:36 -0400, Tom Lane <[EMAIL PROTECTED]> wrote: >I took out the TupleCount typedef and went >back to using doubles for the tuple counts; this is more consistent with >the coding style used elsewhere, and I really doubt that it's any >slower. Performance was not the primary motivation. I found it confusing to have doubles everywhere and not to know whether a variable is declared as double, because . we need the fractional part (e.g. a probability) . or it should be able to hold an integral value of more than 32 bits. So I just invented my own datatype for huge integers. Long long would have been a natural choice, but AFAIK its not available on all platforms. >I was initially convinced that your implementation of Knuth's algorithm >S was all wet, so now there's a bunch of comments explaining why it's >actually correct... Thanks. I like your explanation. My justification for that change was a lot more complicated. Servus Manfred ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Tuple sampling
Manfred Koizar <[EMAIL PROTECTED]> writes: > Performance was not the primary motivation. I found it confusing to > have doubles everywhere and not to know whether a variable is declared > as double, because > . we need the fractional part (e.g. a probability) > . or it should be able to hold an integral value of more than 32 bits. > So I just invented my own datatype for huge integers. Well, if you want to "typedef double TupleCount" as a documentation aid, I don't object, but let's not do it just locally in analyze.c. There are a bunch of other places that do the same thing. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] add build utilities in default install
Fabien COELHO wrote: > > Dear patchers, > > > Subject: [PATCHES] add build utilities in default install > > I withdraw this submission, which was not yet considered for inclusion > anyway. > > I'll send a more complete patch, which includes this one, but also provide > a working infrastructure for extensions, sometimes later. I've something > working that needs some finalization and tests. Good, I was wondering were we were on this. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] updated list rewrite
Neil Conway wrote: I've attached a new version of the list rewrite patch (gzip'ed). Changes since the last patch: I never dig on postgresql code in order to see how and where lists are used, I'm wondering if also a "rope" could be usefull somewhere. Regards Gaetano Mendola ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[PATCHES] delayed planning of unnamed statements
Per discussion on -hackers
(http://archives.postgresql.org/pgsql-hackers/2004-05/msg00990.php),
here is a first cut at delaying query planning for unnamed statements
until we have concrete parameters (i.e. at Bind).
This passes 'make check' (not particularly informative since that
doesn't exercise the extended query protocol path). It also passes the
JDBC driver's regression tests when using a modified driver that uses
the extended query protocol and parameterized queries.
Also attached is a python script that talks the V3 protocol directly and
does some simple tests of various bind/rebind cases with named and
unnamed statements (beware, that code is very ad-hoc!).
With these changes the JDBC driver gets performance similar to the
unparameterized case when using the unnamed statement:
FE=> Parse(stmt=null,query="SELECT count(*) FROM test_big WHERE value = 2",oids={})
FE=> Bind(stmt=null,portal=null)
FE=> Describe(portal=null)
FE=> Execute(portal=null,limit=0)
FE=> Sync
<=BE ParseComplete [null]
<=BE BindComplete [null]
<=BE RowDescription(1)
<=BE DataRow
<=BE CommandStatus(SELECT)
<=BE ReadyForQuery(I)
< END
Elapsed: 54ms
Result: 1
FE=> Parse(stmt=S_1,query="SELECT count(*) FROM test_big WHERE value = $1",oids={23})
FE=> Bind(stmt=S_1,portal=null,$1=<2>)
FE=> Describe(portal=null)
FE=> Execute(portal=null,limit=0)
FE=> Sync
<=BE ParseComplete [S_1]
<=BE BindComplete [null]
<=BE RowDescription(1)
<=BE DataRow
<=BE CommandStatus(SELECT)
<=BE ReadyForQuery(I)
< END
Elapsed: 1484ms
Result: 1
FE=> Parse(stmt=null,query="SELECT count(*) FROM test_big WHERE value = $1",oids={23})
FE=> Bind(stmt=null,portal=null,$1=<2>)
FE=> Describe(portal=null)
FE=> Execute(portal=null,limit=0)
FE=> Sync
<=BE ParseComplete [null]
<=BE BindComplete [null]
<=BE RowDescription(1)
<=BE DataRow
<=BE CommandStatus(SELECT)
<=BE ReadyForQuery(I)
< END
Elapsed: 65ms
Result: 1
-O
Index: doc/src/sgml/protocol.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/protocol.sgml,v
retrieving revision 1.51
diff -u -c -r1.51 protocol.sgml
*** doc/src/sgml/protocol.sgml 21 Mar 2004 22:29:10 - 1.51
--- doc/src/sgml/protocol.sgml 24 May 2004 14:42:10 -
***
*** 663,668
--- 663,688
+ Query planning of named prepared-statement objects occurs when the Parse
+ message is received. If a query will be repeatedly executed with
+ different parameters, it may be beneficial to send a single Parse message
+ containing a parameterized query, followed by multiple Bind
+ and Execute messages. This will avoid replanning the query on each
+ execution.
+
+
+
+
+ Query plans generated from a parameterized query may be less
+ efficient than query plans generated from an equivalent query with actual
+ parameter values substituted. The query planner cannot make decisions
+ based on actual parameter values (for example, index selectivity) when
+ planning a parameterized query assigned to a named prepared-statement
+ object.
+
+
+
+
Once a prepared statement exists, it can be readied for execution using a
Bind message. The Bind message gives the name of the source prepared
statement (empty string denotes the unnamed prepared statement), the name
***
*** 674,679
--- 694,720
by the query; the format can be specified overall, or per-column.
The response is either BindComplete or ErrorResponse.
+
+
+ Query planning of the unnamed prepared-statement object occurs when the
+ first Bind message after a Parse message is received. The planner will
+ consider the actual values of any parameters provided in the Bind message
+ when planning the query. A Parse followed by Bind of the unnamed
+ prepared-statement object will produce the same query plan as for the
+ equivalent unparameterized query.
+
+
+
+
+ When a second or subsequent Bind referencing the unnamed prepared-
+ statement object is received without an intervening Parse, the query is
+ not replanned. The parameter values used in the first Bind message may
+ produce a query plan that is only efficient for a subset of possible
+ parameter values. To force replanning of the query on each execution, send
+ a Parse message to replace the unnamed prepared-statement object before
+ each Bind.
+
+
Index: src/backend/commands/explain.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/commands/explain.c,v
retrieving revision 1.120
diff -u -c -r1.120 explain.c
*** src/backend/commands/explain.c 1 Apr 2004 21:28:44 - 1.120
--- src/backend/commands/explain.c 24 May 2004 14:42:10 -
***
*** 176,182
[PATCHES] contrib/dbmirror typo fix
Please apply this minor patch to the cvs HEAD of dbmirror It fixes a typo in a define Thanks -- Steven Singer [EMAIL PROTECTED] Dispatch SystemsPhone: 519-747-1170 ext 282 Navtech Systems Support Inc.AFTN: CYYZXNSX SITA: YYZNSCR Waterloo, Ontario ARINC: YKFNSCR Index: pending.c === RCS file: /projects/cvsroot/pgsql-server/contrib/dbmirror/pending.c,v retrieving revision 1.17 diff -u -r1.17 pending.c --- pending.c 22 Apr 2004 03:48:38 - 1.17 +++ pending.c 24 May 2004 16:30:38 - @@ -76,7 +76,7 @@ #else #define debug_msg2(x,y) #define debug_msg(x) -#define debug_msg(x,y,z) +#define debug_msg3(x,y,z) #endif ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Cancel/Kill backend functions
Okay, here is an updated patch. now uses IsBackendPid(), which is closely modeled (read cut-and-pasted) from TransactionIdIsInProgress(). Since it's no longer a pgstat function, I moved it to "misc.c". Not 100% that's the right place either, but it seemed like the best alternative. //Magnus >-Original Message- >From: Neil Conway [mailto:[EMAIL PROTECTED] >Sent: den 22 maj 2004 10:00 >To: Magnus Hagander >Cc: [EMAIL PROTECTED] >Subject: Re: [PATCHES] Cancel/Kill backend functions > > >Magnus Hagander wrote: >> Per previous discussions, here are two functions to send INT and TERM >> signals to other backends.They permit only INT and TERM, and permits >> sending only to postgresql backends (as registered in pgstat). > >Why does this depend on pgstat? ISTM it would be better to use the >per-backend PGPROC information, which is stored in shared memory. >Consider TransactionIdIsInProgress() for an example. > >-Neil > termbackend.patch Description: termbackend.patch ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[PATCHES] Small patch for oracle_compat.c
limits.h needed in oracle_compat.c to compile on win32. See attached patch. //Magnus <> oracle_compat.patch Description: oracle_compat.patch ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] Relocatable locale
Magnus found out that LOCALEDIR wasn't being handled in a relocatable
manner.
This patch fixes that. It also adjusts the get_*_path functions to
limit values to MAXPGPATH.
I have two questions. First, setlocale() seemed to be inconsistently
set inside and outside of ENABLE_NLS. I assume the proper location is
inside. Second, libpq has a locale setting for error messages, but a
libpq program could be in any directory, so I see no way to make that
relocatable. Instead, I just use the hardcoded path. I could make it
relocatable, but that seems to error-prone, plus I would have to look up
the exec path and stuff, and it seemed too complicated.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/backend/main/main.c
===
RCS file: /cvsroot/pgsql-server/src/backend/main/main.c,v
retrieving revision 1.81
diff -c -c -r1.81 main.c
*** src/backend/main/main.c 24 May 2004 02:47:44 - 1.81
--- src/backend/main/main.c 25 May 2004 00:54:53 -
***
*** 150,155
--- 150,157
* startup error messages to be localized.
*/
+ set_pglocale(argv[0], "postgres");
+
#ifdef WIN32
/*
* Windows uses codepages rather than the environment, so we work around
***
*** 184,194
setlocale(LC_MONETARY, "C");
setlocale(LC_NUMERIC, "C");
setlocale(LC_TIME, "C");
-
- #ifdef ENABLE_NLS
- bindtextdomain("postgres", LOCALEDIR);
- textdomain("postgres");
- #endif
/*
* Skip permission checks if we're just trying to do --help or
--- 186,191
Index: src/bin/initdb/initdb.c
===
RCS file: /cvsroot/pgsql-server/src/bin/initdb/initdb.c,v
retrieving revision 1.32
diff -c -c -r1.32 initdb.c
*** src/bin/initdb/initdb.c 18 May 2004 03:36:36 - 1.32
--- src/bin/initdb/initdb.c 25 May 2004 00:54:56 -
***
*** 167,173
static bool chklocale(const char *locale);
static void setlocales(void);
static void usage(const char *progname);
! static void init_nls(void);
/*
--- 167,173
static bool chklocale(const char *locale);
static void setlocales(void);
static void usage(const char *progname);
! static void init_nls(const char *argv0);
/*
***
*** 1754,1766
* Initialized NLS if enabled.
*/
static void
! init_nls(void)
{
! #ifdef ENABLE_NLS
! setlocale(LC_ALL, "");
! bindtextdomain("initdb", LOCALEDIR);
! textdomain("initdb");
! #endif
}
--- 1754,1762
* Initialized NLS if enabled.
*/
static void
! init_nls(const char *argv0)
{
! set_pglocale(argv0, "initdb");
}
***
*** 1801,1807
* environment */
char *subdirs[] =
{"global", "pg_xlog", "pg_clog", "base", "base/1"};
! init_nls();
progname = get_progname(argv[0]);
--- 1797,1803
* environment */
char *subdirs[] =
{"global", "pg_xlog", "pg_clog", "base", "base/1"};
! init_nls(argv[0]);
progname = get_progname(argv[0]);
Index: src/bin/pg_controldata/Makefile
===
RCS file: /cvsroot/pgsql-server/src/bin/pg_controldata/Makefile,v
retrieving revision 1.7
diff -c -c -r1.7 Makefile
*** src/bin/pg_controldata/Makefile 30 Apr 2004 20:01:39 - 1.7
--- src/bin/pg_controldata/Makefile 25 May 2004 00:54:56 -
***
*** 14,20
override CPPFLAGS += -DFRONTEND
! OBJS= pg_controldata.o pg_crc.o
all: submake-libpgport pg_controldata
--- 14,20
override CPPFLAGS += -DFRONTEND
! OBJS= pg_controldata.o pg_crc.o exec.o
all: submake-libpgport pg_controldata
***
*** 24,29
--- 24,32
pg_crc.c: $(top_srcdir)/src/backend/utils/hash/pg_crc.c
rm -f $@ && $(LN_S) $< .
+ exec.c: % : $(top_srcdir)/src/port/%
+ rm -f $@ && $(LN_S) $< .
+
install: all installdirs
$(INSTALL_PROGRAM) pg_controldata$(X) $(DESTDIR)$(bindir)/pg_controldata$(X)
***
*** 34,37
rm -f $(DESTDIR)$(bindir)/pg_controldata$(X)
clean distclean maintainer-clean:
! rm -f pg_controldata$(X) pg_controldata.o pg_crc.o pg_crc.c
--- 37,40
rm -f $(DESTDIR)$(bindir)/pg_controldata$(X)
clean distclean maintainer-clean:
! rm -f pg_controldata$(X) pg_controldata.o pg_crc.o pg_crc.c exec.c
Index: src/bin/pg_controldata/pg_controldata.c
Re: [PATCHES] Relocatable locale
Bruce Momjian <[EMAIL PROTECTED]> writes: > I have two questions. First, setlocale() seemed to be inconsistently > set inside and outside of ENABLE_NLS. I assume the proper location is > inside. Please do *not* go adding setlocale calls that were not there before. You *will* break things. > ! setlocale(LC_ALL, ""); ^ Putting this call in the backend is a very serious mistake. It might be okay in clients, but not in the backend. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Relocatable locale
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have two questions. First, setlocale() seemed to be inconsistently
> > set inside and outside of ENABLE_NLS. I assume the proper location is
> > inside.
>
> Please do *not* go adding setlocale calls that were not there before.
> You *will* break things.
>
> > ! setlocale(LC_ALL, "");
> ^
>
> Putting this call in the backend is a very serious mistake. It might be
> okay in clients, but not in the backend.
OK, patch applied. Turns out it was only added for the backend
("postgres").
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/port/path.c
===
RCS file: /cvsroot/pgsql-server/src/port/path.c,v
retrieving revision 1.12
diff -c -c -r1.12 path.c
*** src/port/path.c 25 May 2004 01:00:30 - 1.12
--- src/port/path.c 25 May 2004 01:40:36 -
***
*** 251,257
char path[MAXPGPATH];
char my_exec_path[MAXPGPATH];
! setlocale(LC_ALL, "");
if (find_my_exec(argv0, my_exec_path) < 0)
return;
--- 251,260
char path[MAXPGPATH];
char my_exec_path[MAXPGPATH];
! /* don't set LC_ALL in the backend */
! if (strcmp(app, "postgres") != 0)
! setlocale(LC_ALL, "");
!
if (find_my_exec(argv0, my_exec_path) < 0)
return;
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] Relocatable locale
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, patch applied. Turns out it was only added for the backend
> ("postgres").
Hm? Isn't that code going to be executed in postmaster, bootstrap,
checkpoint processes, etc etc?
I don't really believe that path.c has any business doing this at
all, in any program.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Relocatable locale
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, patch applied. Turns out it was only added for the backend
> > ("postgres").
>
> Hm? Isn't that code going to be executed in postmaster, bootstrap,
> checkpoint processes, etc etc?
>
> I don't really believe that path.c has any business doing this at
> all, in any program.
Well, all our client apps used to do it in their own code. Now they
call set_pglocale to do it centrally and relocabably.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Relocatable locale
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I don't really believe that path.c has any business doing this at >> all, in any program. > Well, all our client apps used to do it in their own code. Now they > call set_pglocale to do it centrally and relocabably. I don't care if the clients do it. I don't want main.c doing it. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Relocatable locale
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I don't really believe that path.c has any business doing this at
> >> all, in any program.
>
> > Well, all our client apps used to do it in their own code. Now they
> > call set_pglocale to do it centrally and relocabably.
>
> I don't care if the clients do it. I don't want main.c doing it.
Well, as coded now, it will behave the same.
The old code has in main.c:
- bindtextdomain("postgres", LOCALEDIR);
- textdomain("postgres");
and now it has a call to set_pgsetlocale which does:
if (find_my_exec(argv0, my_exec_path) < 0)
return;
get_locale_path(argv0, path);
bindtextdomain(app, path);
textdomain(app);
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: main.c
===
RCS file: /cvsroot/pgsql-server/src/backend/main/main.c,v
retrieving revision 1.81
retrieving revision 1.82
diff -c -r1.81 -r1.82
*** main.c 24 May 2004 02:47:44 - 1.81
--- main.c 25 May 2004 01:00:20 - 1.82
***
*** 150,155
--- 150,157
* startup error messages to be localized.
*/
+ set_pglocale(argv[0], "postgres");
+
#ifdef WIN32
/*
* Windows uses codepages rather than the environment, so we work around
***
*** 184,194
setlocale(LC_MONETARY, "C");
setlocale(LC_NUMERIC, "C");
setlocale(LC_TIME, "C");
-
- #ifdef ENABLE_NLS
- bindtextdomain("postgres", LOCALEDIR);
- textdomain("postgres");
- #endif
/*
* Skip permission checks if we're just trying to do --help or
--- 186,191
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Relocatable locale
Bruce Momjian <[EMAIL PROTECTED]> writes: > Well, as coded now, it will behave the same. No it won't: as you have it, the postmaster and everything else that goes through main.c will execute a setlocale call, which was not there before for very good reasons. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Relocatable locale
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Well, as coded now, it will behave the same. > > No it won't: as you have it, the postmaster and everything else that > goes through main.c will execute a setlocale call, which was not there > before for very good reasons. I don't understand. I moved it up little in the file, but those calls were happening in that file before, just a little lower. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Relocatable locale
Bruce Momjian <[EMAIL PROTECTED]> writes: > I don't understand. I moved it up little in the file, but those calls > were happening in that file before, just a little lower. No, *that* call wasn't happening at all. The calls that were there were setting certain limited, safe LC categories. You added a call that sets *all* LC categories, including ones we do not want changed. See the discussion in src/backend/utils/adt/pg_locale.c. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Relocatable locale
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I don't understand. I moved it up little in the file, but those calls > > were happening in that file before, just a little lower. > > No, *that* call wasn't happening at all. The calls that were there > were setting certain limited, safe LC categories. You added a call > that sets *all* LC categories, including ones we do not want changed. > See the discussion in src/backend/utils/adt/pg_locale.c. But I added code to path.c to skip that if the app is "postgres". Why doesn't that work? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Relocatable locale
Bruce Momjian <[EMAIL PROTECTED]> writes: > But I added code to path.c to skip that if the app is "postgres". Why > doesn't that work? That will work fine ... for a standalone backend. Not so fine for postmaster or bootstrap or other cases that go through main.c. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Relocatable locale
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > But I added code to path.c to skip that if the app is "postgres". Why > > doesn't that work? > > That will work fine ... for a standalone backend. Not so fine for > postmaster or bootstrap or other cases that go through main.c. But they all use the app name of "postgres". They always did. That is not 'progname' but a hardcoded appname that is used in the main.c call. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Relocatable locale
Bruce Momjian <[EMAIL PROTECTED]> writes: > But they all use the app name of "postgres". They always did. Oh! Sorry, I'm barking up the wrong tree then. I was thinking you were looking at the exec_path. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Relocatable locale
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > But they all use the app name of "postgres". They always did. > > Oh! Sorry, I'm barking up the wrong tree then. I was thinking you were > looking at the exec_path. Nope, hard-coded, as they all are. I could pull from argv[0], but that doesn't work in too many cases. The main.c call is: set_pglocale(argv[0], "postgres"); and is the same no matter what is coming through main.c. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
