[PATCHES] Add GUC setting to make created tables default to WITHOUT
I have attaches a patch against 7.4.0 which contains the implementation
of the following todo item.
Log message:
Add:
* Add GUC setting to make created tables
default to WITHOUT OIDS
Cheers,
Hans
--
Cybertec Geschwinde u Schoenig
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/2952/30706 or +43/660/816 40 77
www.cybertec.at, www.postgresql.at, kernel.cybertec.at
*** ./doc/src/sgml/ref/create_table.sgml.orig 2003-11-19 18:28:41.0 +0100
--- ./doc/src/sgml/ref/create_table.sgml2003-11-19 18:30:12.0 +0100
***
*** 243,252
listitem
para
This optional clause specifies whether rows of the new table
! should have OIDs (object identifiers) assigned to them. The
! default is to have OIDs. (If the new table inherits from any
tables that have OIDs, then literalWITH OIDS/ is forced even
! if the command says literalWITHOUT OIDS/.)
/para
para
--- 243,254
listitem
para
This optional clause specifies whether rows of the new table
! should have OIDs (object identifiers) assigned to them. The
! default behaviour of PostgrSQL can be defined with the help of a
! runtime variable (table_with_oid).
! If the new table inherits from any
tables that have OIDs, then literalWITH OIDS/ is forced even
! if the command says literalWITHOUT OIDS/.
/para
para
*** ./src/backend/commands/tablecmds.c.orig 2003-11-19 10:24:13.0 +0100
--- ./src/backend/commands/tablecmds.c 2003-11-19 18:23:13.0 +0100
***
*** 52,57
--- 52,58
#include utils/acl.h
#include utils/builtins.h
#include utils/fmgroids.h
+ #include utils/guc.h
#include utils/inval.h
#include utils/lsyscache.h
#include utils/relcache.h
***
*** 250,257
*/
descriptor = BuildDescForRelation(schema);
! descriptor-tdhasoid = (stmt-hasoids || parentHasOids);
!
if (old_constraints != NIL)
{
ConstrCheck *check = (ConstrCheck *) palloc(length(old_constraints) *
--- 251,273
*/
descriptor = BuildDescForRelation(schema);
! /* it is time to decide whether the table we are about to
!* generate contains an OID or not. several cases have to be
!* taken into consideration. we will need an oid if:
!* a. the parent table has an oid
!* b. the user has not defined WITH/OUT OID explicity but has
!* set table_with_oid to true
!* c. the user tells us to use an OID - no matter if
!* table_with_oid is set or not
!*/
! if (parentHasOids || stmt-hasoids == WITH_OID ||
! (stmt-hasoids == EMPTY_OID table_with_oid == true))
! {
! descriptor-tdhasoid = true;
! }
! else
! descriptor-tdhasoid = false;
!
if (old_constraints != NIL)
{
ConstrCheck *check = (ConstrCheck *) palloc(length(old_constraints) *
*** ./src/backend/nodes/outfuncs.c.orig 2003-11-19 10:37:59.0 +0100
--- ./src/backend/nodes/outfuncs.c 2003-11-19 10:38:14.0 +0100
***
*** 1101,1107
WRITE_NODE_FIELD(tableElts);
WRITE_NODE_FIELD(inhRelations);
WRITE_NODE_FIELD(constraints);
! WRITE_BOOL_FIELD(hasoids);
WRITE_ENUM_FIELD(oncommit, OnCommitAction);
}
--- 1101,1107
WRITE_NODE_FIELD(tableElts);
WRITE_NODE_FIELD(inhRelations);
WRITE_NODE_FIELD(constraints);
! WRITE_INT_FIELD(hasoids);
WRITE_ENUM_FIELD(oncommit, OnCommitAction);
}
*** ./src/backend/parser/gram.y.orig2003-11-19 10:54:02.0 +0100
--- ./src/backend/parser/gram.y 2003-11-19 16:21:17.0 +0100
***
*** 234,240
%type defeltcreatefunc_opt_item
%type typnamfunc_arg func_return func_type aggr_argtype
! %type boolean opt_arg TriggerForType OptTemp OptWithOids
%type oncommit OnCommitOption
%type list for_update_clause opt_for_update_clause update_list
--- 234,241
%type defeltcreatefunc_opt_item
%type typnamfunc_arg func_return func_type aggr_argtype
! %type ival OptWithOids
! %type boolean opt_arg TriggerForType OptTemp
%type oncommit OnCommitOption
%type list for_update_clause opt_for_update_clause update_list
***
*** 1840,1848
;
OptWithOids:
! WITH OIDS
{ $$ = TRUE; }
! | WITHOUT OIDS
{ $$ = FALSE; }
! | /*EMPTY*/
{ $$ = TRUE; }
;
OnCommitOption: ON COMMIT DROP { $$ =
Re: [pgsql-hackers-win32] [PATCHES] SRA Win32 sync() code
On Monday 17 November 2003 11:16, Bruce Momjian wrote: Tom Lane wrote: Do we know that having the background writer fsync a file that was written by a backend cause all the data to fsync? I think I could write a program to test this by timing each of these tests: That might prove something about the particular platform you tested it on; but it would not speak to the real problem, which is what we can assume is true on every platform... The attached program does test if fsync can be used on a file descriptor after the file is closed and then reopened. I see: write 0.000613 write fsync 0.001727 write, close fsync 0.001633 ArchLinux, maxtor IDE HDD, write cache enabled. [EMAIL PROTECTED] tmp]$ gcc -o test_fsync test_fsync.c [EMAIL PROTECTED] tmp]$ ./test_fsync write 0.002403 write fsync 0.009423 write, close fsync 0.006457 [EMAIL PROTECTED] tmp]$ uname -a Linux daithan 2.4.21 #1 SMP Tue Jul 8 19:41:52 PDT 2003 i686 unknown Anyway, if we find all our platforms can pass this test, we might be able to allow backends to do their own writes and just record the file name somewhere for the checkpointer to fsync. It also shows write/fsync was 3x slower than simple write. Does anyone have a platform where the last duration is significantly different from the middle timing? Does 30% difference above count as significant? Assuming fsync on a file descriptor flushes dirty buffers of that file, from all processes, would following be sufficient? 1. Open WAL with O_SYNC|O_DIRECT (Later whereever possible) And issue fsync on WAL files whenever required. 2. Use regular writes for data files and fsync them in background. May be if background process is the only one that issues any fsync on data files, that could maximize overall system throughput. Say, all backends write to a datafile and signal the background writer, that they are blocked on this write to complete. BGWriter could chunk all such requests and flush them/fsync when there is enough disk activity. Hopefully none of them would be stalled for too long. That way slowest part of the system i.e the disk will be kept full of load. Besides since WAL writes are synchornous, backgrounds can safely push a write and move to further business, most of the times. I guess BGWriter has to fsync the data files anyways to recycle a WAL segment. In idle conditions, this mechanism should not be a problem. Just a thought. Does this take care of sync? I am keeping this discussion on patches because of the C program attachment. I dropped win32 list. I am not subscribed to it. Just getting thread out of it. I will write a short program which writes to a file in different processes and attempts to fsync them from only one. Let's see what that turns out. Shridhar ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-hackers-win32] [PATCHES] SRA Win32 sync() code
On Mon, Nov 17, 2003 at 12:46:34AM -0500, Bruce Momjian wrote: Tom Lane wrote: Do we know that having the background writer fsync a file that was written by a backend cause all the data to fsync? I think I could write a program to test this by timing each of these tests: That might prove something about the particular platform you tested it on; but it would not speak to the real problem, which is what we can assume is true on every platform... The attached program does test if fsync can be used on a file descriptor after the file is closed and then reopened. I see: write 0.000613 write fsync 0.001727 write, close fsync 0.001633 Does anyone have a platform where the last duration is significantly different from the middle timing? write 0.002807 write fsync 0.015248 write, close fsync 0.004696 This is a Linux 2.6.0-test5 on an old IDE disk. The results change alot. An other result shows: write 0.002737 write fsync 0.006658 write, close fsync 0.008431 The first time is stable, the other 2 aren't. Averagly write fsync would be about twice as big/slow as write, close fsync. PS: Please specify some modes when creating files. Kurt ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-hackers-win32] [PATCHES] SRA Win32 sync() code
Shridhar Daithankar wrote: Does 30% difference above count as significant? No. It's Linux, we can look at the sources: there is no per-fd cache, the page cache is global. Thus fsync() syncs the whole cache to disk. A problem could only occur if the file cache is not global - perhaps a per-node file cache on NUMA systems - IRIX on an Origin 2000 cluster or something similar. But as I read the unix spec, fsync is guaranteed to sync all data to disk: Draft 6 of the posix-200x spec: SIO If _POSIX_SYNCHRONIZED_IO is defined, the fsync( ) function shall force all currently queued I/O operations associated with the file indicated by file descriptor fildes to the synchronized I/O completion state. All I/O operations shall be completed as defined for synchronized I/O file integrity completion. All I/O operations associated with the file, not all operations associated with the file descriptor. -- Manfred ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[PATCHES] Fwd: quick ECPG doco change
No objections from interfaces, can this be applied? Regards, Philip. -- Forwarded Message -- Subject: quick ECPG doco change Date: Wed, 19 Nov 2003 11:00:34 +1100 From: Philip Yarra [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi, this doco patch is a quick one to add explicit mention of the need for the AT clause in threaded ECPG applications. Does this sound okay? Bruce, yes, I do intend to contribute more than this, but at least this will stop some confusion in the meantime. Regards, Philip Yarra. Index: ecpg.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/ecpg.sgml,v retrieving revision 1.54 diff -c -r1.54 ecpg.sgml *** ecpg.sgml 12 Nov 2003 22:47:47 - 1.54 --- ecpg.sgml 18 Nov 2003 23:20:51 - *** *** 353,358 --- 353,365 /programlisting This option is particularly suitable if the application needs to use several connections in mixed order. + /para + + para + If your application uses multiple threads of execution, they cannot share a + connection concurrently. You must either explicitly control access to the connection + (using mutexes) or use a connection for each thread. If each thread uses its own connection, + you will need to use the AT clause to specify which connection the thread will use. /para para --- --- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[PATCHES] internationalization of initdb
Hi, I just enable support for internationalization of initdb. I used the same style from scripts. The files need to be put in initdb directory (nls.mk and po/pt_BR.po). The patch was made under CVS HEAD. -- Euler Taveira de Oliveira euler (at) ufgnet.ufg.br Desenvolvedor Web e Administrador de Sistemas UFGNet - Universidade Federal de Goiás patch_initdb.tgz Description: Binary data ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] internationalization of initdb
heh. Now I can cross that off my todo list :-) Euler Taveira de Oliveira wrote: Hi, I just enable support for internationalization of initdb. I used the same style from scripts. The files need to be put in initdb directory (nls.mk and po/pt_BR.po). The patch was made under CVS HEAD. ---(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
[PATCHES] cleanup execTuples.c
This patch refactors execTuples.c in two ways:
(1) ExecInitXXXResultTupleSlot() used a macro to avoid some
duplicated code, whereas calling ExecInitExtraTupleSlot() would
make the code more clear.
(2) ExecTypeFromTL() and ExecCleanTypeFromTL() duplicated a bunch
of code; I added a new function ExecTypeFromTLInternal() and
re-implemented these functions in terms of calls to it.
As a result, ExecInitScanTupleSlot(), ExecInitResultTupleSlot(),
ExecTypeFromTL(), and ExecCleanTypeFromTL() are now all trivial
(1 line) functions. I could have replaced these with macros, but I
didn't: does anyone thinks that would be worth doing?
-Neil
Index: src/backend/executor/execTuples.c
===
RCS file: /var/lib/cvs/pgsql-server/src/backend/executor/execTuples.c,v
retrieving revision 1.72
diff -c -r1.72 execTuples.c
*** src/backend/executor/execTuples.c 29 Sep 2003 18:22:48 - 1.72
--- src/backend/executor/execTuples.c 20 Nov 2003 02:42:17 -
***
*** 112,117
--- 112,119
#include executor/executor.h
#include utils/lsyscache.h
+ static TupleDesc ExecTypeFromTLInternal(List *targetList,
+ bool hasoid, bool skipjunk);
/*
* tuple table create/delete functions
***
*** 469,481
* is used for initializing special-purpose slots.
*
*/
- #define INIT_SLOT_DEFS \
- TupleTable tupleTable; \
- TupleTableSlot* slot
-
- #define INIT_SLOT_ALLOC \
- tupleTable = (TupleTable) estate-es_tupleTable; \
- slot = ExecAllocTableSlot(tupleTable);
/*
* ExecInitResultTupleSlot
--- 471,476
***
*** 484,492
void
ExecInitResultTupleSlot(EState *estate, PlanState *planstate)
{
! INIT_SLOT_DEFS;
! INIT_SLOT_ALLOC;
! planstate-ps_ResultTupleSlot = slot;
}
/*
--- 479,485
void
ExecInitResultTupleSlot(EState *estate, PlanState *planstate)
{
! planstate-ps_ResultTupleSlot = ExecInitExtraTupleSlot(estate);
}
/*
***
*** 496,504
void
ExecInitScanTupleSlot(EState *estate, ScanState *scanstate)
{
! INIT_SLOT_DEFS;
! INIT_SLOT_ALLOC;
! scanstate-ss_ScanTupleSlot = slot;
}
/*
--- 489,495
void
ExecInitScanTupleSlot(EState *estate, ScanState *scanstate)
{
! scanstate-ss_ScanTupleSlot = ExecInitExtraTupleSlot(estate);
}
/*
***
*** 508,516
TupleTableSlot *
ExecInitExtraTupleSlot(EState *estate)
{
! INIT_SLOT_DEFS;
! INIT_SLOT_ALLOC;
! return slot;
}
/*
--- 499,505
TupleTableSlot *
ExecInitExtraTupleSlot(EState *estate)
{
! return ExecAllocTableSlot(estate-es_tupleTable);
}
/*
***
*** 560,593
TupleDesc
ExecTypeFromTL(List *targetList, bool hasoid)
{
! TupleDesc typeInfo;
! List *tlitem;
! int len;
!
! /*
! * allocate a new typeInfo
! */
! len = ExecTargetListLength(targetList);
! typeInfo = CreateTemplateTupleDesc(len, hasoid);
!
! /*
! * scan list, generate type info for each entry
! */
! foreach(tlitem, targetList)
! {
! TargetEntry *tle = lfirst(tlitem);
! Resdom *resdom = tle-resdom;
!
! TupleDescInitEntry(typeInfo,
! resdom-resno,
! resdom-resname,
! resdom-restype,
! resdom-restypmod,
! 0,
! false);
! }
!
! return typeInfo;
}
/*
--- 549,555
TupleDesc
ExecTypeFromTL(List *targetList, bool hasoid)
{
! return ExecTypeFromTLInternal(targetList, hasoid, false);
}
/*
***
*** 599,628
TupleDesc
ExecCleanTypeFromTL(List *targetList, bool hasoid)
{
! TupleDesc typeInfo;
! List *tlitem;
! int len;
! int cleanresno;
! /*
! * allocate a new typeInfo
! */
! len = ExecCleanTargetListLength(targetList);
typeInfo = CreateTemplateTupleDesc(len, hasoid);
! /*
! * scan list, generate type info for each entry
! */
! cleanresno = 1;
! foreach(tlitem, targetList)
{
! TargetEntry *tle = lfirst(tlitem);
! Resdom *resdom = tle-resdom;
! if (resdom-resjunk)
continue;
TupleDescInitEntry(typeInfo,
! cleanresno++,
resdom-resname,
resdom-restype,
resdom-restypmod,
--- 561,592
TupleDesc
ExecCleanTypeFromTL(List *targetList, bool hasoid)
{
! return ExecTypeFromTLInternal(targetList, hasoid, true);
! }
! static TupleDesc
! ExecTypeFromTLInternal(List *targetList, bool hasoid, bool skipjunk)
! {
! TupleDesc typeInfo;
! List *l;
! int len;
! int cur_resno = 1;
!
! if (skipjunk)
! len =
Re: [PATCHES] Add GUC setting to make created tables default to
Hans-Jürgen Schönig [EMAIL PROTECTED] writes: I have attaches a patch against 7.4.0 which contains the implementation of the following todo item. I sent a proposal for this functionality to -hackers a month or so ago, and implemented it a couple days later -- it was sent to pgsql-patches, and is in the queue of items to be applied to 7.5. -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
