Re: [HACKERS] Review: Hot standby
I wonder if there is corner case below where there are no WAL records to
replay during standby recovery. Specifically, that may cause
IsRunningXactDataValid() to return false since latestObservedXid remains set
to InvalidTransactionId and that prevents postmaster from serving read-only
clients.
I don't have a test case, but I recall seeing the issue while experimenting.
Though that could be because of the WALInsertLock issue reported earlier.
/*
* Can we signal Postmaster to enter consistent recovery
mode?
*
* There are two points in the log that we must pass. The
first
* is minRecoveryPoint, which is the LSN at the time the
* base backup was taken that we are about to rollfoward
from.
* If recovery has ever crashed or was stopped there is also
* another point also: minSafeStartPoint, which we know the
* latest LSN that recovery could have reached prior to
crash.
*
* We must also have assembled sufficient information about
* transaction state to allow valid snapshots to be taken.
*/
if (!reachedSafeStartPoint
IsRunningXactDataValid()
XLByteLE(ControlFile-minSafeStartPoint, EndRecPtr)
XLByteLE(ControlFile-minRecoveryPoint, EndRecPtr))
{
reachedSafeStartPoint = true;
if (InArchiveRecovery)
{
ereport(LOG,
(errmsg(database has now reached consistent
state at %X/%X,
EndRecPtr.xlogid, EndRecPtr.xrecoff)));
InitRecoveryTransactionEnvironment();
StartCleanupDelayStats();
if (IsUnderPostmaster)
SendPostmasterSignal(PMSIGNAL_RECOVERY_START);
}
}
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] Review: Hot standby
+ /* +* Release locks, if any. +*/ + RelationReleaseRecoveryLocks(xlrec-slotId); If I am reading the patch correctly, AccessExclusiveLocks acquired by a transaction will be released when the transaction is committed or aborted. If the transaction errors out with FATAL, the locks will be released when the next transaction occupying the same slot is committed/aborted. I smell some sort of deadlock condition here. What if the following events happen: - transaction A (slot 1) starts and acquires AEL lock on relation - transaction A errors out with FATAL error - transaction B (slot 1) starts and requests AEL lock on the same relation Won't B deadlock with A ? Since B hasn't yet committed/aborted, the lock held by A is not released and relation_redo_lock() would indefinitely wait for the lock. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] Should enum GUCs be listed as such in config.sgml?
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: bruce wrote: Tom Lane wrote: Currently, config.sgml still describes the new enum GUC variables as being of type string --- but pg_settings says they are enum. This is not very consistent, but I wonder whether changing the docs would be more confusing or less so. I note that section 18.1 doesn't mention the enum alternative either. I looked into this and I think the documentation is fine. If enums didn't require quotes but strings did, we would document them differently, but the fact is that enums are the same as strings except enums have a limited number of possible values --- that isn't something that is usually identified in a variable type definition heading. By that logic, we should not distinguish integers and floats. One's just a restricted form of the other. Looking further, it seems we still have an inconsistency problem because pg_settings mentions enum; should we just change that to 'string'? No, and in fact pg_settings is the counterexample to your conclusion that it's okay to pretend enums are the same as strings: since it has an enumvals column that's populated for enums and not for strings, there is clearly a genuine user-visible difference. Last I checked, Magnus had promised to come up with suitable documentation changes for this patch, but then he went off sailing... Meh, I seem to have forgotten this one again. Here's a suggestion, seems ok, or were you thinking about something more? //Magnus diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index b0de16e..1cfa8bc 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -20,8 +20,8 @@ para All parameter names are case-insensitive. Every parameter takes a -value of one of four types: Boolean, integer, floating point, -or string. Boolean values can be written as literalON/literal, +value of one of five types: Boolean, integer, floating point, +string or enum. Boolean values can be written as literalON/literal, literalOFF/literal, literalTRUE/literal, literalFALSE/literal, literalYES/literal, literalNO/literal, literal1/literal, literal0/literal @@ -43,6 +43,12 @@ /para para +Enum settings are specified the same way as string settings, but they +are limited in which strings are accepted. For each setting the available +are listed in literalpg_settings.enumvals/. + /para + + para One way to set these parameters is to edit the file filenamepostgresql.conf/indextermprimarypostgresql.conf//, which is normally kept in the data directory. (applicationinitdb/ @@ -1329,7 +1335,7 @@ SET ENABLE_SEQSCAN TO OFF; /varlistentry varlistentry id=guc-wal-sync-method xreflabel=wal_sync_method - termvarnamewal_sync_method/varname (typestring/type)/term + termvarnamewal_sync_method/varname (typeenum/type)/term indexterm primaryvarnamewal_sync_method/ configuration parameter/primary /indexterm @@ -2464,7 +2470,7 @@ local0.*/var/log/postgresql /varlistentry varlistentry id=guc-syslog-facility xreflabel=syslog_facility - termvarnamesyslog_facility/varname (typestring/type)/term + termvarnamesyslog_facility/varname (typeenum/type)/term indexterm primaryvarnamesyslog_facility/ configuration parameter/primary /indexterm @@ -2511,7 +2517,7 @@ local0.*/var/log/postgresql variablelist varlistentry id=guc-client-min-messages xreflabel=client_min_messages - termvarnameclient_min_messages/varname (typestring/type)/term + termvarnameclient_min_messages/varname (typeenum/type)/term indexterm primaryvarnameclient_min_messages/ configuration parameter/primary /indexterm @@ -2532,7 +2538,7 @@ local0.*/var/log/postgresql /varlistentry varlistentry id=guc-log-min-messages xreflabel=log_min_messages - termvarnamelog_min_messages/varname (typestring/type)/term + termvarnamelog_min_messages/varname (typeenum/type)/term indexterm primaryvarnamelog_min_messages/ configuration parameter/primary /indexterm @@ -2554,7 +2560,7 @@ local0.*/var/log/postgresql /varlistentry varlistentry id=guc-log-error-verbosity xreflabel=log_error_verbosity - termvarnamelog_error_verbosity/varname (typestring/type)/term + termvarnamelog_error_verbosity/varname (typeenum/type)/term indexterm primaryvarnamelog_error_verbosity/ configuration parameter/primary /indexterm @@ -2570,7 +2576,7 @@ local0.*/var/log/postgresql /varlistentry varlistentry id=guc-log-min-error-statement xreflabel=log_min_error_statement - termvarnamelog_min_error_statement/varname (typestring/type)/term + termvarnamelog_min_error_statement/varname (typeenum/type)/term indexterm primaryvarnamelog_min_error_statement/ configuration
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1197)
Bruce Momjian wrote: KaiGai Kohei wrote: Please consider SELinux/SE-PostgreSQL requires various kind of objects (including database objects) to be labeled properly at the initial state. If it allows clients to turn on row-level security feature, it means many unlabeled tuples appear suddenly. In generally, these have to be labeled before the system get being available. I was thinking more about people are using the SQL-level row permissions. Are they going to want it for all tables for all databases, or not at all? We don't have a reason why the SQL-level row permissions should be toggled in global only. It it designed based on DAC policy, so it is quite natural to be controled by owner of resources. (However, it is not implemented yet.) Yes, that was my question --- how will SQL-level row permissions be controlled by the user. When the given tuple has no ACL, it applies the default behavior which allows anything for public. This behavior intends to keep compatible works compared to the vanilla PostgreSQL. We can have two state for no ACLs. The first one is when tuples don't have fixed 4-bytes security attributes. It can be happen when PostgreSQL with SQL-level row-permissions mount compatible database files created by vanilla PostgreSQL. The other is the fixed 4-byte security attribute indicates an entry of no ACLs. It seems unnecessary consumption, but we cannot determine whether the user tries to set ACLs when heap_form_tuple(). One considerable solution is to add an RowACL specific table option to disable row-level ACLs whole of the tables. It can be suitable for security design because the option is provided by the resource owner. For example: CRATE TABLE t ( a int, b text ) WITH (row_acl=disable); If the reloptions contains an information to determine whether a new tuple need the security field, or not, we can reflect it at heap_form_tuple(). Actually, you called it sepostgresql_mode, SE*, but how are we going to control the SQL-level row permissions? Are we using this name? I didn't think so because it seems so associated withe SE-Linux, and if not, how would one say whether a table has SQL-level row permissions? A new GUC variable of row_acl_is_enabled allows us to toggle the SQL-level row permission feature, when the binary is built with --enable-row-acl. I assumed we would always enable SQL-level row permissions. Why would it be a compile-time option? The SQL-level row permission feature is implemented as a guest of PGACE security framework, so we need to select one of the guest mehanism when compile-time. The --enable-selinux and --enable-row-acl are exclusive option. In my guess, I'll be able to complete to put a flag within TupleDesc to control security field of HeapTupleHeader by tomorrow. And I have a plan to check its behavior in this weekend before merge them into my tree. Nice. I will look over your newest version as soon as I can. Today, I could complete to implement the newer version which passes standard regression tests except for two cases expected. Simon, In the result of pgbench -i -s 10, the sepostgresql_row_level=true case consumed 152MB of storage, and the sepostgresql_row_level=false case consumed 148MB of storage. [EMAIL PROTECTED] sepgsql]$ du -hs $PGDATA/base/16384 152M/opt/sepgsql/base/16384 [EMAIL PROTECTED] sepgsql]$ du -hs $PGDATA/base/16385 148M/opt/sepgsql/base/16385 Now I'm under preparation to submit the newest patch set. ToDo: - Check behavior for SE-PostgreSQL specific operations. (like security context updates) - Implementation of new table options to disable row-acl. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby (commit fest version - v5)
On Thu, Nov 20, 2008 at 8:15 PM, Pavan Deolasee [EMAIL PROTECTED]wrote: On Thu, Nov 20, 2008 at 7:50 PM, Simon Riggs [EMAIL PROTECTED]wrote: (I assume you mean bgwriter, not archiver process). Yeah, its the bgwriter, IIRC hung while taking checkpoint. Sorry, its the startup process thats stuck in the checkpoint. Here is the stack trace: (gdb) bt #0 0x00110402 in __kernel_vsyscall () #1 0x0095564b in semop () from /lib/libc.so.6 #2 0x0825c703 in PGSemaphoreLock (sema=0xb7c52c7c, interruptOK=0 '\0') at pg_sema.c:420 #3 0x0829ff5e in LWLockAcquire (lockid=WALInsertLock, mode=LW_EXCLUSIVE) at lwlock.c:456 #4 0x080d5c7e in XLogInsert (rmid=0 '\0', info=16 '\020', rdata=0xbfda1798) at xlog.c:746 #5 0x080e2e0f in CreateCheckPoint (flags=6) at xlog.c:6674 #6 0x080e1afd in StartupXLOG () at xlog.c:6077 #7 0x08104f2f in AuxiliaryProcessMain (argc=2, argv=0xbfda19e4) at bootstrap.c:421 #8 0x0826d285 in StartChildProcess (type=StartupProcess) at postmaster.c:4104 #9 0x082690d9 in PostmasterMain (argc=3, argv=0x9c89a60) at postmaster.c:1034 #10 0x081f90ff in main (argc=3, argv=0x9c89a60) at main.c:188 ISTM that the postmaster somehow does not receive (may be because of what I reported in my other mail) PMSIGNAL_RECOVERY_START and hence bgwriter is not started. The startup process then itself tries to take a checkpoint and hangs. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] [COMMITTERS] pgsql: TABLE command
Tom Lane wrote: [EMAIL PROTECTED] (Peter Eisentraut) writes: Log Message: --- TABLE command If this got re-posted for review I missed it :-(. I disagree with using qualified_name here --- I think it would be better to use relation_expr so that people would have the ability to specify inheritance behavior. If you want to point to the spec and say that that syntax isn't in the spec, that's true, but then you need to justify the inhOpt setting you're forcing people to use. It's not entirely clear what behavior the spec intends, but I'm pretty sure INH_DEFAULT isn't it. relation_expr is fine by me. It just makes the syntax more complicated to explain ... Btw., so we plan to keep the sql_inheritance parameter forever? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_settings.enumval as array
The attached patch changes pg_settings.enumval to be an array of text
instead of just a string, per previous discussion and the open items list.
Comments?
//Magnus
*** a/src/backend/utils/misc/guc.c
--- b/src/backend/utils/misc/guc.c
***
*** 168,174 static bool assign_maxconnections(int newval, bool doit, GucSource source);
static const char *assign_pgstat_temp_directory(const char *newval, bool doit, GucSource source);
static char *config_enum_get_options(struct config_enum *record,
! const char *prefix, const char *suffix);
/*
--- 168,175
static const char *assign_pgstat_temp_directory(const char *newval, bool doit, GucSource source);
static char *config_enum_get_options(struct config_enum *record,
! const char *prefix, const char *suffix,
! const char *separator);
/*
***
*** 4427,4433 config_enum_lookup_by_name(struct config_enum *record, const char *value, int *r
* If suffix is non-NULL, it is added to the end of the string.
*/
static char *
! config_enum_get_options(struct config_enum *record, const char *prefix, const char *suffix)
{
const struct config_enum_entry *entry = record-options;
int len = 0;
--- 4428,4435
* If suffix is non-NULL, it is added to the end of the string.
*/
static char *
! config_enum_get_options(struct config_enum *record, const char *prefix,
! const char *suffix, const char *separator)
{
const struct config_enum_entry *entry = record-options;
int len = 0;
***
*** 4439,4445 config_enum_get_options(struct config_enum *record, const char *prefix, const ch
while (entry entry-name)
{
if (!entry-hidden)
! len += strlen(entry-name) + 2; /* string and , */
entry++;
}
--- 4441,4447
while (entry entry-name)
{
if (!entry-hidden)
! len += strlen(entry-name) + strlen(separator);
entry++;
}
***
*** 4454,4460 config_enum_get_options(struct config_enum *record, const char *prefix, const ch
if (!entry-hidden)
{
strcat(hintmsg, entry-name);
! strcat(hintmsg, , );
}
entry++;
--- 4456,4462
if (!entry-hidden)
{
strcat(hintmsg, entry-name);
! strcat(hintmsg, separator);
}
entry++;
***
*** 4469,4484 config_enum_get_options(struct config_enum *record, const char *prefix, const ch
* to make sure we don't write to invalid memory instead of actually
* trying to do something smart with it.
*/
! if (len 1)
! /* Replace final comma/space */
! hintmsg[len-2] = '\0';
strcat(hintmsg, suffix);
return hintmsg;
}
-
/*
* Call a GucStringAssignHook function, being careful to free the
* newval string if the hook ereports.
--- 4471,4485
* to make sure we don't write to invalid memory instead of actually
* trying to do something smart with it.
*/
! if (len strlen(separator)-1)
! /* Replace final separator */
! hintmsg[len-strlen(separator)] = '\0';
strcat(hintmsg, suffix);
return hintmsg;
}
/*
* Call a GucStringAssignHook function, being careful to free the
* newval string if the hook ereports.
***
*** 5044,5050 set_config_option(const char *name, const char *value,
{
if (!config_enum_lookup_by_name(conf, value, newval))
{
! char *hintmsg = config_enum_get_options(conf, Available values: , .);
ereport(elevel,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
--- 5045,5051
{
if (!config_enum_lookup_by_name(conf, value, newval))
{
! char *hintmsg = config_enum_get_options(conf, Available values: , ., , );
ereport(elevel,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
***
*** 6249,6255 GetConfigOptionByNum(int varnum, const char **values, bool *noshow)
values[10] = NULL;
/* enumvals */
! values[11] = config_enum_get_options((struct config_enum *) conf, , );
/* boot_val */
values[12] = pstrdup(config_enum_lookup_by_value(lconf, lconf-boot_val));
--- 6250,6256
values[10] = NULL;
/* enumvals */
! values[11] = config_enum_get_options((struct config_enum *) conf, {\, \}, \,\);
/* boot_val */
values[12] = pstrdup(config_enum_lookup_by_value(lconf, lconf-boot_val));
***
*** 6385,6391 show_all_settings(PG_FUNCTION_ARGS)
TupleDescInitEntry(tupdesc, (AttrNumber) 11, max_val,
TEXTOID, -1, 0);
TupleDescInitEntry(tupdesc, (AttrNumber) 12, enumvals,
! TEXTOID, -1, 0);
TupleDescInitEntry(tupdesc, (AttrNumber) 13, boot_val,
TEXTOID, -1, 0);
TupleDescInitEntry(tupdesc, (AttrNumber) 14, reset_val,
--- 6386,6392
TupleDescInitEntry(tupdesc, (AttrNumber) 11, max_val,
TEXTOID, -1, 0);
TupleDescInitEntry(tupdesc, (AttrNumber) 12, enumvals,
!
Re: [HACKERS] Hot Standby (commit fest version - v5)
On Fri, 2008-11-21 at 17:08 +0530, Pavan Deolasee wrote: Sorry, its the startup process thats stuck in the checkpoint. Here is the stack trace: Already fixed in new version I'm preparing for you. Both the startup process and bgwriter can perform restartpoints, so its not a problem whether we reached the point at which we pmsignal or not. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: Hot standby
On Fri, 2008-11-21 at 13:22 +0530, Pavan Deolasee wrote: I think we should avoid the #define's like below which uses a local variable. I guess the same #define is used elsewhere in the code as well. If the code is rearranged or the variable name is changed, the code would break. I use a #define because same value is used elsewhere in code. The use of malloc should also be avoided (unless the memory subsystem is not up yet; I haven't checked). The malloc was part of the existing code, explained by comments. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL configure patch: review
Alex Hunsaker wrote: On Fri, Aug 1, 2008 at 13:31, Alvaro Herrera [EMAIL PROTECTED] wrote: Something that's bothering me is that PGSSLKEY is inconsistent with the sslkey conninfo parameter. PGSSLKEY specifies an engine (basically a driver for specialized hardware AFAICT) from which the key is to be loaded, but sslkey is a simple filename. This means that there's no way to load a key from hardware if you want to specify it per connection. Not that I have any such hardware, but it looks bogus. Obviously one still wants to be able to specify a different file name from the default; I tried to see if there's any way to load an engine that would load the key from a file, but could not extract any sense from the man page: http://www.openssl.org/docs/crypto/engine.html Maybe this means that we should provide separate parameters, say sslkey and sslkeyfile, and a new env var PGSSLKEYFILE. Thoughts? Am I overengineering this stuff? I think the patch as it stands is ok for now (mainly because I don't have any hardware either so I can't test or attest to how it should be done i.e. if those params would be enough) Should PGROOTCERT be PGSSLROOTCERT to be more congruent with all the other ssl params? Yes, I think that'd be a good idea. Find attached an updated patch against HEAD (no other changes). I also gave it a look over and tested it to make sure it worked as described. I still think the parameters should be available for non-SSL builds, but ignored. None of them put any restrictions in place, so it's not an issue to ignore them if we are not going to obey them (if SSL isn't used anyway), and it'll make life easier for autogenerated connection strings. I also think we should rename the variables internally. conn-sslcert sounds very much to me like it'd be the certificate in use for the connection, which it isn't. How about sslcertname, sslcrlname etc? (no need to change the user visible stuff, just in the code to make it easier to follow elsewhere) We still have the issue with the environment variable not matching the connection string one that needs to be resolved. Thoughts? (I have added this to the commitfest page, as it was lost) //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: Hot standby
On Fri, 2008-11-21 at 15:21 +0530, Pavan Deolasee wrote: + /* +* Release locks, if any. +*/ + RelationReleaseRecoveryLocks(xlrec-slotId); If I am reading the patch correctly, AccessExclusiveLocks acquired by a transaction will be released when the transaction is committed or aborted. If the transaction errors out with FATAL, the locks will be released when the next transaction occupying the same slot is committed/aborted. I smell some sort of deadlock condition here. What if the following events happen: - transaction A (slot 1) starts and acquires AEL lock on relation - transaction A errors out with FATAL error - transaction B (slot 1) starts and requests AEL lock on the same relation Won't B deadlock with A ? Since B hasn't yet committed/aborted, the lock held by A is not released and relation_redo_lock() would indefinitely wait for the lock. This won't happen because the lock is held by the startup process on behalf of slot 1. Explained in comments in inval.c code. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Autoconf, libpq and replacement function
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
AFAICS, we're not doing this for any other functions though - or am I
too tired and just looking in the wrong place? Or is that because
they're just function definitions and not #defines?
(I want to be sure to stick whatever new file there is in the same place..)
src/include/rusagestub.h is doing things more or less this way.
Also, right now we have got
src/include/getaddrinfo.h
src/include/getopt_long.h
which really make me itch now that I am contemplating the possibility
that we try to use libc-supplied code for these functions along with
our own header definitions.
I think the reason we've avoided putting such stuff into include/port/
is that right now that directory consists exclusively of OS-specific
files. Maybe we need another include subdirectory?
Or in the same directly, called something else. Like fnmatchstub.h. See
attached, seems reasonable?
//Magnus
*** a/configure
--- b/configure
***
*** 24821,24826 esac
--- 24821,24910
+ # Check for fnmatch()
+ { echo $as_me:$LINENO: checking for working POSIX fnmatch 5
+ echo $ECHO_N checking for working POSIX fnmatch... $ECHO_C 6; }
+ if test ${ac_cv_func_fnmatch_works+set} = set; then
+ echo $ECHO_N (cached) $ECHO_C 6
+ else
+ # Some versions of Solaris, SCO, and the GNU C Library
+# have a broken or incompatible fnmatch.
+# So we run a test program. If we are cross-compiling, take no chance.
+# Thanks to John Oleynick, Franc,ois Pinard, and Paul Eggert for this test.
+if test $cross_compiling = yes; then
+ ac_cv_func_fnmatch_works=cross
+ else
+ cat conftest.$ac_ext _ACEOF
+ /* confdefs.h. */
+ _ACEOF
+ cat confdefs.h conftest.$ac_ext
+ cat conftest.$ac_ext _ACEOF
+ /* end confdefs.h. */
+ #include fnmatch.h
+ # define y(a, b, c) (fnmatch (a, b, c) == 0)
+ # define n(a, b, c) (fnmatch (a, b, c) == FNM_NOMATCH)
+
+ int
+ main ()
+ {
+ return
+ (!(y (a*, abc, 0)
+ n (d*/*1, d/s/1, FNM_PATHNAME)
+ y (abc, abc, 0)
+ n (abc, abc, FNM_NOESCAPE)
+ y (*x, .x, 0)
+ n (*x, .x, FNM_PERIOD)
+ 1));
+ ;
+ return 0;
+ }
+ _ACEOF
+ rm -f conftest$ac_exeext
+ if { (ac_try=$ac_link
+ case (($ac_try in
+ *\* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+ *) ac_try_echo=$ac_try;;
+ esac
+ eval echo \\$as_me:$LINENO: $ac_try_echo\) 5
+ (eval $ac_link) 25
+ ac_status=$?
+ echo $as_me:$LINENO: \$? = $ac_status 5
+ (exit $ac_status); } { ac_try='./conftest$ac_exeext'
+ { (case (($ac_try in
+ *\* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+ *) ac_try_echo=$ac_try;;
+ esac
+ eval echo \\$as_me:$LINENO: $ac_try_echo\) 5
+ (eval $ac_try) 25
+ ac_status=$?
+ echo $as_me:$LINENO: \$? = $ac_status 5
+ (exit $ac_status); }; }; then
+ ac_cv_func_fnmatch_works=yes
+ else
+ echo $as_me: program exited with status $ac_status 5
+ echo $as_me: failed program was: 5
+ sed 's/^/| /' conftest.$ac_ext 5
+
+ ( exit $ac_status )
+ ac_cv_func_fnmatch_works=no
+ fi
+ rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext conftest.$ac_objext conftest.$ac_ext
+ fi
+
+
+ fi
+ { echo $as_me:$LINENO: result: $ac_cv_func_fnmatch_works 5
+ echo ${ECHO_T}$ac_cv_func_fnmatch_works 6; }
+ if test $ac_cv_func_fnmatch_works = yes; then
+
+ cat confdefs.h \_ACEOF
+ #define HAVE_FNMATCH 1
+ _ACEOF
+
+ fi
+
+
+
# Select semaphore implementation type.
if test $PORTNAME != win32; then
*** a/configure.in
--- b/configure.in
***
*** 1625,1630 fi
--- 1625,1632
# SunOS doesn't handle negative byte comparisons properly with +/- return
AC_FUNC_MEMCMP
+ # Check for fnmatch()
+ AC_FUNC_FNMATCH
# Select semaphore implementation type.
if test $PORTNAME != win32; then
*** /dev/null
--- b/src/include/fnmatchstub.h
***
*** 0
--- 1,27
+ /*-
+ *
+ * fnmatchstub.h
+ * Stubs for fnmatch() in port/fnmatch.c
+ *
+ *
+ * Portions Copyright (c) 1996-2008, PostgreSQL Global Development Group
+ * Portions Copyright (c) 1994, Regents of the University of California
+ *
+ * $PostgreSQL$
+ *
+ *-
+ */
+ #ifndef FNMATCHSTUB_H
+ #define FNMATCHSTUB_H
+
+ extern int fnmatch(const char *, const char *, int);
+ #define FNM_NOMATCH 1 /* Match failed. */
+ #define FNM_NOSYS 2 /* Function not implemented. */
+ #define FNM_NOESCAPE 0x01 /* Disable backslash escaping. */
+ #define FNM_PATHNAME 0x02 /* Slash must be matched by slash. */
+ #define FNM_PERIOD 0x04 /* Period must be matched by period. */
+ #define FNM_CASEFOLD 0x08 /* Pattern is matched case-insensitive */
+ #define FNM_LEADING_DIR 0x10 /* Ignore /tail after Imatch. */
+
+
+ #endif
*** a/src/include/pg_config.h.in
--- b/src/include/pg_config.h.in
***
*** 143,148
--- 143,151
/* Define to
Re: [HACKERS] SSL configure patch: review
Magnus Hagander escribió: Alex Hunsaker wrote: On Fri, Aug 1, 2008 at 13:31, Alvaro Herrera [EMAIL PROTECTED] wrote: Something that's bothering me is that PGSSLKEY is inconsistent with the sslkey conninfo parameter. PGSSLKEY specifies an engine (basically a driver for specialized hardware AFAICT) from which the key is to be loaded, but sslkey is a simple filename. This means that there's no way to load a key from hardware if you want to specify it per connection. Not that I have any such hardware, but it looks bogus. I think the above consideration needs some discussion too. Committing it as-is doesn't seem OK because you can't change it later -- it's user-visible. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1197)
KaiGai Kohei wrote: Bruce Momjian wrote: KaiGai Kohei wrote: Please consider SELinux/SE-PostgreSQL requires various kind of objects (including database objects) to be labeled properly at the initial state. If it allows clients to turn on row-level security feature, it means many unlabeled tuples appear suddenly. In generally, these have to be labeled before the system get being available. I was thinking more about people are using the SQL-level row permissions. Are they going to want it for all tables for all databases, or not at all? We don't have a reason why the SQL-level row permissions should be toggled in global only. It it designed based on DAC policy, so it is quite natural to be controled by owner of resources. (However, it is not implemented yet.) Yes, that was my question --- how will SQL-level row permissions be controlled by the user. When the given tuple has no ACL, it applies the default behavior which allows anything for public. This behavior intends to keep compatible works compared to the vanilla PostgreSQL. We can have two state for no ACLs. The first one is when tuples don't have fixed 4-bytes security attributes. It can be happen when PostgreSQL with SQL-level row-permissions mount compatible database files created by vanilla PostgreSQL. The other is the fixed 4-byte security attribute indicates an entry of no ACLs. It seems unnecessary consumption, but we cannot determine whether the user tries to set ACLs when heap_form_tuple(). One considerable solution is to add an RowACL specific table option to disable row-level ACLs whole of the tables. It can be suitable for security design because the option is provided by the resource owner. For example: CRATE TABLE t ( a int, b text ) WITH (row_acl=disable); If the reloptions contains an information to determine whether a new tuple need the security field, or not, we can reflect it at heap_form_tuple(). What I am saying is for the default compile, SQL-level ACLs should be possible because, since the ACL field has optional storage, there is no downside to have it be available by default. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] fmgr.h vs funcapi.h?
I was writing a simple standalone function compiled with pgxs - been a while since I did that. Including postgres.h and fmgr.h, it didn't work - the backend would complain that the function did not exist in the shared library. Including postgres.h and funcapi.h *did* work - no complaints. From what I can find in the docs, fmgr.h is the one to use as long as you don't need to do set returning functions (mine is a simpe int-returning function). Docs issue, code issue, or Magnus-issue? //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Transactions and temp tables
Heikki Linnakangas wrote: Emmanuel Cecchet wrote: I still quite did not get what the big deal was if an ON COMMIT DELETE ROWS temp table was created inside a transaction. In case the transaction that created a temp table rolls back, the table needs to be removed. Removing a temporary table belonging to another backend is problematic; the local buffers in the original backend need to be dropped, as well as the entry in the on commit actions list. Why the new checks you are doing in lock.c would not work with dropped temp tables? Could it be possible to drop the lock as soon as the temp table is dropped inside a transaction? If you release the lock early on a table that you drop, another transactions would be free to access the table, even though it's about to be dropped. I will try to find more time to review the patch tonight. Thanks! Thinking about this whole thing yet more, I wonder if we could have a more holistic approach and make temporary tables work just like regular ones. The problems we've identified this far are: 1. If the prepared transaction keeps the temp table locked, the backend can't exit, because the shutdown hook tries to drop all temp tables. 2. When a prepared transaction that has deleted a temporary table commits (or one that created one aborts), we need to drop all the local buffers from the original backend's private buffer cache. 3. When a prepared transaction that has deleted a temporary table commits (or one that created one aborts), we need to remove the on-commit entry from the original backend's private list. Is there more? I think we can solve all the above problems: 1. Modify RemoveTempRelations so that it doesn't block if it can't immediately acquire lock on the to-be-removed object. That way the original backend can exit even if a prepared transaction is holding a lock on a temporary object. To avoid conflict with a new backend that's assigned the same backendid, divorce the temporary namespace naming from backendid so that the temporary namespace name stays reserved for the prepared transaction. Is that going to cause any problem with DROP CASCADE operations or trying to later drop a child table if the parent table is locked? I did hit that issue when I tried to modify RemoveTempRelations but I was probably not very smart at it. 2. Flush and drop all local buffers on temporary tables that have been created or dropped in the transaction at PREPARE TRANSACTION already. Would there be any issue if someone was trying to use a READ_UNCOMMITTED isolation level to access the temp table data? 3. Add on-commit field to pg_class, and only keep a list of temporary tables that have been accessed in the current transaction in backend-private memory. Yes, this seems doable. We will certainly have to keep a list per transaction id in case multiple prepared but uncommitted transactions have accessed different temp table on that backend. Have you already started to code some of this? I am looking at adding new tests to check all cases including all types of temp tables (normal/on delete/on drop, created inside or outside a transaction, prepare/postmaster stop/commit/rollback, inherit/index/vaccuum). That should get all the use cases covered. Let me know what you think. Thanks, Emmanuel -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development Consulting -- Web: http://www.frogthinker.org email: [EMAIL PROTECTED] Skype: emmanuel_cecchet -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: TABLE command
Peter Eisentraut [EMAIL PROTECTED] writes: relation_expr is fine by me. It just makes the syntax more complicated to explain ... Btw., so we plan to keep the sql_inheritance parameter forever? I have no idea ... but I should think we'd want to allow ONLY here in any case. You can use that anywhere else in the SELECT syntax that you can write a table name, so why not here? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] fmgr.h vs funcapi.h?
Magnus Hagander [EMAIL PROTECTED] writes: I was writing a simple standalone function compiled with pgxs - been a while since I did that. Including postgres.h and fmgr.h, it didn't work - the backend would complain that the function did not exist in the shared library. Including postgres.h and funcapi.h *did* work - no complaints. I can't recall ever having had to do that. Can you show a complete example (including the Makefile you're using)? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Silence compiler warning about ignored return value.
Tom Lane wrote: (Whatcha gonna do if you fail to write the postmaster log ... try to log a complaint message?) Well, good question, but I'm not convinced that doing nothing is always the best answer. Something along the lines of SIGSTOP'ing oneself or calling abort() might be appropriate in some cases. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Opening a recovering DB in for read-only access?
On Fri, 2008-11-21 at 15:45 +1100, Philip Warner wrote: Sounds somewhat evil, I know, but I was wondering if it was even remotely possible with the current design? The reason: we are contemplating using pg_standy to create a warm-standby. It would be a bonus if we would run read-only queries against this DB to take some of the load off or production servers. We currently use slony to provide warm-standby *and* read-only access, but pg_standby is a great deal more appealing...especially if there was some way to do read-only access at the same time. Yes, exactly what I'm working on now, currently patch in review. FWIW, the data would not even need to be completely consistent ... the kinds of things we are looking at offloading are large summary-type sequential scans of big tables. Access to inconsistent data has not been agreed. We will only allow access to consistent data with this approach. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Silence compiler warning about ignored return value.
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane wrote: (Whatcha gonna do if you fail to write the postmaster log ... try to log a complaint message?) Well, good question, but I'm not convinced that doing nothing is always the best answer. I didn't say it was --- merely opined that we need a consistent plan about how to handle corner cases like that if we want to try to wipe out all the warnings of this class. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] How should pg_standby get over the gap of timeline?
On Thu, 2008-11-20 at 22:41 +0900, Fujii Masao wrote: In the current Synch Rep patch, the standby cannot catch up with the primary which has a bigger timeline. So, whenever making the standby catch up, a fresh base backup is required. This is obviously undesirable, and I'd like to get rid of this restriction. Postgres itself can recover up to a bigger timeline without a base backup. The remaining problem is that pg_standby cannot get over the gap of timeline. It continues waiting for the XLOG file with out-of-date timeline, and redo doesn't progress. We've discussed this before. My answer is the same: you are assuming it is safe to re-enter recovery, which is not correct (currently). You are also assuming that taking a base backup is an expensive operation - it need not be so if you simply move only the files/data that have changed, e.g. rsync. So if you want this to work, hacking pg_standby is not the way to do it. But I'm not convinced there is a problem worth solving. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL configure patch: review
Alvaro Herrera wrote: Magnus Hagander escribió: Alex Hunsaker wrote: On Fri, Aug 1, 2008 at 13:31, Alvaro Herrera [EMAIL PROTECTED] wrote: Something that's bothering me is that PGSSLKEY is inconsistent with the sslkey conninfo parameter. PGSSLKEY specifies an engine (basically a driver for specialized hardware AFAICT) from which the key is to be loaded, but sslkey is a simple filename. This means that there's no way to load a key from hardware if you want to specify it per connection. Not that I have any such hardware, but it looks bogus. I think the above consideration needs some discussion too. Committing it as-is doesn't seem OK because you can't change it later -- it's user-visible. .. that's the one I was referring to in my mail ... It should definitely be made consistent. //MAgnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Silence compiler warning about ignored return value.
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane wrote: (Whatcha gonna do if you fail to write the postmaster log ... try to log a complaint message?) Well, good question, but I'm not convinced that doing nothing is always the best answer. I didn't say it was --- merely opined that we need a consistent plan about how to handle corner cases like that if we want to try to wipe out all the warnings of this class. Maybe syslog? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Silence compiler warning about ignored return value.
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: I didn't say it was --- merely opined that we need a consistent plan about how to handle corner cases like that if we want to try to wipe out all the warnings of this class. Maybe syslog? Doesn't exist on Windows ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_settings.enumval as array
Magnus Hagander [EMAIL PROTECTED] writes: The attached patch changes pg_settings.enumval to be an array of text instead of just a string, per previous discussion and the open items list. Comments? Hmmm ... this coding will fail if any enumval contains a double quote. Which is probably not a big problem, but we ought to document the restriction somewhere. Also, this: ! if (len strlen(separator)-1) ! /* Replace final separator */ ! hintmsg[len-strlen(separator)] = '\0'; would read better IMHO as if (len = strlen(separator)). Also, the output datatype should be text[] not cstring[]. Otherwise seems okay. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] fmgr.h vs funcapi.h?
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I was writing a simple standalone function compiled with pgxs - been a while since I did that. Including postgres.h and fmgr.h, it didn't work - the backend would complain that the function did not exist in the shared library. Including postgres.h and funcapi.h *did* work - no complaints. I can't recall ever having had to do that. Can you show a complete example (including the Makefile you're using)? Pah, ignore that. It was a combination of me working when I really should've gone home, a connection pooler and somebody else working on the same database. Bottom line: it wasn't the change of fmgr.h that fixed it, it was the fact that the backend was actually not restarted in the first test so it had an old version of the shared lib! D'uh. Apologies. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should enum GUCs be listed as such in config.sgml?
Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: Last I checked, Magnus had promised to come up with suitable documentation changes for this patch, but then he went off sailing... Meh, I seem to have forgotten this one again. Here's a suggestion, seems ok, or were you thinking about something more? Needs a bit of proofreading but this is more or less what I had in mind. +Enum settings are specified the same way as string settings, but they +are limited in which strings are accepted. For each setting the available +are listed in literalpg_settings.enumvals/. IIRC the comparisons are case-insensitive; if so the fact should be mentioned here. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_settings.enumval as array
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: The attached patch changes pg_settings.enumval to be an array of text instead of just a string, per previous discussion and the open items list. Comments? Hmmm ... this coding will fail if any enumval contains a double quote. Which is probably not a big problem, but we ought to document the restriction somewhere. Hmm. Know what, I had a code comment about that in there. Then I re-factored my patch and lost it! I think a code comment is enough. It would actually be quite silly to *have* a double quote in an enumval - I doubt it will happen by misake. Will add back. Also, this: !if (len strlen(separator)-1) !/* Replace final separator */ !hintmsg[len-strlen(separator)] = '\0'; would read better IMHO as if (len = strlen(separator)). Pfft, result of too much copy/paste. Changed. Also, the output datatype should be text[] not cstring[]. Ok, will change. That requires hardcode of 1009? Or should I a #define to pg_type.h? //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_settings.enumval as array
Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: Also, the output datatype should be text[] not cstring[]. Ok, will change. That requires hardcode of 1009? Or should I a #define to pg_type.h? Add a #define (bit surprising we didn't have one already) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Silence compiler warning about ignored return value.
Maybe syslog? Doesn't exist on Windows ... There is an event log though which is fairly comparable. Of course that still leaves you with the problem of what to do when the syslog or event log write fails. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] How should pg_standby get over the gap of timeline?
Hi, Simon. Thanks for the comment!! On Sat, Nov 22, 2008 at 2:09 AM, Simon Riggs [EMAIL PROTECTED] wrote: On Thu, 2008-11-20 at 22:41 +0900, Fujii Masao wrote: In the current Synch Rep patch, the standby cannot catch up with the primary which has a bigger timeline. So, whenever making the standby catch up, a fresh base backup is required. This is obviously undesirable, and I'd like to get rid of this restriction. Postgres itself can recover up to a bigger timeline without a base backup. The remaining problem is that pg_standby cannot get over the gap of timeline. It continues waiting for the XLOG file with out-of-date timeline, and redo doesn't progress. We've discussed this before. My answer is the same: you are assuming it is safe to re-enter recovery, which is not correct (currently). I'm afraid you might be right. But I cannot understand yet why it's not safe to re-enter recovery. Is it safe to re-enter recovery from the restart point after PITR stopped halfway? If it's safe, ISTM that PITR without a base backup also is safe. Please let me know what might violate a re-entry of recovery. What is your worry? You are also assuming that taking a base backup is an expensive operation - it need not be so if you simply move only the files/data that have changed, e.g. rsync. It depends on DB size and type. I think that it's important that the user *can* choose the better method according to his situation. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Autoconf, libpq and replacement function
Magnus Hagander [EMAIL PROTECTED] writes: Or in the same directly, called something else. Like fnmatchstub.h. See attached, seems reasonable? Seems okay to me. Note: in future, don't bother posting configure diffs; nobody wants to look at that, just the changes in the autoconf input files. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_settings.enumval as array
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: Also, the output datatype should be text[] not cstring[]. Ok, will change. That requires hardcode of 1009? Or should I a #define to pg_type.h? Add a #define (bit surprising we didn't have one already) Yeah, that surprised me too - which is why I had to ask (in case there was some strange reason we didn't want it). Changed and applied. Thanks for your comments! //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Autoconf, libpq and replacement function
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Or in the same directly, called something else. Like fnmatchstub.h. See attached, seems reasonable? Seems okay to me. Note: in future, don't bother posting configure diffs; nobody wants to look at that, just the changes in the autoconf input files. Ok, will exclude it next time. FYI, the if check in the configure (and configure.in) was backwards :-) I posted the patch without testing it to get the general idea across. Will run a set of test of the latest one on msvc as well, and then commit. //magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] HEAD build failure on win32 mingw
On Thu, Nov 20, 2008 at 4:31 AM, ITAGAKI Takahiro [EMAIL PROTECTED] wrote: I used a nightly snapshot(snapshot/postgresql-snapshot.tar.bz2) and it includes *.gz files. It would be the cause. i saw the same on a nightly snapshot a week ago, then used cvs and everything was good... i thouhgt it was a problem already solved... could be a problem in the nightly builds? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Autoconf, libpq and replacement function
If you want people to stop posting configure diffs you should remove the damn configure file from CVS where it doesn't belong. greg On 21 Nov 2008, at 06:49 PM, Tom Lane [EMAIL PROTECTED] wrote: Magnus Hagander [EMAIL PROTECTED] writes: Or in the same directly, called something else. Like fnmatchstub.h. See attached, seems reasonable? Seems okay to me. Note: in future, don't bother posting configure diffs; nobody wants to look at that, just the changes in the autoconf input files. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Autoconf, libpq and replacement function
Greg Stark [EMAIL PROTECTED] writes: If you want people to stop posting configure diffs you should remove the damn configure file from CVS where it doesn't belong. Well, that'd require everyone using CVS to have autoconf installed --- and not just any autoconf, but the specific version. Seems like more pain than it's worth considering most people have little need to fool with the configure script. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should enum GUCs be listed as such in config.sgml?
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: Last I checked, Magnus had promised to come up with suitable documentation changes for this patch, but then he went off sailing... Meh, I seem to have forgotten this one again. Here's a suggestion, seems ok, or were you thinking about something more? Needs a bit of proofreading but this is more or less what I had in mind. +Enum settings are specified the same way as string settings, but they +are limited in which strings are accepted. For each setting the available +are listed in literalpg_settings.enumvals/. IIRC the comparisons are case-insensitive; if so the fact should be mentioned here. Updated, added, and applied. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Silence compiler warning about ignored return value.
Robert Haas escribió: Maybe syslog? Doesn't exist on Windows ... There is an event log though which is fairly comparable. Of course that still leaves you with the problem of what to do when the syslog or event log write fails. Well, syslog does not have a return code, which probably means that it can't fail (and if it does, there's no way for you to know). -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Cool hack with recursive queries
Alvaro Herrera napsal(a): David Fetter escribió: On Wed, Nov 19, 2008 at 10:21:06PM -, David Rowley wrote: Gregory Stark wrote: So based on Graeme Job's T-SQL hack over at thedailywtf.com I adapted the T-SQL code to Postgres and got this. Thought others might find it amusing. That's pretty amazing. I think we should add a regression test with that. :) +1 for adding a regression test :) It's too slow for that :-( I takes 2.6 second on my laptop. I think it is not so bad. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] HEAD build failure on win32 mingw
Jaime Casanova wrote: On Thu, Nov 20, 2008 at 4:31 AM, ITAGAKI Takahiro [EMAIL PROTECTED] wrote: I used a nightly snapshot(snapshot/postgresql-snapshot.tar.bz2) and it includes *.gz files. It would be the cause. i saw the same on a nightly snapshot a week ago, then used cvs and everything was good... i thouhgt it was a problem already solved... could be a problem in the nightly builds? Yeah. Buildfarm doesn't do docs at all. Looks to me at first glance like this line in the Makefile: $(mkinstalldirs) man$(sqlmansectnum) should be moved up so it comes immediately after gzip line. That certainly seems to make it work properly for me. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Cool hack with recursive queries
On Fri, Nov 21, 2008 at 3:06 PM, Zdenek Kotala [EMAIL PROTECTED] wrote: I takes 2.6 second on my laptop. I think it is not so bad. Time: 694.512 ms :-) merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] HEAD build failure on win32 mingw
Andrew Dunstan [EMAIL PROTECTED] writes: Jaime Casanova wrote: i saw the same on a nightly snapshot a week ago, then used cvs and everything was good... i thouhgt it was a problem already solved... could be a problem in the nightly builds? Yeah. Buildfarm doesn't do docs at all. Looks to me at first glance like this line in the Makefile: $(mkinstalldirs) man$(sqlmansectnum) should be moved up so it comes immediately after gzip line. No, that is just a kluge that prevents the visible failure. It looks to me like the problem is that the makefile expects the man.tar.gz file to contain stuff in man1/ and man7/, but the file that is actually being delivered in snapshots still contains man1/ and manl/. So that file needs to be regenerated. Peter? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Cool hack with recursive queries
On Fri, Nov 21, 2008 at 09:06:13PM +0100, Zdenek Kotala wrote: Alvaro Herrera napsal(a): David Fetter escribió: On Wed, Nov 19, 2008 at 10:21:06PM -, David Rowley wrote: Gregory Stark wrote: So based on Graeme Job's T-SQL hack over at thedailywtf.com I adapted the T-SQL code to Postgres and got this. Thought others might find it amusing. That's pretty amazing. I think we should add a regression test with that. :) +1 for adding a regression test :) It's too slow for that :-( I takes 2.6 second on my laptop. I think it is not so bad. About 2.0 on my OS/X laptop. Could this be a problem on whatever architecture/OS/compiler combo you have? Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Cool hack with recursive queries
David Fetter [EMAIL PROTECTED] writes: On Fri, Nov 21, 2008 at 09:06:13PM +0100, Zdenek Kotala wrote: I takes 2.6 second on my laptop. I think it is not so bad. About 2.0 on my OS/X laptop. Could this be a problem on whatever architecture/OS/compiler combo you have? Not everyone is using fast new laptops. This is a cool hack, agreed, but that doesn't make it a useful regression test. Whatever value it might have isn't going to repay the community-wide expenditure of cycles. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] HEAD build failure on win32 mingw
Tom Lane wrote: It looks to me like the problem is that the makefile expects the man.tar.gz file to contain stuff in man1/ and man7/, but the file that is actually being delivered in snapshots still contains man1/ and manl/. So that file needs to be regenerated. Peter? Shouldn't it be part of the nightly snapshot creation to make that file? In the snapshot I just downloaded its date is yesterday. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Cool hack with recursive queries
On Fri, Nov 21, 2008 at 04:11:11PM -0500, Tom Lane wrote: David Fetter [EMAIL PROTECTED] writes: On Fri, Nov 21, 2008 at 09:06:13PM +0100, Zdenek Kotala wrote: I takes 2.6 second on my laptop. I think it is not so bad. About 2.0 on my OS/X laptop. Could this be a problem on whatever architecture/OS/compiler combo you have? Not everyone is using fast new laptops. Possibly not, but this could be a way to flush out inconsistencies among floating point units or, more importantly, implementations of NUMERIC. This is a cool hack, agreed, but that doesn't make it a useful regression test. Whatever value it might have isn't going to repay the community-wide expenditure of cycles. What's the slowest it runs? Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Cool hack with recursive queries
David Fetter escribió: On Fri, Nov 21, 2008 at 04:11:11PM -0500, Tom Lane wrote: This is a cool hack, agreed, but that doesn't make it a useful regression test. Whatever value it might have isn't going to repay the community-wide expenditure of cycles. What's the slowest it runs? If we want to do some advocacy with it, how about making some banners? Posters? Flyers? Or go blog about it. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Cool hack with recursive queries
Alvaro Herrera wrote: David Fetter escribi?: On Fri, Nov 21, 2008 at 04:11:11PM -0500, Tom Lane wrote: This is a cool hack, agreed, but that doesn't make it a useful regression test. Whatever value it might have isn't going to repay the community-wide expenditure of cycles. What's the slowest it runs? If we want to do some advocacy with it, how about making some banners? Posters? Flyers? Or go blog about it. Agreed, there is great PR advantage to this, like us running on a PS2. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] HEAD build failure on win32 mingw
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: ... the file that is actually being delivered in snapshots still contains man1/ and manl/. So that file needs to be regenerated. Peter? Shouldn't it be part of the nightly snapshot creation to make that file? In the snapshot I just downloaded its date is yesterday. The tar file's own date might be yesterday, but its contents are dated 2003-11-02 ... and indeed look to be that old. So something's bollixed in the snapshot generation process. Historically the man.tar.gz files were created manually because there were some manual fixups needed to the generated man files. I'm not sure what vestiges of that still remain --- Peter's generally been the one to take care of it. But we definitely aren't shipping a freshly generated copy in the nightly snapshot right now. If we do have a fully automated process now, it's probably fair to ask why there's an internal tarball involved at all, rather than just shipping the built man1/ and man7/ subdirectories (and likewise for the html). Double compression of that data isn't going to be helpful. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Autoconf, libpq and replacement function
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Or in the same directly, called something else. Like fnmatchstub.h. See attached, seems reasonable? Seems okay to me. Note: in future, don't bother posting configure diffs; nobody wants to look at that, just the changes in the autoconf input files. Yea, it makes us ill, especially when it is the first diff in the patch. ;-) -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] RAM-only temporary tables
Sorry for the late response; I was on vacation. Heikki Linnakangas [EMAIL PROTECTED] wrote: Kevin, what was your original scenario like that led you to investigate this? We noticed a performance degradation in application code which, within a database transaction, looped through large numbers of iterations where each iteration created, used, and dropped a temporary table. The temporary table always had several columns (typically ten to twenty, many of which were varchar) and had a primary key. We initially thought this was because of an upgrade of PostgreSQL from 8.2.5 to 8.3.4, but subsequent testing showed that it was because of the concurrent update of the Linux kernel from one which defaulted to not using write barriers to one which did default to using write barriers. The file system was XFS on five spindles in RAID 5 on a good BBU controller. Updating the relevant /etc/fstab entry with nobarrier brought performance back to an acceptable level. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Window functions review
Just to let you know, I'm hacking this patch again, the executor part in particular. I've got a stripped out the unfinished window frame stuff, refactored the Window object API so that the window functions don't get to, and don't need to, access tuple slots directly. And a bunch of other simplifications as well. I'll post as soon as it's in a more readable state. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Window functions review
2008/11/22 Heikki Linnakangas [EMAIL PROTECTED]: Just to let you know, I'm hacking this patch again, the executor part in particular. I've got a stripped out the unfinished window frame stuff, refactored the Window object API so that the window functions don't get to, and don't need to, access tuple slots directly. And a bunch of other simplifications as well. I'll post as soon as it's in a more readable state. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com I'm so glad to hear that. Currently I don't have time to refactor much in executor, but only fixes such like what David reported. Feel free to ask me about any cut of the patch. Regards, -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1197)
Bruce Momjian wrote: KaiGai Kohei wrote: Bruce Momjian wrote: KaiGai Kohei wrote: Please consider SELinux/SE-PostgreSQL requires various kind of objects (including database objects) to be labeled properly at the initial state. If it allows clients to turn on row-level security feature, it means many unlabeled tuples appear suddenly. In generally, these have to be labeled before the system get being available. I was thinking more about people are using the SQL-level row permissions. Are they going to want it for all tables for all databases, or not at all? We don't have a reason why the SQL-level row permissions should be toggled in global only. It it designed based on DAC policy, so it is quite natural to be controled by owner of resources. (However, it is not implemented yet.) Yes, that was my question --- how will SQL-level row permissions be controlled by the user. When the given tuple has no ACL, it applies the default behavior which allows anything for public. This behavior intends to keep compatible works compared to the vanilla PostgreSQL. We can have two state for no ACLs. The first one is when tuples don't have fixed 4-bytes security attributes. It can be happen when PostgreSQL with SQL-level row-permissions mount compatible database files created by vanilla PostgreSQL. The other is the fixed 4-byte security attribute indicates an entry of no ACLs. It seems unnecessary consumption, but we cannot determine whether the user tries to set ACLs when heap_form_tuple(). One considerable solution is to add an RowACL specific table option to disable row-level ACLs whole of the tables. It can be suitable for security design because the option is provided by the resource owner. For example: CRATE TABLE t ( a int, b text ) WITH (row_acl=disable); If the reloptions contains an information to determine whether a new tuple need the security field, or not, we can reflect it at heap_form_tuple(). What I am saying is for the default compile, SQL-level ACLs should be possible because, since the ACL field has optional storage, there is no downside to have it be available by default. I think it is a possible and desirable desicion from the viewpoint of security folks. However, I think we have a few issues, and it makes unclear whether we can make an agreement in the community. The one is a cost of security hooks. They consume a bit more CPU steps when a security mechanism is enabled. The other is prevention to override a few hooks (ExecutorRun_hook and planner_hook), because they assume standard implementations to be executed. Which is more desirable option in the default? Thanks, -- KaiGai Kohei [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
