Re: [PATCHES] Compiling libpq with VisualC
Bruce Momjian wrote: fe-connect.c: - pg_config_paths.h isn't available. SYSCONFDIR is already defined so fe-connect.c doesn't need to include that. patch appended This shouldn't be needed anymore. Where is SYSCONFDIR coming from? Is it from some Win32 include file? It should only be coming from pg_config_paths.h now. It's defined in pg_config.h.win32, which is copied to pg_config.h. There's no pg_config_paths.h for win32, and I wonder if the code which uses SYSCONFDIR is of any use for win32. Regards, Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[PATCHES] Stylistic changes in bufmgr.c
Basically replaces (*a).b with a-b as it is everywhere else in
Postgres.
Servus
Manfred
diff -Ncr ../base/src/backend/storage/page/bufpage.c src/backend/storage/page/bufpage.c
*** ../base/src/backend/storage/page/bufpage.c Sat Nov 29 20:51:57 2003
--- src/backend/storage/page/bufpage.c Wed Jun 2 22:26:12 2004
***
*** 151,158
if (offsetNumber limit)
{
itemId = PageGetItemId(phdr, offsetNumber);
! if (((*itemId).lp_flags LP_USED) ||
! ((*itemId).lp_len != 0))
{
elog(WARNING, will not overwrite a used
ItemId);
return InvalidOffsetNumber;
--- 151,158
if (offsetNumber limit)
{
itemId = PageGetItemId(phdr, offsetNumber);
! if ((itemId-lp_flags LP_USED) ||
! (itemId-lp_len != 0))
{
elog(WARNING, will not overwrite a used
ItemId);
return InvalidOffsetNumber;
***
*** 172,179
for (offsetNumber = 1; offsetNumber limit; offsetNumber++)
{
itemId = PageGetItemId(phdr, offsetNumber);
! if *itemId).lp_flags LP_USED) == 0)
! ((*itemId).lp_len == 0))
break;
}
/* if no free slot, we'll put it at limit (1st open slot) */
--- 172,179
for (offsetNumber = 1; offsetNumber limit; offsetNumber++)
{
itemId = PageGetItemId(phdr, offsetNumber);
! if (((itemId-lp_flags LP_USED) == 0)
! (itemId-lp_len == 0))
break;
}
/* if no free slot, we'll put it at limit (1st open slot) */
***
*** 214,222
(limit - offsetNumber) * sizeof(ItemIdData));
/* set the item pointer */
! (*itemId).lp_off = upper;
! (*itemId).lp_len = size;
! (*itemId).lp_flags = flags;
/* copy the item's data onto the page */
memcpy((char *) page + upper, item, size);
--- 214,222
(limit - offsetNumber) * sizeof(ItemIdData));
/* set the item pointer */
! itemId-lp_off = upper;
! itemId-lp_len = size;
! itemId-lp_flags = flags;
/* copy the item's data onto the page */
memcpy((char *) page + upper, item, size);
***
*** 278,296
/*
* sorting support for PageRepairFragmentation
*/
! struct itemIdSortData
{
int offsetindex;/* linp array index */
int itemoff;/* page offset of item data */
Sizealignedlen; /* MAXALIGN(item data len) */
! };
static int
itemoffcompare(const void *itemidp1, const void *itemidp2)
{
/* Sort in decreasing itemoff order */
! return ((struct itemIdSortData *) itemidp2)-itemoff -
! ((struct itemIdSortData *) itemidp1)-itemoff;
}
/*
--- 278,297
/*
* sorting support for PageRepairFragmentation
*/
! typedef struct itemIdSortData
{
int offsetindex;/* linp array index */
int itemoff;/* page offset of item data */
Sizealignedlen; /* MAXALIGN(item data len) */
! } itemIdSortData;
! typedef itemIdSortData *itemIdSort;
static int
itemoffcompare(const void *itemidp1, const void *itemidp2)
{
/* Sort in decreasing itemoff order */
! return ((itemIdSort) itemidp2)-itemoff -
! ((itemIdSort) itemidp1)-itemoff;
}
/*
***
*** 309,316
Offset pd_lower = ((PageHeader) page)-pd_lower;
Offset pd_upper = ((PageHeader) page)-pd_upper;
Offset pd_special = ((PageHeader) page)-pd_special;
! struct itemIdSortData *itemidbase,
! *itemidptr;
ItemId lp;
int nline,
nused;
--- 310,317
Offset pd_lower = ((PageHeader) page)-pd_lower;
Offset pd_upper = ((PageHeader) page)-pd_upper;
Offset pd_special = ((PageHeader) page)-pd_special;
! itemIdSort itemidbase,
! itemidptr;
ItemId lp;
int nline,
nused;
***
***
[PATCHES] vacuum.c refactoring
. rename variables
. cur_buffer - dst_buffer
. ToPage - dst_page
. cur_page - dst_vacpage
. move variable declarations into block where variable is used
. various Asserts instead of elog(ERROR, ...)
. extract functionality from repair_frag() into new routines
. move_chain_tuple()
. move_plain_tuple()
. update_hint_bits()
. create type ExecContext
. add comments
This patch does not intend to change any behaviour. It passes make
check, make installcheck and some manual tests. It might be hard to
review, because some lines are affected by more than one change. If
it's too much to swallow at once, I can provide it in smaller chunks ...
Servus
Manfred
diff -Ncr ../base/src/backend/commands/vacuum.c src/backend/commands/vacuum.c
*** ../base/src/backend/commands/vacuum.c Mon May 31 21:24:05 2004
--- src/backend/commands/vacuum.c Wed Jun 2 21:46:59 2004
***
*** 99,104
--- 99,162
VTupleLink vtlinks;
} VRelStats;
+ /*--
+ * ExecContext:
+ *
+ * As these variables always appear together, we put them into one struct
+ * and pull initialization and cleanup into separate routines.
+ * ExecContext is used by repair_frag() and move_xxx_tuple(). More
+ * accurately: It is *used* only in move_xxx_tuple(), but because this
+ * routine is called many times, we initialize the struct just once in
+ * repair_frag() and pass it on to move_xxx_tuple().
+ */
+ typedef struct ExecContextData
+ {
+ ResultRelInfo *resultRelInfo;
+ EState *estate;
+ TupleTable tupleTable;
+ TupleTableSlot *slot;
+ } ExecContextData;
+ typedef ExecContextData *ExecContext;
+
+ static void
+ ExecContext_Init(ExecContext ec, Relation rel)
+ {
+ TupleDesc tupdesc = RelationGetDescr(rel);
+
+ /*
+* We need a ResultRelInfo and an EState so we can use the regular
+* executor's index-entry-making machinery.
+*/
+ ec-estate = CreateExecutorState();
+
+ ec-resultRelInfo = makeNode(ResultRelInfo);
+ ec-resultRelInfo-ri_RangeTableIndex = 1; /* dummy */
+ ec-resultRelInfo-ri_RelationDesc = rel;
+ ec-resultRelInfo-ri_TrigDesc = NULL; /* we don't fire triggers */
+
+ ExecOpenIndices(ec-resultRelInfo);
+
+ ec-estate-es_result_relations = ec-resultRelInfo;
+ ec-estate-es_num_result_relations = 1;
+ ec-estate-es_result_relation_info = ec-resultRelInfo;
+
+ /* Set up a dummy tuple table too */
+ ec-tupleTable = ExecCreateTupleTable(1);
+ ec-slot = ExecAllocTableSlot(ec-tupleTable);
+ ExecSetSlotDescriptor(ec-slot, tupdesc, false);
+ }
+
+ static void
+ ExecContext_Finish(ExecContext ec)
+ {
+ ExecDropTupleTable(ec-tupleTable, true);
+ ExecCloseIndices(ec-resultRelInfo);
+ FreeExecutorState(ec-estate);
+ }
+ /*
+ * End of ExecContext Implementation
+ *--
+ */
static MemoryContext vac_context = NULL;
***
*** 122,127
--- 180,196
static void repair_frag(VRelStats *vacrelstats, Relation onerel,
VacPageList vacuum_pages, VacPageList fraged_pages,
int nindexes, Relation *Irel);
+ static void move_chain_tuple(Relation rel,
+Buffer old_buf, Page old_page, HeapTuple
old_tup,
+Buffer dst_buf, Page dst_page, VacPage
dst_vacpage,
+ExecContext ec, ItemPointer ctid, bool
cleanVpd);
+ static void move_plain_tuple(Relation rel,
+Buffer old_buf, Page old_page, HeapTuple
old_tup,
+Buffer dst_buf, Page dst_page, VacPage
dst_vacpage,
+ExecContext ec);
+ static void update_hint_bits(Relation rel, VacPageList fraged_pages,
+ int num_fraged_pages, BlockNumber
last_move_dest_block,
+ int num_moved);
static void vacuum_heap(VRelStats *vacrelstats, Relation onerel,
VacPageList vacpagelist);
static void vacuum_page(Relation onerel, Buffer buffer, VacPage vacpage);
***
*** 675,681
static void
vac_truncate_clog(TransactionId vacuumXID, TransactionId frozenXID)
{
! TransactionId myXID;
Relationrelation;
HeapScanDesc scan;
HeapTuple tuple;
--- 744,750
static void
vac_truncate_clog(TransactionId vacuumXID, TransactionId frozenXID)
{
! TransactionId myXID = GetCurrentTransactionId();
Relationrelation;
HeapScanDesc scan;
HeapTuple tuple;
***
*** 683,689
boolvacuumAlreadyWrapped = false;
Re: [PATCHES] [HACKERS] Configuration patch
Bruce Momjian [EMAIL PROTECTED] writes: This patch incorporates a number of changes suggested by the group. The purpose of this patch is to move postgresql to a position where all configuration options are specified in one place. The postgresql.conf file could completely document a postgresql environment. AFAICS this patch breaks standalone backends, since the smarts involved in dealing with the new flavors of directory layouts were not taught to postgres.c. The documentation is rather lacking as well. include is not really a variable and should not be documented as if it were --- for one thing, that leaves the reader wondering if he can only specify it once. The other added variables are insufficiently doc'd because there is no explanation of the defaults. Also I should think that somewhere in the admin guide there should be an explanation of the different ways you can lay out the files and why you might choose different ones. It's also highly unclear how you get such a setup established, when there's been no change in the behavior of initdb. ProcessConfigFile will dump core on out-of-memory (test for malloc failure is in the wrong place). I also think some memory leaks have been introduced in ReadConfigFile. The whole concept of a function GUC variable seems very ill-advised to me; for one thing, what will show include or set include do? Can a user do ALTER USER SET include = foo? I think it would have been better to hard-wire the handling of 'include' in the guc file reader, and not try to make it act like a variable. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] fix oid casting inconsistency
On Mon, Feb 16, 2004 at 10:00:49PM -0500, Neil Conway wrote: This patch removes the quotes from oid, to make this error message consistent with the error messages for rejected input to most other types. While I suppose it's possible that some applications might be examining this error message string, (a) this particular error message isn't very likely be used for that (b) we have error codes now. This kind of error message consistency enhancement has been applied liberally in the past. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) If you have nothing to say, maybe you need just the right tool to help you not say it. (New York Times, about Microsoft PowerPoint) ---(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] [HACKERS] Configuration patch
Bruce Momjian [EMAIL PROTECTED] writes: This patch incorporates a number of changes suggested by the group. The purpose of this patch is to move postgresql to a position where all configuration options are specified in one place. The postgresql.conf file could completely document a postgresql environment. AFAICS this patch breaks standalone backends, since the smarts involved in dealing with the new flavors of directory layouts were not taught to postgres.c. Hmm, I guess its time to get a CVS version of PG. This was originally done in 7.3 and migrated to 7.4. 7.5 is substantially different? The documentation is rather lacking as well. include is not really a variable and should not be documented as if it were --- for one thing, that leaves the reader wondering if he can only specify it once. The other added variables are insufficiently doc'd because there is no explanation of the defaults. Also I should think that somewhere in the admin guide there should be an explanation of the different ways you can lay out the files and why you might choose different ones. It's also highly unclear how you get such a setup established, when there's been no change in the behavior of initdb. I can write the docs. The primary purpose of this patch is to enable the functionality for those who need it. I was sure it would be impractical to get a concensus on changing PostgreSQL's default behavior, but this functionality can be used by OS vendors and consultants alike. As for include not being a variable, no it isn't. It is a new class of GUC parameter. Would you like a better syntax? FWIW: This is exactly the same syntax that was discussed, and no one brought up that it was a problem. You even said you liked the idea of include. ProcessConfigFile will dump core on out-of-memory (test for malloc failure is in the wrong place). I also think some memory leaks have been introduced in ReadConfigFile. I will double check. The test for malloc failure may have drifted over time. There should be no memory leaks, but again, I'll double check. The whole concept of a function GUC variable seems very ill-advised to me; for one thing, what will show include or set include do? Can a user do ALTER USER SET include = foo? I think it would have been better to hard-wire the handling of 'include' in the guc file reader, and not try to make it act like a variable. I wanted to create a generic facility for smarter configuration. Being able to create functions and pass parameters should allow smaller more focused configuration parsing. I'm open to suggestions. Would you prefer stating the function parameters with a special character? '#' is taken, how about '!' ? is in: !include ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Add error-checking to timestamp_recv
I said: I'll make a note to do something with this issue after the TZ patch is in. I've applied a patch to take care of this problem. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [HACKERS] Configuration patch
[EMAIL PROTECTED] writes: AFAICS this patch breaks standalone backends, since the smarts involved in dealing with the new flavors of directory layouts were not taught to postgres.c. Hmm, I guess its time to get a CVS version of PG. This was originally done in 7.3 and migrated to 7.4. 7.5 is substantially different? The same issue applied in 7.4 and before; but yes, all that code looks noticeably different in CVS tip. As for include not being a variable, no it isn't. It is a new class of GUC parameter. Would you like a better syntax? As I said, I think this class of GUC parameter is ill-considered. FWIW: This is exactly the same syntax that was discussed, and no one brought up that it was a problem. You even said you liked the idea of include. I like the idea of include. I don't like this implementation. I wanted to create a generic facility for smarter configuration. Being able to create functions and pass parameters should allow smaller more focused configuration parsing. I don't believe include is a representative of a class; it seems a specialized one-of-a-kind thing. If you had one or two more examples of this class then I might think you are onto something, but as-is there is no reason to think that you've got a well-defined idea or have made the right decisions about how it should work. Basically, include is not a variable because neither set include nor show include are sensible operations at all. Implementing it in a way that makes you have to deal with these possibilities is simply wrongheaded. Another reason why it's not a variable is that processing it as a variable means the sub-file is not read in the order that the user would naturally expect; with the implementation as you have it, the behavior would be quite surprising as to which file wins if both outer file and subfile set the same variable. (Take another look at guc-file.l: it eats the whole file and only then starts to evaluate variables.) What I'd think is reasonable is a special case hack in guc-file.l that checks for opt_name = include and does something immediately upon seeing it. (CVS tip has a special hack for custom_variable_classes here, which has got problems of its own because that *is* a variable, but that's right around where I'd envision inserting code for include.) I'm open to suggestions. Would you prefer stating the function parameters with a special character? '#' is taken, how about '!' ? is in: It's not the syntax I'm objecting to; it's the implementation. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] Configuration patch
[EMAIL PROTECTED] writes: AFAICS this patch breaks standalone backends, since the smarts involved in dealing with the new flavors of directory layouts were not taught to postgres.c. Hmm, I guess its time to get a CVS version of PG. This was originally done in 7.3 and migrated to 7.4. 7.5 is substantially different? The same issue applied in 7.4 and before; but yes, all that code looks noticeably different in CVS tip. As for include not being a variable, no it isn't. It is a new class of GUC parameter. Would you like a better syntax? As I said, I think this class of GUC parameter is ill-considered. See below FWIW: This is exactly the same syntax that was discussed, and no one brought up that it was a problem. You even said you liked the idea of include. I like the idea of include. I don't like this implementation. OK. I wanted to create a generic facility for smarter configuration. Being able to create functions and pass parameters should allow smaller more focused configuration parsing. I don't believe include is a representative of a class; it seems a specialized one-of-a-kind thing. If you had one or two more examples of this class then I might think you are onto something, but as-is there is no reason to think that you've got a well-defined idea or have made the right decisions about how it should work. OK, imagine this, maybe not right now, but in the future.. In the configuration file, one can load C code modules like in apache. Not just SQL functions, but modules of functionality, like foreign table types. Basically, include is not a variable because neither set include nor show include are sensible operations at all. Implementing it in a way that makes you have to deal with these possibilities is simply wrongheaded. Another reason why it's not a variable is that processing it as a variable means the sub-file is not read in the order that the user would naturally expect; with the implementation as you have it, the behavior would be quite surprising as to which file wins if both outer file and subfile set the same variable. (Take another look at guc-file.l: it eats the whole file and only then starts to evaluate variables.) What I'd think is reasonable is a special case hack in guc-file.l that checks for opt_name = include and does something immediately upon seeing it. (CVS tip has a special hack for custom_variable_classes here, which has got problems of its own because that *is* a variable, but that's right around where I'd envision inserting code for include.) I'm open to suggestions. Would you prefer stating the function parameters with a special character? '#' is taken, how about '!' ? is in: It's not the syntax I'm objecting to; it's the implementation. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Doing psql's lexing with flex
Tom Lane wrote: I got interested enough in the psql-with-flex problem to go off and solve it. Attached is a working patch, which I'm now debating whether to apply. Comments solicited... The patch removes about 200 lines of very spaghetti-ish code in mainloop.c. However, it adds an 875-line flex source file, which might be thought a bad tradeoff :-(. One bright spot is that about half of that total is a direct copy of the main backend lexer, so it's not really as much new, separately maintainable code as all that. Also, Andrew Dunstan's patch for supporting dollar-quoting would add about 100 lines to mainloop.c, versus only a dozen or so lines in the flex implementation. Am I missing something, or is dollar quoting not in this patch? Perhaps you have a followup patch? Once that's taken into account I don't think there is a lot of difference in effective SLOC to maintain. I'm also of the opinion that the new C code in psqlscan.l is much more straightforward than the code removed from mainloop.c, though having just written it, I'm no doubt pretty biased. Bruce was asking about speed. On normal-size queries I cannot measure any difference at all. For testing purposes I made up a file containing a single 750K query (just a SELECT big-honking-string-constant, with the string literal broken into lines of 75 bytes). The client-side (psql) CPU time to run this file looks about like this on my machine: PGCLIENTENCODING UNICODE SJIS CVS tip 1.571.82 flex implementation 0.932.33 The flex implementation is consistently faster than CVS tip when dealing with backend-compatible encodings (such as UTF-8). It's consistently slower when it has to deal with a non-backend-safe encoding such as SJIS or Big5. But for real-world cases the differential is down in the noise either way. I'm inclined to apply this but I can see where a person not comfortable with flex might feel differently. Opinions? In principle this is the Right Thing (tm). We use flex elsewhere, of course, so the fact that it is a flex scanner doesn't seem to me to be any sort of strong argument. If we are going to do this we need to get it in ASAP, so it gets plenty of beating on. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Add error-checking to timestamp_recv
* Tom Lane ([EMAIL PROTECTED]) wrote: I said: I'll make a note to do something with this issue after the TZ patch is in. I've applied a patch to take care of this problem. Great, thanks, much appriciated. I'll test once 7.5 goes beta. Stephen signature.asc Description: Digital signature
Re: [PATCHES] [HACKERS] Configuration patch
[EMAIL PROTECTED] wrote: I wanted to create a generic facility for smarter configuration. Being able to create functions and pass parameters should allow smaller more focused configuration parsing. I don't believe include is a representative of a class; it seems a specialized one-of-a-kind thing. If you had one or two more examples of this class then I might think you are onto something, but as-is there is no reason to think that you've got a well-defined idea or have made the right decisions about how it should work. OK, imagine this, maybe not right now, but in the future.. In the configuration file, one can load C code modules like in apache. Not just SQL functions, but modules of functionality, like foreign table types. I agree with Tom that include isn't really a setting, but more of an action. What would SHOW include output? I think that outlines why it is different from other setttings. Your load capability would be another non-setting, or perhaps a read-only one, but not the same as include either. Include includes other settings. One format idea would be to suppress the equals for include, so: include '/somedir/pgdefs.conf' # include another file hba_conf = '/etc/postgres/pg_hba.conf' # use file in another directory ident_conf = '/etc/postgres/pg_ident.conf' # use file in another directory pgdata = '/usr/local/pgsql/data'# use /data in another directory external_pidfile= '/var/run/postgresql.pid' # write an extra pid file Notice include has no equals. This would more clearly suggest that multiple includes could be used. I think a SHOW of include should report an error. One interesting idea would be for SET include to work like this: SET include '/var/run/xx' Notice there is no equals here. This would allow users to create files with various settings and enable them all with one SET command. However, this does open a security issue. Seems we might have to disallow this and only allow include in postgresql.conf, where the super-user has full control. I agree with Tom that the documentation is sparse. Hopefully folks can add to that. If someone is going to keep improving this patch, please use the version I posted rather than the original because mine has lots of cleanups. ftp://candle.pha.pa.us/pub/postgresql/mypatches/guc In summary, I think we need to treat include specially in postgresql.conf (no equals) and remove it as an actual GUC parameter and just have it do includes immediately. (This will probably require special-casing it in the guc-file grammar.) Also, we need more docs on how to set up the new -D/PGDATA functionality. I was wondering myself how someone would configure this. Do we need to add an initdb capability? -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] Configuration patch
Bruce Momjian [EMAIL PROTECTED] writes: One interesting idea would be for SET include to work like this: SET include '/var/run/xx' Notice there is no equals here. This would allow users to create files with various settings and enable them all with one SET command. However, this does open a security issue. More than one, in fact. In the first place, as the code presently works, anything coming in from the file would be treated on an equal footing with values sourced from postgresql.conf, thereby allowing unprivileged users to set things they shouldn't. This is potentially fixable, but the other issue isn't: such a facility would allow anyone to ask the backend to read any file the Postgres user account can access. Not very successfully, perhaps, but even the error messages might give useful info about the file's contents to an attacker. This is the same reason that COPY FROM file is a privileged operation. I think it's important that include be restricted to appear only in config files, and not be in any way shape or form a SETtable thing. In summary, I think we need to treat include specially in postgresql.conf (no equals) and remove it as an actual GUC parameter and just have it do includes immediately. (This will probably require special-casing it in the guc-file grammar.) Yes. In fact, it'll be a less-than-trivial change in guc-file, at least if you want the thing to act intuitively (that is, include acts like the target file is actually included right here). This will mean splitting ProcessConfigFile into a recursive read step followed by a nonrecursive apply step. Also, I think that invoking the flex lexer recursively will take a little bit of work. I would suggest splitting the patch into two separate patches, one that handles include and one that handles the other changes. The other stuff is reasonably close to being ready to apply (modulo docs and fixing the standalone-backend case), but include I think is still a ways off. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] Configuration patch
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: In summary, I think we need to treat include specially in postgresql.conf (no equals) and remove it as an actual GUC parameter and just have it do includes immediately. (This will probably require special-casing it in the guc-file grammar.) Yes. In fact, it'll be a less-than-trivial change in guc-file, at least if you want the thing to act intuitively (that is, include acts like the target file is actually included right here). This will mean splitting ProcessConfigFile into a recursive read step followed by a nonrecursive apply step. Also, I think that invoking the flex lexer recursively will take a little bit of work. I would suggest splitting the patch into two separate patches, one that handles include and one that handles the other changes. The other stuff is reasonably close to being ready to apply (modulo docs and fixing the standalone-backend case), but include I think is still a ways off. One classic way to do include files is inside the lexer itself - at least that's the way I have always done it in the past. Then the client code doesn't need to know anything about it at all - it just sees a stream of lexemes with no idea what file they come from. Since inclusion can be done recursively, the lexer keeps a stack of files, of some reasonable size - in our case surely 5 or 10 would be a more than reasonable maximum recursion depth. You do need to keep track of the filename and line number for error reporting, though (use parallel stacks for those). cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] NO WAIT ...
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Why? You can do a SELECT FOR UPDATE first and then you know that you have the row lock. There's no need for any special handling of UPDATE or DELETE. I don't see the applicability to VACUUM, either. Why bother when you can do it without the SELECT FOR UPDATE? Because you want the extra feature? It throws an error. I don't see how that could cause actual data corruption or invalid data. I am concerned about what behavior will stop working nicely when locks that normally always succeed suddenly error out instead. Perhaps it won't corrupt your database, but that doesn't mean that the behavior will be pleasant. As an example: the proposed patch is able to cause an error instead of waiting for access-share locks. Suppose you actually turn that on, and then try to call some function, and the resulting attempt to read pg_proc errors out because someone was transiently holding a conflicting lock. This means your application fails, randomly, and in hard-to-reproduce ways. Not only would the failure or not-failure depend on what other people were doing, it'd depend on whether you'd already cached the function definition (if so, no lock would actually get taken on pg_proc during the call). I think a feature narrowly focused on suppressing waits for specific locks (like the lock on a specific row that you're trying to update) would be useful. Implementing something that affects *every* lock in the system is nothing more nor less than a foot-gun, because you could never be very certain what lock attempts would fail. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] small fix in FAQ
Euler Taveira de Oliveira wrote: Hi, This is a small fix in FAQ. It just clean up some old comments and change an old -not-working piece of code. Please apply it in HEAD and 7.4 branch. Thanks. Patch applied to HEAD. We don't normally backpatch stuff like this to 7.4.X. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] pg_dump --comment?
Jon Jensen wrote: On Fri, 28 May 2004, Christopher Kings-Lynne wrote: I've encountered a situation where I'd like to store some information about the database when I do a pg_dump. For instance, the timestamp of the dump. And some other information that I pull from the database. I think every dump should dump the timestamp regardless... That would cause me a lot of trouble. Every night I do a pg_dump on all my databases to a temporary file. Then I use cmp to compare that dump to last night's dump. If they're identical I just delete the new dump so that only the old one remains, with its original timestamp. That way rsync doesn't see any change, and doesn't waste any time comparing it when we do backups. It's also handy to see the last day the dump changed by looking at the file's timestamp. Granted, this is only of interest on databases that don't change at all, but on a multi-user system we have a surprising number of databases that don't change at all for days (alongside the ones that change all the time, of course). However, I would like to see an option to include the timestamp if someone wants it. The following patch adds start/stop times for pg_dump and pg_dumpall when verbose output is selected: -- -- PostgreSQL database cluster dump -- Started on 2004-06-04 01:01:35 EDT -- -- -- PostgreSQL database dump -- Started on 2004-06-04 01:01:36 EDT -- -- -- PostgreSQL database dump complete -- Completed on 2004-06-04 01:01:36 EDT -- -- -- PostgreSQL database cluster dump complete -- Completed on 2004-06-04 01:01:36 EDT -- -- 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: doc/src/sgml/ref/pg_dump.sgml === RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/pg_dump.sgml,v retrieving revision 1.70 diff -c -c -r1.70 pg_dump.sgml *** doc/src/sgml/ref/pg_dump.sgml 31 May 2004 13:37:52 - 1.70 --- doc/src/sgml/ref/pg_dump.sgml 4 Jun 2004 04:58:18 - *** *** 403,409 para Specifies verbose mode. This will cause applicationpg_dump/application to output detailed object ! comments in the dump file, and progress messages to standard error. /para /listitem /varlistentry --- 403,410 para Specifies verbose mode. This will cause applicationpg_dump/application to output detailed object ! comments in the dump file, start and stop times, and progress ! messages to standard error. /para /listitem /varlistentry Index: doc/src/sgml/ref/pg_dumpall.sgml === RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/pg_dumpall.sgml,v retrieving revision 1.43 diff -c -c -r1.43 pg_dumpall.sgml *** doc/src/sgml/ref/pg_dumpall.sgml29 Nov 2003 19:51:39 - 1.43 --- doc/src/sgml/ref/pg_dumpall.sgml4 Jun 2004 04:58:18 - *** *** 192,199 listitem para Specifies verbose mode. This will cause ! applicationpg_dumpall/application to print progress ! messages to standard error. /para /listitem /varlistentry --- 192,200 listitem para Specifies verbose mode. This will cause ! applicationpg_dumpall/application to output start and stop ! times in the dump file, and progress messages to standard error. ! It will also enable verbose output in applicationpg_dump/. /para /listitem /varlistentry Index: src/bin/pg_dump/pg_backup_archiver.c === RCS file: /cvsroot/pgsql-server/src/bin/pg_dump/pg_backup_archiver.c,v retrieving revision 1.87 diff -c -c -r1.87 pg_backup_archiver.c *** src/bin/pg_dump/pg_backup_archiver.c19 May 2004 21:21:26 - 1.87 --- src/bin/pg_dump/pg_backup_archiver.c4 Jun 2004 04:58:21 - *** *** 28,33 --- 28,34 #include ctype.h #include errno.h + #include time.h #include unistd.h #include pqexpbuffer.h *** *** 202,208 if (ropt-filename || ropt-compression) sav = SetOutput(AH, ropt-filename, ropt-compression); ! ahprintf(AH, --\n-- PostgreSQL database dump\n--\n\n); /* * Establish important parameter values right away. --- 203,218 if (ropt-filename || ropt-compression) sav = SetOutput(AH, ropt-filename, ropt-compression); ! ahprintf(AH, --\n--
Re: [PATCHES] [HACKERS] pg_dump --comment?
Bruce Momjian [EMAIL PROTECTED] writes: The following patch adds start/stop times for pg_dump and pg_dumpall What happens in a pg_dump -Fc / pg_restore scenario? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
