[PATCHES] Unused MMCacheLock
Hi, Are there any reasons MMCacheLock has been left yet? Did we forget to remove it when mm.c was removed? *** lwlock.hSat Jun 18 07:32:50 2005 --- lwlock-nomm.h Wed Jul 27 16:18:42 2005 *** *** 33,39 ProcArrayLock, SInvalLock, FreeSpaceLock, - MMCacheLock, WALInsertLock, WALWriteLock, ControlFileLock, --- 33,38 --- ITAGAKI Takahiro NTT Cyber Space Laboratories ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] O_DIRECT for WAL writes
ITAGAKI Takahiro wrote: Thanks for reviewing! But the patch does not work on HEAD, because of the changes in BootStrapXLOG(). I send the patch with a fix for it. Thanks. If you are doing fsync(), I don't see how O_DIRECT makes any sense because O_DIRECT is writing to disk on every write, and then what is the fsync() actually doing. It's depends on OSes. Manpage of Linux says, http://linux.com.hk/PenguinWeb/manpage.jsp?name=opensection=2 File I/O is done directly to/from user space buffers. The I/O is synchronous, i.e., at the completion of the read(2) or write(2) system call, data is **guaranteed to have been transferred**. But manpage of FreeBSD says, http://www.manpages.info/freebsd/open.2.html O_DIRECT may be used to minimize or eliminate the cache effects of read- ing and writing. The system will attempt to avoid caching the data you read or write. If it cannot avoid caching the data, it will **minimize the impact the data has on the cache**. In my understanding, the completion of write() with O_DIRECT does not always assure an actual write. So there may be difference between O_DIRECT+O_SYNC and O_DIRECT+fsync(), but I think that is not very often. Yes, I do remember that. I know we _need_ fsync when using O_DIRECT, but the downside of O_DIRECT (force every write to disk) is the same as O_SYNC, so it seems if we are using O_DIRECT, we might as well use O_SYNC too and skip the fsync(). I will add a comment mentioning this. What I did was to add O_DIRECT unconditionally for all uses of O_SYNC and O_DSYNC, so it is automatically used in those cases. And of course, if your operating system doens't support O_DIRECT, it isn't used. I agree with your way, where O_DIRECT is automatically used. I bet the combination of O_DIRECT and O_SYNC is always better than the case O_SYNC only used. OK. -- 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 5: don't forget to increase your free space map settings
Re: [PATCHES] Unused MMCacheLock
ITAGAKI Takahiro [EMAIL PROTECTED] writes: Did we forget to remove it when mm.c was removed? Yup :-(. Thanks for catching it. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] small SPI docs correction
I've had this small patch in my local tree for a while. It documents new commands which may make an SPI call fail. -- Alvaro Herrera (alvherre[a]alvh.no-ip.org) Maybe there's lots of data loss but the records of data loss are also lost. (Lincoln Yeoh) Index: doc/src/sgml/spi.sgml === RCS file: /home/alvherre/cvs/pgsql/doc/src/sgml/spi.sgml,v retrieving revision 1.41 diff -c -r1.41 spi.sgml *** doc/src/sgml/spi.sgml 2 May 2005 00:37:06 - 1.41 --- doc/src/sgml/spi.sgml 27 Jul 2005 15:44:26 - *** *** 537,544 termsymbolSPI_ERROR_TRANSACTION/symbol/term listitem para !if commandBEGIN/, commandCOMMIT/, or !commandROLLBACK/ was attempted /para /listitem /varlistentry --- 537,551 termsymbolSPI_ERROR_TRANSACTION/symbol/term listitem para ! if any command involving transaction manipulation was attempted ! (commandBEGIN/, ! commandCOMMIT/, ! commandROLLBACK/, ! commandSAVEPOINT/, ! commandPREPARE TRANSACTION/, ! commandCOMMIT PREPARED/, ! commandROLLBACK PREPARED/, ! or any variant thereof) /para /listitem /varlistentry ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Bitmap index AM
Hi again. Here's an updated patch, that fixes several bugs and is synced with HEAD. -- Victor Y. Yegorov diff-20050727-2.gz Description: Binary data ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] psql patch for displaying the username when asking password
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. I made this adjustment in the applied version. Thanks. -- 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] [HACKERS] Autovacuum loose ends
On Mon, Jul 25, 2005 at 09:31:15AM +0800, Christopher Kings-Lynne wrote: We have to consider what happens at stat reset -- AFAICS there's no problem, because as soon as the table sees some activity, it will be picked up by pgstat. However, it would be bad if stats are reset right after some heavy activity on a table. Maybe the only thing we need is documentation. What's the use-case for having the stat reset feature at all? I believe I was the root cause of the pg_stat_reset() function. The idea at the time was that if you decide to do a round of index optimisation, you want to be able to search for unused indexes and heavily seq. scanned tables. If you reset the stats you have 'clean' data to work with. For instance, you can get 24 hours of clean stats data. Ok, so there's a reason for having a manual stat-reset. However what's the rationale for cleaning stats at postmaster start? In fact I think it's actively bad because you lose any data you had before postmaster stop/crash. -- Alvaro Herrera (alvherre[a]alvh.no-ip.org) I personally became interested in Linux while I was dating an English major who wouldn't know an operating system if it walked up and bit him. (Val Henson) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] PLPGSQL OID Bug
This patch will resolve the oid retrieval bugs from
plpgsql. There are however several other places where isnull=false was removed
and replaced with isnull which may also need to be corrected.
Kevin McArthur
StormTide Digital Studios Inc.
Index:
src/pl/plpgsql/src/pl_exec.c===RCS
file: /projects/cvsroot/pgsql/src/pl/plpgsql/src/pl_exec.c,vretrieving
revision 1.149diff -c -r1.149 pl_exec.c***
src/pl/plpgsql/src/pl_exec.c 26 Jun
2005 22:05:42 - 1.149---
src/pl/plpgsql/src/pl_exec.c 27 Jul
2005 20:38:25 -** 1143,1149
{
PLpgSQL_diag_item *diag_item =
(PLpgSQL_diag_item *)
lfirst(lc);
PLpgSQL_datum
*var;!
bool
isnull;
if (diag_item-target =
0)
continue;--- 1143,1149
{
PLpgSQL_diag_item *diag_item =
(PLpgSQL_diag_item *)
lfirst(lc);
PLpgSQL_datum
*var;!
bool
isnull=false;
if (diag_item-target =
0)
continue;
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCHES] [HACKERS] Autovacuum loose ends
Alvaro Herrera [EMAIL PROTECTED] writes: Ok, so there's a reason for having a manual stat-reset. However what's the rationale for cleaning stats at postmaster start? In fact I think it's actively bad because you lose any data you had before postmaster stop/crash. We probably *should* drop the stats file if any WAL replay activity occurs, because the stats file could be out of sync with reality --- this is particularly important in a PITR recovery situation, where the stats file is likely to be WAY out of sync. (Maybe only clobber it in PITR mode?) I agree that the argument for doing it in a normal restart is pretty weak. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] AIX - pgport/contrib resolution
The comment in regress/GNUmakefile about the pgport symbols not being found got me thinking about why that might be the case. I finally noticed that when we are building the postgres.imp file, we are not pulling in the pgport symbols, since they are not being linked into the local SUBSYS.o before running mkldexport.sh. I noticed that windows has a similar dilemma when creating the .def file. The solution was to suck in libpgport.a before we extract all the symbols out. A patch to that affect is attached. backend/Makefile - fix rule for AIX regarding pgport files port/getopt_long - needed to have optreset wrapped in HAVE_INT_OPTRESET regress/GNUmakefile - hopefully I backed out the change to bring in pgsleep well enough With these changes in place, I was able to complete a full build and test suite (including contrib). Thanks, -rocco aix-pgport-contrib.patch Description: aix-pgport-contrib.patch ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] PLPGSQL OID Bug
Kevin McArthur [EMAIL PROTECTED] writes: This patch will resolve the oid retrieval bugs from plpgsql. Applied. There are however several other places where isnull=false was removed and replaced with isnull which may also need to be corrected. The other spots seem to be OK. Thanks for the report and fix! regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] AIX - pgport/contrib resolution
Rocco Altier [EMAIL PROTECTED] writes: The comment in regress/GNUmakefile about the pgport symbols not being found got me thinking about why that might be the case. I finally noticed that when we are building the postgres.imp file, we are not pulling in the pgport symbols, since they are not being linked into the local SUBSYS.o before running mkldexport.sh. Ah-hah! Good detective work. A patch to that affect is attached. Will apply this in a bit. 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] PLPGSQL OID Bug
Tom Lane wrote: The other spots seem to be OK. Thanks for the report and fix! Woops, my apologies for introducing the bug. In general I think it's worth removing explicit initialization of out parameters unless that initialization is actually needed. I thought I had checked that `isnull=false' wasn't needed, but obviously I missed a case. BTW, is there a reason why exec_cast_value() and friends take a bool *, rather than a bool? -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
Re: [PATCHES] PLPGSQL OID Bug
Neil Conway [EMAIL PROTECTED] writes: BTW, is there a reason why exec_cast_value() and friends take a bool *, rather than a bool? I think the reason is that it's both an input and an output parameter, to handle the case where the cast function returns NULL. This is obviously a pretty bug-prone convention, however, and so maybe we should rethink it. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] AIX - pgport/contrib resolution
Rocco Altier [EMAIL PROTECTED] writes: I finally noticed that when we are building the postgres.imp file, we are not pulling in the pgport symbols, since they are not being linked into the local SUBSYS.o before running mkldexport.sh. The solution was to suck in libpgport.a before we extract all the symbols out. A patch to that affect is attached. I've applied this in a modified form: it seemed better to put libpgport.a into $(OBJS), which not only gets it into the symbols file but makes it a dependency that will force rebuilding of the backend executable. Give me a holler if this doesn't work :-( port/getopt_long - needed to have optreset wrapped in HAVE_INT_OPTRESET regress/GNUmakefile - hopefully I backed out the change to bring in pgsleep well enough With these changes in place, I was able to complete a full build and test suite (including contrib). Pushed these in too ... hope to see a green board on the AIX buildfarm machines soon. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] PLPGSQL OID Bug
Tom Lane wrote:
I think the reason is that it's both an input and an output parameter,
to handle the case where the cast function returns NULL.
The only reference to `isnull' in the body of exec_cast_value() is:
if (!*isnull)
{
/* ... */
}
i.e. it is never referenced again, let alone written through. Barring
any objections I'll apply the attached patch tomorrow.
-Neil
Index: src/pl/plpgsql/src/pl_exec.c
===
RCS file: /var/lib/cvs/pgsql/src/pl/plpgsql/src/pl_exec.c,v
retrieving revision 1.150
diff -c -r1.150 pl_exec.c
*** src/pl/plpgsql/src/pl_exec.c 28 Jul 2005 00:26:30 - 1.150
--- src/pl/plpgsql/src/pl_exec.c 28 Jul 2005 05:29:21 -
***
*** 173,182
FmgrInfo *reqinput,
Oid reqtypioparam,
int32 reqtypmod,
! bool *isnull);
static Datum exec_simple_cast_value(Datum value, Oid valtype,
Oid reqtype, int32 reqtypmod,
! bool *isnull);
static void exec_init_tuple_store(PLpgSQL_execstate *estate);
static bool compatible_tupdesc(TupleDesc td1, TupleDesc td2);
static void exec_set_found(PLpgSQL_execstate *estate, bool state);
--- 173,182
FmgrInfo *reqinput,
Oid reqtypioparam,
int32 reqtypmod,
! bool isnull);
static Datum exec_simple_cast_value(Datum value, Oid valtype,
Oid reqtype, int32 reqtypmod,
! bool isnull);
static void exec_init_tuple_store(PLpgSQL_execstate *estate);
static bool compatible_tupdesc(TupleDesc td1, TupleDesc td2);
static void exec_set_found(PLpgSQL_execstate *estate, bool state);
***
*** 356,362
(func-fn_retinput),
func-fn_rettypioparam,
-1,
! fcinfo-isnull);
/*
* If the function's return type isn't by value, copy the value
--- 356,362
(func-fn_retinput),
func-fn_rettypioparam,
-1,
! fcinfo-isnull);
/*
* If the function's return type isn't by value, copy the value
***
*** 1348,1354
value = exec_cast_value(value, valtype, var-datatype-typoid,
(var-datatype-typinput),
var-datatype-typioparam,
! var-datatype-atttypmod, isnull);
if (isnull)
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
--- 1348,1354
value = exec_cast_value(value, valtype, var-datatype-typoid,
(var-datatype-typinput),
var-datatype-typioparam,
! var-datatype-atttypmod, isnull);
if (isnull)
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
***
*** 1364,1370
value = exec_cast_value(value, valtype, var-datatype-typoid,
(var-datatype-typinput),
var-datatype-typioparam,
! var-datatype-atttypmod, isnull);
if (isnull)
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
--- 1364,1370
value = exec_cast_value(value, valtype, var-datatype-typoid,
(var-datatype-typinput),
var-datatype-typioparam,
! var-datatype-atttypmod, isnull);
if (isnull)
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
***
*** 1868,1874
var-datatype-typoid,
tupdesc-attrs[0]-atttypid,
tupdesc-attrs[0]-atttypmod,
! isNull);
tuple = heap_form_tuple(tupdesc, retval, isNull);
--- 1868,1874
var-datatype-typoid,
tupdesc-attrs[0]-atttypid,
tupdesc-attrs[0]-atttypmod,
! isNull);
tuple = heap_form_tuple(tupdesc, retval, isNull);
***
*** 1934,1940
rettype,
tupdesc-attrs[0]-atttypid,
tupdesc-attrs[0]-atttypmod,
! isNull);
tuple = heap_form_tuple(tupdesc, retval, isNull);
--- 1934,1940
rettype,
tupdesc-attrs[0]-atttypid,
tupdesc-attrs[0]-atttypmod,
! isNull);
tuple = heap_form_tuple(tupdesc, retval, isNull);
***
*** 2995,3001
(var-datatype-typinput),
var-datatype-typioparam,
var-datatype-atttypmod,
! isNull);
if (*isNull var-notnull)
ereport(ERROR,
--- 2995,3001
(var-datatype-typinput),
var-datatype-typioparam,
var-datatype-atttypmod,
! *isNull);
if (*isNull var-notnull)
ereport(ERROR,
***
*** 3194,3200
valtype,
atttype,
atttypmod,
! attisnull);
if (attisnull)
nulls[fno] = 'n';
else
--- 3194,3200
valtype,
atttype,
atttypmod,
! attisnull);
if (attisnull)
nulls[fno] = 'n';
else
***
*** 3340,3346
valtype,
arrayelemtypeid,
