Re: [PATCHES] Relocatable locale
Bruce Momjian wrote: With no one coming up with a better idea, this applied patch adds PGETC (for pg_service.conf) and PGLOCALE (for locale dir) environment variable processing to libpq. Considering that in other places these locations are referred to as sysconfdir and localdir, it would make sense to name the variables PGSYSCONFDIR and PGLOCALEDIR, so we stick to one set of terms. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[PATCHES] cost_nonsequential_access()
The comment describing cost_nonsequential_access() says that the two functions meet in the middle. They meet at random_page_cost/2, however, not in the middle between 1 and random_page_cost. For random_page_cost 2 the result can be less than 1 for relpages near effective_cache_size. I don't think that this was intended. This patch makes sure that cost_nonsequential_access() is always between 1 and randon_page_cost and the functions meet a (1+random_page_cost)/2. Servus Manfred diff -Ncr ../base/src/backend/optimizer/path/costsize.c src/backend/optimizer/path/costsize.c *** ../base/src/backend/optimizer/path/costsize.c Tue Jun 1 05:02:52 2004 --- src/backend/optimizer/path/costsize.c Tue Jun 8 08:34:27 2004 *** *** 189,199 * for now by assuming we are given an effective_cache_size parameter. * * Given a guesstimated cache size, we estimate the actual I/O cost per page ! * with the entirely ad-hoc equations: *if relpages = effective_cache_size: ! *random_page_cost * (1 - (effective_cache_size/relpages)/2) *if relpages effective_cache_size: ! *1 + (random_page_cost/2-1) * (relpages/effective_cache_size) ** 2 * These give the right asymptotic behavior (= 1.0 as relpages becomes * small, = random_page_cost as it becomes large) and meet in the middle * with the estimate that the cache is about 50% effective for a relation --- 189,200 * for now by assuming we are given an effective_cache_size parameter. * * Given a guesstimated cache size, we estimate the actual I/O cost per page ! * with the entirely ad-hoc equations (writing rpc for random_page_cost and ! * relsize for relpages/effective_cache_size): *if relpages = effective_cache_size: ! *rpc - (rpc-1)/2 * 1/relsize *if relpages effective_cache_size: ! *1 + (rpc-1)/2 * relsize * These give the right asymptotic behavior (= 1.0 as relpages becomes * small, = random_page_cost as it becomes large) and meet in the middle * with the estimate that the cache is about 50% effective for a relation *** *** 213,221 relsize = relpages / effective_cache_size; if (relsize = 1.0) ! return random_page_cost * (1.0 - 0.5 / relsize); else ! return 1.0 + (random_page_cost * 0.5 - 1.0) * relsize * relsize; } /* --- 214,222 relsize = relpages / effective_cache_size; if (relsize = 1.0) ! return random_page_cost - (random_page_cost - 1.0) / 2.0 / relsize; else ! return 1.0 + (random_page_cost - 1.0) / 2.0 * relsize; } /* ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Relocatable locale
Peter Eisentraut wrote: Bruce Momjian wrote: With no one coming up with a better idea, this applied patch adds PGETC (for pg_service.conf) and PGLOCALE (for locale dir) environment variable processing to libpq. Considering that in other places these locations are referred to as sysconfdir and localdir, it would make sense to name the variables PGSYSCONFDIR and PGLOCALEDIR, so we stick to one set of terms. OK, change made. -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Stylistic changes in bufmgr.c
Patch applied. Thanks.
---
Manfred Koizar wrote:
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.cSat Nov 29 20:51:57 2003
--- src/backend/storage/page/bufpage.cWed 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;
Re: [PATCHES] vacuum.c refactoring
Patch applied. Thanks.
---
Manfred Koizar wrote:
. 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();
[PATCHES] fix schema ownership for database owner on first connection
Dear patchers,
Please find attached a patch to fix schema ownership on first connection,
so that non system schemas reflect the database owner.
(1) It adds a new datisinit attribute to pg_database, which tells
whether the database initialization was performed or not.
The documentation is updated accordingly.
(2) This boolean is tested in postinit.c:ReverifyMyDatabase,
and InitializeDatabase is called if necessary.
(3) The routine updates pg_database datisinit, as well as pg_namespace
ownership and acl stuff.
(4) Some validation is added. This part validates for me
(although rules and errors regression tests are broken in current
cvs head, independtly of this patch).
Some questions/comments :
- is the place for the first connection housekeeping updates appropriate?
it seems so from ReverifyMyDatabase comments, but these are only comments.
- it is quite convenient to use SPI_* stuff for this very rare updates,
but I'm not that confident about the issue... On the other hand, the
all-C solution would result in a much longer and less obvious code:-(
- it is unclear to me whether it should be allowed to skip this under
some condition, when the database is accessed in debug mode from
a standalone postgres for instance?
- also I'm wondering how to react (what to do and how to do it) on
errors within or under these initialization. For instance, how to
be sure that the CurrentUser is reset as expected?
Thanks in advance for any comments.
Have a nice day.
--
Fabien.*** ./doc/src/sgml/catalogs.sgml.orig Mon Jun 7 09:08:11 2004
--- ./doc/src/sgml/catalogs.sgmlTue Jun 8 10:14:26 2004
***
*** 1536,1541
--- 1536,1552
/row
row
+ entrystructfielddatisinit/structfield/entry
+ entrytypebool/type/entry
+ entry/entry
+ entry
+False when a database is just created but housekeeping initialization
+tasks are not performed yet. On the first connection, the initialization
+is performed and the boolean is turned to true.
+ /entry
+ /row
+
+ row
entrystructfielddatlastsysoid/structfield/entry
entrytypeoid/type/entry
entry/entry
*** ./src/backend/commands/dbcommands.c.origWed May 26 17:28:40 2004
--- ./src/backend/commands/dbcommands.c Tue Jun 8 10:14:26 2004
***
*** 424,429
--- 424,430
new_record[Anum_pg_database_encoding - 1] = Int32GetDatum(encoding);
new_record[Anum_pg_database_datistemplate - 1] = BoolGetDatum(false);
new_record[Anum_pg_database_datallowconn - 1] = BoolGetDatum(true);
+ new_record[Anum_pg_database_datisinit - 1] = BoolGetDatum(false);
new_record[Anum_pg_database_datlastsysoid - 1] =
ObjectIdGetDatum(src_lastsysoid);
new_record[Anum_pg_database_datvacuumxid - 1] =
TransactionIdGetDatum(src_vacuumxid);
new_record[Anum_pg_database_datfrozenxid - 1] =
TransactionIdGetDatum(src_frozenxid);
*** ./src/backend/utils/adt/acl.c.orig Thu Jun 3 15:05:57 2004
--- ./src/backend/utils/adt/acl.c Tue Jun 8 10:16:16 2004
***
*** 2203,2205
--- 2203,2225
errmsg(unrecognized privilege type: \%s\, priv_type)));
return ACL_NO_RIGHTS; /* keep compiler quiet */
}
+
+ /* acl acl_switch_grantor(acl, oldgrantor, newgrantor);
+ * switch grantor id in aclitem array.
+ * used internally for fixing owner rights in new databases.
+ * must be STRICT.
+ */
+ Datum acl_switch_grantor(PG_FUNCTION_ARGS)
+ {
+ Acl * acls = PG_GETARG_ACL_P_COPY(0);
+ int i,
+ old_grantor = PG_GETARG_INT32(1),
+ new_grantor = PG_GETARG_INT32(2);
+ AclItem * item;
+
+ for (i=0, item=ACL_DAT(acls); iACL_NUM(acls); i++, item++)
+ if (item-ai_grantor == old_grantor)
+ item-ai_grantor = new_grantor;
+
+ PG_RETURN_ACL_P(acls);
+ }
*** ./src/backend/utils/init/postinit.c.origTue Jun 1 10:21:23 2004
--- ./src/backend/utils/init/postinit.c Tue Jun 8 10:23:09 2004
***
*** 50,55
--- 50,109
/*** InitPostgres support ***/
+ #include executor/spi.h
+
+ /* Do housekeeping initializations if required, on first connection.
+ */
+ static void InitializeDatabase(const char * dbname)
+ {
+ /* su */
+ AclId saved_user = GetUserId();
+ SetUserId(1);
+
+ /* Querying in C is nice, but SQL is nicer.
+* This is only done once in a lifetime of the database,
+* so paying for the parser/optimiser cost is not that bad?
+* What if that fails?
+*/
+ SetQuerySnapshot();
+
+ if (SPI_connect() != SPI_OK_CONNECT)
+ ereport(ERROR, (errmsg(SPI_connect failed)));
+
+ if (SPI_exec(UPDATE SystemCatalogName . DatabaseRelationName
+ SET datisinit=TRUE
+ WHERE
Re: [PATCHES] cost_nonsequential_access()
Manfred Koizar [EMAIL PROTECTED] writes: The comment describing cost_nonsequential_access() says that the two functions meet in the middle. They meet at random_page_cost/2, however, not in the middle between 1 and random_page_cost. For random_page_cost 2 the result can be less than 1 for relpages near effective_cache_size. I don't think that this was intended. You're right, I failed to consider that random_page_cost might be less than 2. This patch makes sure that cost_nonsequential_access() is always between 1 and randon_page_cost and the functions meet a (1+random_page_cost)/2. This patch seems to do considerably more violence to the equations than is needed to cover that oversight, though. The old behavior was intentionally nonlinear in relsize; this is not. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] fix schema ownership for database owner on first
Dear Tom, (2) This boolean is tested in postinit.c:ReverifyMyDatabase, and InitializeDatabase is called if necessary. And what happens if multiple backends try to connect at the same time? I took care of that one! There is a lock on the update of pg_database when switching off datisinit. The backend which gets the lock is to update the schema ownership, and others will wait for the lock to be released, and skip the stuff. I don't think I forgot something, but I may be wrong. Also, as I noted I used SPI internally to do that simply with sql. I don't know if this is an issue. (4) Some validation is added. I do not think it's a good idea for the regression tests to do anything to any databases other than regression. Especially not databases with names that might match people's real databases. Oh, you mean calvin and hobbes might use postgresql? ;-) Ok, so I guess I can use regressionuser[123], regression[123] as names in the validation. Writing tests cases is not fun, so I tried to put some fun by using these characters. -- Fabien Coelho - [EMAIL PROTECTED] ---(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] fix schema ownership for database owner on first connection
Fabien COELHO [EMAIL PROTECTED] writes: I do not think it's a good idea for the regression tests to do anything to any databases other than regression. Especially not databases with names that might match people's real databases. Oh, you mean calvin and hobbes might use postgresql? ;-) Ok, so I guess I can use regressionuser[123], regression[123] as names in the validation. Writing tests cases is not fun, so I tried to put some fun by using these characters. I don't really think it's necessary for the regression tests to test this functionality. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] fix schema ownership for database owner on first
Ok, so I guess I can use regressionuser[123], regression[123] as names in the validation. Writing tests cases is not fun, so I tried to put some fun by using these characters. I don't really think it's necessary for the regression tests to test this functionality. Hummm... an interesting view, indeed. It fits neither my experience of programming nor my experience of computer security;-) It taught me that anything which is not tested does not work or will not work later on because someone will break some assumption. On the other hand, I understand that heavy test on make check are not necessary. So maybe some make big_check or the like? -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] cost_nonsequential_access()
On Tue, 08 Jun 2004 11:13:43 -0400, Tom Lane [EMAIL PROTECTED] wrote: This patch seems to do considerably more violence to the equations than is needed to cover that oversight, though. The old behavior was intentionally nonlinear in relsize; this is not. The comment says entirely ad-hoc and I didn't see a particular reason why the lower half should be nonlinear in relsize while the upper half is linear in 1/relsize. So I opted for the more esthetic symmetrical function. :-) http://www.pivot.at/pg/costsize.jpg original http://www.pivot.at/pg/costsize_2.jpg nonlinear/linear http://www.pivot.at/pg/costsize_3a.jpg nonlinear http://www.pivot.at/pg/costsize_3b.jpg linear I don't have a strong opinion for either relsize or relsize^2. So please add * relsize or / relsize as appropriate before you apply (if you intend to apply). Servus Manfred ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] cost_nonsequential_access()
Manfred Koizar [EMAIL PROTECTED] writes: On Tue, 08 Jun 2004 11:13:43 -0400, Tom Lane [EMAIL PROTECTED] wrote: This patch seems to do considerably more violence to the equations than is needed to cover that oversight, though. The old behavior was intentionally nonlinear in relsize; this is not. The comment says entirely ad-hoc and I didn't see a particular reason why the lower half should be nonlinear in relsize while the upper half is linear in 1/relsize. Incremental changes in the relsize fraction are not going to change the cost much except near 1, so I was after a curve that went like this (pardon the crude artwork): rpc*** *** ** cost * * * ** 1.0 * 0 1large relsize fraction I don't think replacing the lower half of this with a straight line segment is an improvement. Possibly the relsize axis ought to be measured on a log scale, or something like that, but that didn't seem to work nicely when relsize approaches zero. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
Magnus Hagander wrote:
Specifically about the logs, I still think there is a lot of value to
being able to read the logs remotely even if you can't restart
postmaster.
Since I believe that retrieving the logs easily without server file
access is a feature that's welcomed by many users, here's my proposal.
The attached diff will
- add a guc-variable log_filename
- extend log_destination to accept the keyword 'file'
- elog to that file if configured
- provide two functions pg_logfile_length() and pg_logfile to obtain the
contents.
int4 pg_logfile_length()
cstring pg_logfile(int4 size, int4 position)
size (may be null meaning max) is the chunk size (max: currently 5)
position (may be null meaning -size) is the start position; positive
counting from log file start, negative from end.
Regards,
Andreas
Index: backend/postmaster/postmaster.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v
retrieving revision 1.402
diff -u -r1.402 postmaster.c
--- backend/postmaster/postmaster.c 3 Jun 2004 02:08:03 - 1.402
+++ backend/postmaster/postmaster.c 8 Jun 2004 18:07:30 -
@@ -532,6 +532,9 @@
/* If timezone is not set, determine what the OS uses */
pg_timezone_initialize();
+/* open alternate logfile, if any */
+ LogFileOpen();
+
#ifdef EXEC_BACKEND
write_nondefault_variables(PGC_POSTMASTER);
#endif
Index: backend/storage/ipc/ipc.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/storage/ipc/ipc.c,v
retrieving revision 1.87
diff -u -r1.87 ipc.c
--- backend/storage/ipc/ipc.c 12 Dec 2003 18:45:09 - 1.87
+++ backend/storage/ipc/ipc.c 8 Jun 2004 18:07:31 -
@@ -111,6 +111,8 @@
on_proc_exit_list[on_proc_exit_index].arg);
elog(DEBUG3, exit(%d), code);
+
+ LogFileClose();
exit(code);
}
Index: backend/utils/adt/misc.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/adt/misc.c,v
retrieving revision 1.34
diff -u -r1.34 misc.c
--- backend/utils/adt/misc.c2 Jun 2004 21:29:29 - 1.34
+++ backend/utils/adt/misc.c8 Jun 2004 18:07:36 -
@@ -103,3 +103,64 @@
{
PG_RETURN_INT32(pg_signal_backend(PG_GETARG_INT32(0),SIGINT));
}
+
+Datum pg_logfile_length(PG_FUNCTION_ARGS)
+{
+ extern FILE *logfile; // in elog.c
+
+ if (logfile)
+ PG_RETURN_INT32(ftell(logfile));
+ PG_RETURN_INT32(0);
+}
+
+
+#define MAXLOGFILECHUNK 5
+Datum pg_logfile(PG_FUNCTION_ARGS)
+{
+ size_t size=MAXLOGFILECHUNK;
+ char *buf=0;
+ size_t nbytes;
+
+ char *filename = LogFileName();
+ if (filename)
+ {
+ if (!PG_ARGISNULL(0))
+ size = PG_GETARG_INT32(0);
+ if (size MAXLOGFILECHUNK)
+ {
+ size = MAXLOGFILECHUNK;
+ ereport(WARNING,
+ (errcode(ERRCODE_OUT_OF_MEMORY),
+errmsg(Maximum size is %d.,
MAXLOGFILECHUNK)));
+ }
+
+ FILE *f=fopen(filename, r);
+ if (f)
+ {
+ if (PG_ARGISNULL(1))
+ fseek(f, -size, SEEK_END);
+ else
+ {
+ long pos = PG_GETARG_INT32(1);
+ if (pos = 0)
+ fseek(f, pos, SEEK_SET);
+ else
+ fseek(f, pos, SEEK_END);
+ }
+ buf = palloc(size+1);
+ nbytes = fread(buf, 1, size, f);
+ buf[nbytes] = 0;
+
+ fclose(f);
+ }
+ else
+ {
+ ereport(WARNING,
+ (errcode(ERRCODE_NO_DATA),
+errmsg(Could not open log file %s.,
filename)));
+ }
+ free(filename);
+ }
+
+ PG_RETURN_CSTRING(buf);
+}
Index: backend/utils/error/elog.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/error/elog.c,v
retrieving revision 1.140
diff -u -r1.140 elog.c
--- backend/utils/error/elog.c 3 Jun 2004 02:08:04 - 1.140
+++ backend/utils/error/elog.c 8 Jun 2004 18:07:39 -
@@ -71,8 +71,10 @@
PGErrorVerbosity Log_error_verbosity = PGERROR_VERBOSE;
char *Log_line_prefix = NULL; /* format for extra log line info */
unsigned int Log_destination = LOG_DESTINATION_STDERR;
+char *Log_filename = NULL;
bool
Re: [PATCHES] pg_autovacuum integration proof of concept patch
Hi Matthew, What have you done specifically? FYI, I will have the GUC variables done done today or tomorrow, and I have started on the new system tables already. Almost everything. In a couple of days it will be done, then I send it for review. -- Euler Taveira de Oliveira euler (at) ufgnet.ufg.br Desenvolvedor Web e Administrador de Sistemas UFGNet - Universidade Federal de Goiás ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] cost_nonsequential_access()
On Tue, 08 Jun 2004 13:13:01 -0400, Tom Lane [EMAIL PROTECTED] wrote: Possibly the relsize axis ought to be measured on a log scale, or something like that, but that didn't seem to work nicely when relsize approaches zero. In my experiments I used log(relsize) on the x axis, and I don't think that the graph looks unpleasant for small relsize. My thought was (and is) that we are much more interested in whether relpages is 1/100, 1/10, 1, 10, 100 times effective_cache_size than whether it is relpages +/- 1000, 2000, 3000, ... I played around with some numbers that could be considered fairly realistic. You might want to look at the graphs I linked to in the previous message or download http://www.pivot.at/pg/costsize.sxc. But I think we are wasting too much effort. The graphs don't look too different, whether you use relsize or relsize^2. Maybe relsize^3 is optimal? Nobody knows. The important part of the patch is that the result is scaled and shifted into the range 1 to random_page_cost. Whatever you decide to do is ok with me. Servus Manfred ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] fix schema ownership for database owner on first connection
Ok, so I guess I can use regressionuser[123], regression[123] as names in the validation. Writing tests cases is not fun, so I tried to put some fun by using these characters. I don't really think it's necessary for the regression tests to test this functionality. Once this machinery is in...can we use it to safely remove users? Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
