Re: [PATCHES] [HACKERS] Autovacuum loose ends
Tom Lane wrote: Matthew T. O'Connor matthew@zeut.net writes: I don't know either, but this brings up another question. Stats wraparound. We'll all be safely dead, for one thing ;-) At one update per nanosecond, it'd take approximately 300 years to wrap a 64-bit counter. Somehow I don't have a problem with the idea that Postgres would need to be rebooted that often. We'd want to fix the 32-bit nature of XIDs long before 64-bit stats counters get to be a real-world issue ... *sigh* Sorry, I should have done a little math before I asked that question. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] per user/database connections limit again
The new syntax for this command is CREATE/ALTER DATABASE/USER:
| MAX CONNECTIONS Iconst
This adds 'max' as a keyword, though at a fairly unreserved level, I
think. Should we use the syntax LIMIT CONNECTIONS so we don't have to
add MAX as a keyword at all?
---
Petr Jelinek wrote:
Stephen Frost wrote:
This should almost certainly be a pg_database_ownercheck() call instead.
Right there wasn't pg_database_ownercheck at the time I was writing it,
fixed
The rest needs to be updated for roles, but looks like it should be
pretty easy to do. Much of it just needs to be repatched, the parts
that do need to be changed look to be pretty simple changes.
Done.
I believe the use of SessionUserId is probably correct in this patch.
This does mean that this patch will only be for canlogin roles, but that
seems like it's probably correct. Handling roles w/ members would
require much more thought.
I don't think that having max connection for roles w/ members is doable
because you can have 5 roles which has 1 user as member and each role
has different number of max conections and there is no right way to
decide what to do.
New version which works with roles is attached (diffed against cvs),
everything else is mostly same.
I also had to readd roleid to flatfiles because I need it in
InitProcess() function.
--
Regards
Petr Jelinek (PJMODOS)
Index: src/backend/commands/dbcommands.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/commands/dbcommands.c,v
retrieving revision 1.164
diff -c -r1.164 dbcommands.c
*** src/backend/commands/dbcommands.c 30 Jun 2005 00:00:50 - 1.164
--- src/backend/commands/dbcommands.c 3 Jul 2005 22:47:39 -
***
*** 53,60
/* non-export function prototypes */
static bool get_db_info(const char *name, Oid *dbIdP, Oid *ownerIdP,
! int *encodingP, bool *dbIsTemplateP, bool *dbAllowConnP,
! Oid *dbLastSysOidP,
TransactionId *dbVacuumXidP, TransactionId
*dbFrozenXidP,
Oid *dbTablespace);
static bool have_createdb_privilege(void);
--- 53,60
/* non-export function prototypes */
static bool get_db_info(const char *name, Oid *dbIdP, Oid *ownerIdP,
! int *encodingP, int *dbMaxConnP, bool *dbIsTemplateP,
! bool *dbAllowConnP, Oid *dbLastSysOidP,
TransactionId *dbVacuumXidP, TransactionId
*dbFrozenXidP,
Oid *dbTablespace);
static bool have_createdb_privilege(void);
***
*** 74,79
--- 74,80
int src_encoding;
boolsrc_istemplate;
boolsrc_allowconn;
+ int src_maxconn;
Oid src_lastsysoid;
TransactionId src_vacuumxid;
TransactionId src_frozenxid;
***
*** 91,100
--- 92,103
DefElem*downer = NULL;
DefElem*dtemplate = NULL;
DefElem*dencoding = NULL;
+ DefElem*dmaxconn = NULL;
char *dbname = stmt-dbname;
char *dbowner = NULL;
const char *dbtemplate = NULL;
int encoding = -1;
+ int dbmaxconn = -1;
#ifndef WIN32
charbuf[2 * MAXPGPATH + 100];
***
*** 140,145
--- 143,156
errmsg(conflicting or
redundant options)));
dencoding = defel;
}
+ else if (strcmp(defel-defname, maxconnections) == 0)
+ {
+ if (dmaxconn)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg(conflicting or
redundant options)));
+ dmaxconn = defel;
+ }
else if (strcmp(defel-defname, location) == 0)
{
ereport(WARNING,
***
*** 185,190
--- 196,203
elog(ERROR, unrecognized node type: %d,
nodeTag(dencoding-arg));
}
+ if (dmaxconn dmaxconn-arg)
+ dbmaxconn = intVal(dmaxconn-arg);
/* obtain OID of proposed owner */
if (dbowner)
***
*** 218,224
* idea, so accept possibility of race to create. We will check again
* after we grab the exclusive lock.
*/
! if (get_db_info(dbname, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL, NULL))
ereport(ERROR,
Re: [PATCHES] per user/database connections limit again
Bruce Momjian pgman@candle.pha.pa.us writes: The new syntax for this command is CREATE/ALTER DATABASE/USER: | MAX CONNECTIONS Iconst This adds 'max' as a keyword, though at a fairly unreserved level, I think. Should we use the syntax LIMIT CONNECTIONS so we don't have to add MAX as a keyword at all? I didn't like that either. I was thinking of just CONNECTIONS. LIMIT CONNECTIONS sort of works grammatically, I guess. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Proposed patch to remove .so pattern rules from platform Makefiles
The patch works on AIX with one small tweak to Makefile.shlib (attached). This is needed because of the clever trick with using % as name, and when its evaulated for the mkldexport. Also, it appears that the changes for regress/GNUmakefile are already applied. I am able to build everything and pass the regression tests. This just leaves the contrib/pgport issue from letting AIX go green on the buildfarm. Thanks for getting this simplification done! -rocco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane Sent: Sunday, July 24, 2005 6:00 PM To: pgsql-patches@postgresql.org Subject: [PATCHES] Proposed patch to remove .so pattern rules from platform Makefiles I've wanted for a long time to get rid of the pattern rules in the port-specific Makefiles that generate shared libraries from single object files. These patterns duplicate (or, more often, fail to completely duplicate) the knowledge in Makefile.shlib. So from a maintenance point of view centralizing that knowledge is a good thing. The stumbling block has been partly that the regression-test makefile depended on the pattern rules (easily fixed by using Makefile.shlib) and partly that pgxs.mk (and its predecessor contrib-global.mk) depended on the pattern rules to handle Makefiles that wanted to build multiple .so files. Since Makefile.shlib is designed to handle only one shlib per build, there wasn't any obvious way to fix that. The attached proposed patch gets around this by invoking Makefile.shlib in a way that produces a pattern rule lib%.so : %.o. This is moderately ugly but it gets the job done without changing Makefile.shlib itself. Possibly it could be done more cleanly if we were willing to introduce pattern rules inside Makefile.shlib. I am not sure if the patch works on non-Unix platforms --- could someone test on Win32 and Cygwin, in particular? AIX is weird enough to need testing too. Any other comments? regards, tom lane makefile.shlib Description: makefile.shlib ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] psql patch for displaying the username when asking password
Patch adjusted slightly, attached, and applied. Thanks.
---
Adrian Maier wrote:
On 6/30/05, Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Donnerstag, 30. Juni 2005 09:34 schrieb Adrian Maier:
The attached patch modifies the message displayed by psql
when asking the password Password:
to include the username as well: Password for user postgres : .
I can't decode your attachment so I don't know if this is a typo or
actually in the patch, but there shouldn't be a space after the user name.
There was a space there. I've removed the space between
username and colons.The space after the colons is ok, I hope ?
I'm attaching the modified patch.
Cheers,
Adrian Maier
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/bin/psql/command.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.150
diff -c -c -r1.150 command.c
*** src/bin/psql/command.c 18 Jul 2005 20:57:53 - 1.150
--- src/bin/psql/command.c 25 Jul 2005 17:13:42 -
***
*** 911,916
--- 911,917
const char *dbparam = NULL;
const char *userparam = NULL;
const char *pwparam = NULL;
+ char *password_prompt = NULL;
char *prompted_password = NULL;
boolneed_pass;
boolsuccess = false;
***
*** 930,938
else
userparam = new_user;
/* need to prompt for password? */
if (pset.getPassword)
! pwparam = prompted_password = simple_prompt(Password: , 100,
false);
/*
* Use old password (if any) if no new one given and we are
--- 931,948
else
userparam = new_user;
+ if (userparam == NULL)
+ password_prompt = strdup(Password: );
+ else
+ {
+ password_prompt = malloc(strlen(Password for user %s: ) - 2 +
+
strlen(userparam) + 1);
+ sprintf(password_prompt,Password for user %s: , userparam);
+ }
+
/* need to prompt for password? */
if (pset.getPassword)
! pwparam = prompted_password = simple_prompt(password_prompt,
100, false);
/*
* Use old password (if any) if no new one given and we are
***
*** 956,966
need_pass = true;
free(prompted_password);
prompted_password = NULL;
! pwparam = prompted_password = simple_prompt(Password:
, 100, false);
}
} while (need_pass);
free(prompted_password);
/*
* If connection failed, try at least keep the old one. That's
--- 966,977
need_pass = true;
free(prompted_password);
prompted_password = NULL;
! pwparam = prompted_password =
simple_prompt(password_prompt, 100, false);
}
} while (need_pass);
free(prompted_password);
+ free(password_prompt);
/*
* If connection failed, try at least keep the old one. That's
Index: src/bin/psql/startup.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/startup.c,v
retrieving revision 1.119
diff -c -c -r1.119 startup.c
*** src/bin/psql/startup.c 14 Jul 2005 08:42:37 - 1.119
--- src/bin/psql/startup.c 25 Jul 2005 17:13:42 -
***
*** 106,111
--- 106,112
char *username = NULL;
char *password = NULL;
+ char *password_prompt = NULL;
boolneed_pass;
set_pglocale_pgservice(argv[0], psql);
***
*** 188,195
username = pg_strdup(options.username);
}
if (pset.getPassword)
! password = simple_prompt(Password: , 100, false);
/* loop until we have a password if requested by backend */
do
--- 189,205
username = pg_strdup(options.username);
}
+ if (options.username == NULL)
+ password_prompt = strdup(Password: );
+ else
+ {
+ password_prompt = malloc(strlen(Password for user %s: ) - 2 +
+
Re: [PATCHES] per user/database connections limit again
Bruce Momjian wrote: The new syntax for this command is CREATE/ALTER DATABASE/USER: | MAX CONNECTIONS Iconst This adds 'max' as a keyword, though at a fairly unreserved level, I think. Should we use the syntax LIMIT CONNECTIONS so we don't have to add MAX as a keyword at all? Yeah I have no problem with LIMIT CONNECTIONS, will you change it or should I do it ? btw where has new keyword to be added to not be added at a fairly unreserved level ? (MAX is also added to keywords.c in that patch) -- Regards Petr Jelinek (PJMODOS) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] per user/database connections limit again
Petr Jelinek wrote: Bruce Momjian wrote: The new syntax for this command is CREATE/ALTER DATABASE/USER: | MAX CONNECTIONS Iconst This adds 'max' as a keyword, though at a fairly unreserved level, I think. Should we use the syntax LIMIT CONNECTIONS so we don't have to add MAX as a keyword at all? Yeah I have no problem with LIMIT CONNECTIONS, will you change it or should I do it ? I will do it. btw where has new keyword to be added to not be added at a fairly unreserved level ? (MAX is also added to keywords.c in that patch) Right, I will remove the MAX addition. parser/gram.y has this comment: /* * Keyword classification lists. Generally, every keyword present in * the Postgres grammar should appear in exactly one of these lists. * * Put a new keyword into the first list that it can go into without causing * shift or reduce conflicts. The earlier lists define less reserved * categories of keywords. */ I will check that your additions are in the right place. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Regression - GNUmakefile - pg_usleep
I see what you are saying now. libpgport is not a shared library - because of AIX's funny linking, I had not noticed that before. You propose making it similar to libpq. By that do you mean breaking it into 2 separate diretories - backend/libpq interfaces/libpq - so that we create the libraries pgport and pgport_srv from different directories - possibly using the existing backend/port and port? If you mean something else, let me know so that I might persue that path. In the mean time, an AIX specific patch(hack) would be to shove -lpgport into BE_DLLLIB in Makefile.aix - patch attached. Thanks -rocco (desperate to get AIX green on buildfarm) -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Sunday, July 24, 2005 7:34 PM To: Rocco Altier Cc: Patches (PostgreSQL) Subject: Re: [PATCHES] Regression - GNUmakefile - pg_usleep Rocco Altier [EMAIL PROTECTED] writes: This time I actually have the patches :-) I've applied the parts of this that add -lm to contrib modules, but not the parts that add -lpgport. That's because libpgport is not built to be relocatable, and so including it fails hard on platforms that care: /usr/ccs/bin/ld +h libtsearch2.sl.0 -b +b /home/postgres/testversion/lib dict_ex.o dict.o snmap.o stopword.o common.o prs_dcfg.o dict_snowball.o dict_ispell.o dict_syn.o wparser.o wparser_def.o ts_cfg.o tsvector.o rewrite.o crc32.o query.o gistidx.o tsvector_op.o rank.o ts_stat.o snowball/SUBSYS.o ispell/SUBSYS.o wordparser/SUBSYS.o -L../../src/port -L/usr/local/lib -lpgport -lm `gcc -L../../src/port -Wl,-z -Wl,+b -Wl,/home/postgres/testversion/lib -print-libgcc-file-name` -o libtsearch2.sl.0 /usr/ccs/bin/ld: DP relative code in file ../../src/port/libpgport.a(exec.o) - shared library must be position independent. Use +z or +Z to recompile. make: *** [libtsearch2.sl.0] Error 1 We will need to either eliminate the dependencies on libpgport, or use the extra-compilation technique used in, eg, libpq. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] User's exception plpgsql
Neil Conway wrote: Not at the moment. I believe we have agreed that it would be better to remove the concept of exception variables and just use strings, but I haven't implemented this yet. BTW, one minor annoyance I noticed: a builtin condition name can actually map to multiple SQLSTATE values. If we allow a builtin condition name to be specified to RAISE, this means we'll actually need to pass around a list of SQLSTATE values that are thrown by the RAISE, rather than a single SQLSTATE. This seems pretty ugly, though -- especially considering that only a handful of the builtin condition names actually do map to multiple SQLSTATEs. Does anyone have a better suggestion? -Neil ---(end of broadcast)--- TIP 1: 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
[PATCHES] Interval-day docs and regression tests
Please find attached diffs for documentation and simple regression tests for the new interval-day changes. I added tests for justify_hours() and justify_days() to interval.sql, as they take interval input and produce interval output. If there's a more appropriate place for them, please let me know. I've included the diff in the email as well (below) for ease of review. Michael Glaesemann grzm myrealbox com Index: doc/src/sgml/func.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/func.sgml,v retrieving revision 1.269 diff -c -r1.269 func.sgml *** doc/src/sgml/func.sgml22 Jul 2005 21:16:14 -1.269 --- doc/src/sgml/func.sgml26 Jul 2005 00:43:49 - *** *** 4903,4908 --- 4903,4926 such pair. /para + para +When adding an typeinterval/type value to (or subtracting an +typeinterval/type value from) a typetimestamp with time zone/type +value, the days component advances (or decrements) the date of the +typetimestamp with time zonetype by the indicated number of days. +Across daylight saving time changes (with the session tiem zone set to a +time zone that recognizes DST), this means literalinterval '1 day'/literal +does not necessarily equal literalinterval '24 hours'/literal. +For example, with the session time zone set to literalCST7CDT/ literal +literaltimestamp with time zone '2005-04-02 12:00-07' + interval '1 day' /literal +will produce literaltimestamp with time zone '2005-04-03 12:00-06'/literal, +while adding literalinterval '24 hours'/literal to the same initial +typetimestamp with time zone/type produces +literaltimestamp with time zone '2005-04-03 13:00-06'/ literal, as there is +a change in daylight saving time at literal2005-04-03 02:00/ literal in time zone +literalCST7CDT/literal. + /para + table id=operators-datetime-table titleDate/Time Operators/title Index: src/test/regress/expected/horology.out === RCS file: /projects/cvsroot/pgsql/src/test/regress/expected/ horology.out,v retrieving revision 1.56 diff -c -r1.56 horology.out *** src/test/regress/expected/horology.out27 May 2005 21:31:23 -1.56 --- src/test/regress/expected/horology.out26 Jul 2005 00:43:49 - *** *** 598,603 --- 598,630 t (1 row) + -- timestamp with time zone, interval arithmetic around DST change + SET TIME ZONE 'CST7CDT'; + SELECT timestamp with time zone '2005-04-02 12:00-07' + interval '1 day' as Apr 3, 12:00; + Apr 3, 12:00 + -- + Sun Apr 03 12:00:00 2005 CDT + (1 row) + + SELECT timestamp with time zone '2005-04-02 12:00-07' + interval '24 hours' as Apr 3, 13:00; + Apr 3, 13:00 + -- + Sun Apr 03 13:00:00 2005 CDT + (1 row) + + SELECT timestamp with time zone '2005-04-03 12:00-06' - interval '1 day' as Apr 2, 12:00; + Apr 2, 12:00 + -- + Sat Apr 02 12:00:00 2005 CST + (1 row) + + SELECT timestamp with time zone '2005-04-03 12:00-06' - interval '24 hours' as Apr 2, 11:00; + Apr 2, 11:00 + -- + Sat Apr 02 11:00:00 2005 CST + (1 row) + + RESET TIME ZONE; SELECT timestamptz(date '1994-01-01', time '11:00') AS Jan_01_1994_10am; Jan_01_1994_10am -- Index: src/test/regress/expected/interval.out === RCS file: /projects/cvsroot/pgsql/src/test/regress/expected/ interval.out,v retrieving revision 1.12 diff -c -r1.12 interval.out *** src/test/regress/expected/interval.out20 Jul 2005 16:42:32 -1.12 --- src/test/regress/expected/interval.out26 Jul 2005 00:43:49 - *** *** 228,230 --- 228,243 @ 4541 years 4 mons 4 days 17 mins 31 secs (1 row) + -- test justify_hours() and justify_days() + SELECT justify_hours(interval '6 months 3 days 52 hours 3 minutes 2 seconds') as 6 mons 5 days 4 hours 3 mins 2 seconds; + 6 mons 5 days 4 hours 3 mins 2 seconds + + @ 6 mons 5 days 4 hours 3 mins 2 secs + (1 row) + + SELECT justify_days(interval '6 months 36 days 5 hours 4 minutes 3 seconds') as 7 mons 6 days 5 hours 4 mins 3 seconds; + 7 mons 6 days 5 hours 4 mins 3 seconds + + @ 7 mons 6 days 5 hours 4 mins 3 secs + (1 row) + Index: src/test/regress/sql/horology.sql === RCS file: /projects/cvsroot/pgsql/src/test/regress/sql/horology.sql,v retrieving revision 1.30 diff -c -r1.30 horology.sql *** src/test/regress/sql/horology.sql7 Apr 2005 01:51:41 - 1.30 --- src/test/regress/sql/horology.sql26 Jul 2005 00:43:49 -
Re: [PATCHES] Regression - GNUmakefile - pg_usleep
Rocco Altier [EMAIL PROTECTED] writes: You propose making it similar to libpq. By that do you mean breaking it into 2 separate diretories - backend/libpq interfaces/libpq - so that we create the libraries pgport and pgport_srv from different directories - possibly using the existing backend/port and port? No, I'm talking about just importing the individual source files that are needed and compiling them with -fpic enabled as part of the module that needs them. Look at what libpq does with pgstrcasecmp.c, or what I just made the regression test module do with pgsleep.c. regards, tom lane ---(end of broadcast)--- TIP 1: 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] User's exception plpgsql
On Tue, 26 Jul 2005, Neil Conway wrote: Neil Conway wrote: Not at the moment. I believe we have agreed that it would be better to remove the concept of exception variables and just use strings, but I haven't implemented this yet. BTW, one minor annoyance I noticed: a builtin condition name can actually map to multiple SQLSTATE values. can you show sample, please? If we allow a builtin condition name to be specified to RAISE, this means we'll actually need to pass around a list of SQLSTATE values that are thrown by the RAISE, rather than a single SQLSTATE. This seems pretty ugly, though -- especially considering that only a handful of the builtin condition names actually do map to multiple SQLSTATEs. Does anyone have a better suggestion? Exception variables can solve it, but its dead concept. We can have list of prohibited condition names and for its throw compile error condition name is ambigous Pavel -Neil ---(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
Re: [PATCHES] User's exception plpgsql
hello, sorry, exception variables don't solve this problem too. But we can detect it in compile-time. I don't wont to complicate raise syntax. best regards Pavel ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Autovacuum loose ends
On Thu, Jul 14, 2005 at 10:52:56AM -0400, Tom Lane wrote:
I've applied Alvaro's latest integrated-autovacuum patch. There are
still a number of loose ends to be dealt with before beta, though:
Updated this patch:
- The stat collector is modified so as to keep shared relations separate
from regular ones. Autovacuum understands this.
- Temp tables are completely ignored.
- pg_statistic is ignored for analyze. It's still candidate for vacuum.
- databases with no stat entry are still ignored, except that they are
checked for Xid wraparound like any other. The oldest one is chosen
for vacuum in a particular autovacuum run.
- A database-wide vacuum forces a pg_database flat-file update, so that
the wraparound check actually works.
- The postmaster's main loop sleeps Min(60, autovacuum_naptime), in
order to be able to pick naptimes smaller than 60 seconds. In order
not to make the loop a busy-wait, I forced a minimum of 1 to that GUC
var. Yes, an argument could be made that the minimum could be higher.
Not sure if we actually want to dictate policy on this. The minimum
is there only to prevent the postmaster from using 100% of a CPU the
whole time.
- Tables with no stat entries are completely ignored.
- The stat collector ignores messages that relate to databases it
doesn't know about. This makes it inocuous to issue a database-wide
vacuum on a template database. A special case is made for database
InvalidOid -- an entry for it is created regardless.
Two comments still apply:
- I haven't done anything yet w.r.t. the custom vacuum_delay nor sleep
scale factor.
- There are still no docs.
--
Alvaro Herrera (alvherre[a]alvh.no-ip.org)
Porque Kim no hacia nada, pero, eso sí,
con extraordinario éxito (Kim, Kipling)
Index: access/transam/xlog.c
===
RCS file: /home/alvherre/cvs/pgsql/src/backend/access/transam/xlog.c,v
retrieving revision 1.210
diff -c -r1.210 xlog.c
*** access/transam/xlog.c 23 Jul 2005 15:31:16 - 1.210
--- access/transam/xlog.c 24 Jul 2005 17:55:51 -
***
*** 465,471
TimeLineID endTLI,
uint32 endLogId, uint32 endLogSeg);
static void WriteControlFile(void);
- static void ReadControlFile(void);
static char *str_time(time_t tnow);
static void issue_xlog_fsync(void);
--- 465,470
***
*** 3383,3390
errmsg(could not close control file: %m)));
}
! static void
! ReadControlFile(void)
{
pg_crc32crc;
int fd;
--- 3382,3394
errmsg(could not close control file: %m)));
}
! /*
! * Read and verify the control file, filling the ControlFile struct.
! *
! * If nextXid is not NULL, the latest Checkpoint's nextXid is returned.
! */
! void
! ReadControlFile(TransactionId *nextXid)
{
pg_crc32crc;
int fd;
***
*** 3525,3530
--- 3529,3537
ControlFile-lc_ctype),
errhint(It looks like you need to initdb or install locale
support.)));
+ if (PointerIsValid(nextXid))
+ *nextXid = ControlFile-checkPointCopy.nextXid;
+
/* Make the fixed locale settings visible as GUC variables, too */
SetConfigOption(lc_collate, ControlFile-lc_collate,
PGC_INTERNAL, PGC_S_OVERRIDE);
***
*** 3650,3656
* for the reasons why).
*/
if (!IsBootstrapProcessingMode())
! ReadControlFile();
}
/*
--- 3657,3663
* for the reasons why).
*/
if (!IsBootstrapProcessingMode())
! ReadControlFile(NULL);
}
/*
***
*** 4232,4238
* Note: in most control paths, *ControlFile is already valid and we
need
* not do ReadControlFile() here, but might as well do it to be sure.
*/
! ReadControlFile();
if (ControlFile-logSeg == 0 ||
ControlFile-state DB_SHUTDOWNED ||
--- 4239,4245
* Note: in most control paths, *ControlFile is already valid and we
need
* not do ReadControlFile() here, but might as well do it to be sure.
*/
! ReadControlFile(NULL);
if (ControlFile-logSeg == 0 ||
ControlFile-state DB_SHUTDOWNED ||
Index: commands/analyze.c
===
RCS file: /home/alvherre/cvs/pgsql/src/backend/commands/analyze.c,v
retrieving revision 1.87
diff -c -r1.87 analyze.c
*** commands/analyze.c 14 Jul 2005 05:13:39 - 1.87
--- commands/analyze.c 26 Jul 2005 03:51:45 -
***
*** 317,323
* a zero-column table.
*/
Re: [PATCHES] User's exception plpgsql
Neil Conway [EMAIL PROTECTED] writes: Pavel Stehule wrote: can you show sample, please? modifying_sql_data_not_permitted, null_value_not_allowed, prohibited_sql_statement_attempted and reading_sql_data_not_permitted are the examples I can see from scanning plerrcodes.h. If we had this to do over again, I'm not sure I see the point in mapping a single condition names to multiple SQLSTATEs, but it's probably too late to undo that now. Those cases are for places where the spec defines similar cases under the error classes SQL Routine Exception and External Routine Exception. You can blame me for having assumed that plpgsql didn't need to distinguish these cases. A quick grep says that the only one of these codes being generated today is contrib/dblink/dblink.c: (errcode(ERRCODE_S_R_E_PROHIBITED_SQL_STATEMENT_ATTEMPTED), and that's for a you should not do that case, which it's very unlikely anyone is specifically trapping for. So I see no backwards-compatibility argument that we can't change this. How would you want to do it better? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
