Re: [PATCHES] temporal version of generate_series()
Hello why you don't use polymorphic types? like: create or replace function generate_time_series(anyelement, anyelement, interval, OUT result anyelement) returns setof anyelement as $$ begin result := $1; while (result <= $2) loop return next; result := result + $3; end loop; return; end; $$ language plpgsql; Regards Pavel Stehule 2008/5/1 H. Harada <[EMAIL PROTECTED]>: > Here's the sync and updated patch. > It contains "strict" in catalog as well. > > Hitoshi Harada > > 2008/4/24 H. Harada <[EMAIL PROTECTED]>: >> 2008/4/23 Alvaro Herrera <[EMAIL PROTECTED]>: >> >> > H.Harada escribió: >> > >> > >> > > # This is my first time to send a patch. If I did something wrong, I >> > > appreciate your pointing me out. >> > >> > Brace positioning is off w.r.t. our conventions -- please fix that and >> > resubmit. >> >> Here's updated version. Thanks for your advice. >> >> Hitoshi Harada >> >> 2008/4/23 Alvaro Herrera <[EMAIL PROTECTED]>: >> >> >> > H.Harada escribió: >> > >> > >> > > # This is my first time to send a patch. If I did something wrong, I >> > > appreciate your pointing me out. >> > >> > Brace positioning is off w.r.t. our conventions -- please fix that and >> > resubmit. >> > >> > I have added this patch to the May commitfest. >> > >> > -- >> > Alvaro Herrera >> http://www.CommandPrompt.com/ >> > The PostgreSQL Company - Command Prompt, Inc. >> > >> > > > -- > Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-patches > > -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] temporal version of generate_series()
Here's the sync and updated patch. It contains "strict" in catalog as well. Hitoshi Harada 2008/4/24 H. Harada <[EMAIL PROTECTED]>: > 2008/4/23 Alvaro Herrera <[EMAIL PROTECTED]>: > > > H.Harada escribió: > > > > > > > # This is my first time to send a patch. If I did something wrong, I > > > appreciate your pointing me out. > > > > Brace positioning is off w.r.t. our conventions -- please fix that and > > resubmit. > > Here's updated version. Thanks for your advice. > > Hitoshi Harada > > 2008/4/23 Alvaro Herrera <[EMAIL PROTECTED]>: > > > > H.Harada escribió: > > > > > > > # This is my first time to send a patch. If I did something wrong, I > > > appreciate your pointing me out. > > > > Brace positioning is off w.r.t. our conventions -- please fix that and > > resubmit. > > > > I have added this patch to the May commitfest. > > > > -- > > Alvaro Herrera > http://www.CommandPrompt.com/ > > The PostgreSQL Company - Command Prompt, Inc. > > > generate_series_timestamp.20080501.patch.gz Description: GNU Zip compressed data -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] Proposed patch - psql wraps at window width
"Alvaro Herrera" <[EMAIL PROTECTED]> writes: > The fact that it's wrapped is not a new format in itself, just a property of > the aligned format. Well I agree I just don't see any benefit to presenting it that way. I mean, sure "wrapped" means "aligned and wrapped", but it's just shorthand notation anyways. In fact, it seems the only reason to separate the two like you're describing would be if it *were* possible to have a wrapped html. Then your notation could handle things "\pset format wrapped" couldn't: \pset format html:autowrap But I think we agree that isn't happening so why spell it "aligned:autowrap" instead of just "wrap"? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] Proposed patch - psql wraps at window width
Gregory Stark wrote: > "Alvaro Herrera" <[EMAIL PROTECTED]> writes: > > I think that could be fixed easily by having the syntax be something > > like > > > > \pset format aligned:80 > > \pset format aligned:autowrap > > I suppose. It seems kind of inconvenient though, what advantage does it have? Over what? I think having a separate "\pset format wrapped" does not make much sense. The fact that it's wrapped is not a new format in itself, just a property of the aligned format. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] libpq object hooks
Attached is an updated version of 'libpq object hooks'. The primary
purpose for libpq object hooks is to support our libpqtypes system
(not attached), but could possibly some nice sideband features to
libpq. We are hoping to sneak this into the May commit fest.
regards,
merlin
Index: exports.txt
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/exports.txt,v
retrieving revision 1.19
diff -C6 -r1.19 exports.txt
*** exports.txt 19 Mar 2008 00:39:33 - 1.19
--- exports.txt 30 Apr 2008 20:05:25 -
***
*** 138,143
--- 138,150
PQsendDescribePortal 136
lo_truncate 137
PQconnectionUsedPassword 138
pg_valid_server_encoding_id 139
PQconnectionNeedsPassword 140
lo_import_with_oid 141
+ PQcopyResult 142
+ PQsetvalue143
+ PQresultAlloc 144
+ PQaddObjectHooks 145
+ PQaddGlobalObjectHooks146
+ PQhookData147
+ PQresultHookData 148
\ No newline at end of file
Index: fe-connect.c
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.357
diff -C6 -r1.357 fe-connect.c
*** fe-connect.c 31 Mar 2008 02:43:14 - 1.357
--- fe-connect.c 30 Apr 2008 20:05:25 -
***
*** 241,253
PQExpBuffer errorMessage);
static char *pwdfMatchesString(char *buf, char *token);
static char *PasswordFromFile(char *hostname, char *port, char *dbname,
char *username);
static void default_threadlock(int acquire);
-
/* global variable because fe-auth.c needs to access it */
pgthreadlock_t pg_g_threadlock = default_threadlock;
/*
* Connecting to a Database
--- 241,252
***
*** 979,990
--- 978,990
* o If your backend wants to use Kerberos authentication then you must
* supply both a host name and a host address, otherwise this function
* may block on gethostname.
*
*
*/
+
PostgresPollingStatusType
PQconnectPoll(PGconn *conn)
{
PGresult *res;
char sebuf[256];
***
*** 998,1009
--- 998,1010
* We really shouldn't have been polled in these two cases, but we
* can handle it.
*/
case CONNECTION_BAD:
return PGRES_POLLING_FAILED;
case CONNECTION_OK:
+ pqInitObjectHooks(conn);
return PGRES_POLLING_OK;
/* These are reading states */
case CONNECTION_AWAITING_RESPONSE:
case CONNECTION_AUTH_OK:
{
***
*** 1816,1827
--- 1817,1829
conn->next_eo = EnvironmentOptions;
return PGRES_POLLING_WRITING;
}
/* Otherwise, we are open for business! */
conn->status = CONNECTION_OK;
+ pqInitObjectHooks(conn);
return PGRES_POLLING_OK;
}
case CONNECTION_SETENV:
/*
***
*** 1848,1859
--- 1850,1862
default:
goto error_return;
}
/* We are open for business! */
conn->status = CONNECTION_OK;
+ pqInitObjectHooks(conn);
return PGRES_POLLING_OK;
default:
printfPQExpBuffer(&conn->errorMessage,
libpq_gettext(
"invalid connection state %c, "
***
*** 1875,1887
* the connection structure must be freed).
*/
conn->status = CONNECTION_BAD;
return PGRES_POLLING_FAILED;
}
-
/*
* makeEmptyPGconn
* - create a PGconn data structure with (as yet) no interesting data
*/
static PGconn *
makeEmptyPGconn(void)
--- 1878,1889
***
*** 1970,1981
--- 1972,2001
* release data that is to be held for the life of the PGconn structure.
* If a value ought to be cleared/freed during PQreset(), do it there not here.
*/
static void
freePGconn(PGconn *conn)
{
+ int i;
+
+ for(i=0; i < conn->objHooksCount; i++)
+ {
+ if(conn->objHooks[i].connDestroy)
+ {
+ conn->objHooks[i].connDestroy((const PGconn *)conn);
+ free(conn->objHooks[i].name);
+ }
+ }
+
+ if(conn->objHooks)
+ {
+ free(conn->objHooks);
+ conn->objHooks = NULL;
+ conn->objHooksCount = conn->objHooksSize = 0;
+ }
+
if (conn->pghost)
free(conn->pghost);
if (conn->pghostaddr)
free(conn->pghostaddr);
if (conn->pgport)
free(conn->pgport);
***
*** 2151,2164
PQreset(PGconn *conn)
{
if (conn)
{
closePGconn(conn);
! if (connectDBStart(conn))
! (void) connectDBComplete(conn);
}
}
/*
* PQresetStart:
--- 2171,2189
PQreset(PGconn *conn)
{
if (conn)
{
closePGconn(conn);
! if (connectDBStart(conn) && connectDBComplete(conn))
! {
! int i;
! for(i=0; i < conn->objHooksCount; i++)
! if(conn->objHooks[i].connReset)
! conn->objHooks[i].connReset((const PGconn *)conn);
! }
}
}
/*
* PQresetStart:
***
*** 21
Re: [PATCHES] pg_postmaster_reload_time() patch
On Wed, Apr 30, 2008 at 8:16 AM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> George Gensure escribió:
>
>
> > I've done a quick write up for reload time reporting from the
> > administration TODO. I was a little paranoid with the locking, but
> > didn't want problems to occur with signals on the postmaster and the
> > read side.
>
> I'd say too much -- postmaster runs with signals blocked all the time
> (except during select()) so this is not necessary there.
>
> Regarding the locking on backends, I admit I am not sure if this is
> really a problem enough that you need a spinlock for it. Anyway we tend
> not to use spinlocks too much -- probably an LWLock would be more
> apropos, if a lock is really needed. (A bigger question is whether the
> reload time should be local for each backend, or exposed globally
> through MyProc. I don't think it's interesting enough to warrant that,
> but perhaps others think differently.)
>
> Lastly, I didn't read the patch close enough to tell if it would work on
> both the EXEC_BACKEND case and the regular one.
>
> --
> Alvaro Herrerahttp://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
I've reworked the patch in response to comments.
The new function name is pg_conf_load_time()
I'm now using LWLocks only on the backend in order to protect the
PgReloadTime from mid copy reads. This may prove to be unnecessary,
since the code to handle HUPs seems to be executed synchronously on
the backend, but I'll let someone else tell me its safe before
removing it.
-George
*** ./doc/src/sgml/func.sgml.orig 2008-04-29 23:47:39.378726574 -0400
--- ./doc/src/sgml/func.sgml 2008-04-30 11:31:38.434893712 -0400
***
*** 10892,10897
--- 10892,10903
+pg_conf_load_time()
+timestamp with time zone
+config load time
+
+
+
session_user
name
session user name
***
*** 11037,11042
--- 11043,11062
+ pg_conf_load_time
+
+
+
+ pg_conf_load_time returns the
+ timestamp with time zone when the
+ config was last loaded for this session.
+
+
+
+ version
+
+
+
version
*** ./src/backend/postmaster/postmaster.c.orig 2008-04-29 23:48:07.374455697 -0400
--- ./src/backend/postmaster/postmaster.c 2008-04-30 12:02:05.156215936 -0400
***
*** 390,395
--- 390,396
InheritableSocket pgStatSock;
pid_t PostmasterPid;
TimestampTz PgStartTime;
+ TimestampTz PgReloadTime;
bool redirection_done;
#ifdef WIN32
HANDLE PostmasterHandle;
***
*** 1008,1013
--- 1009,1015
* Remember postmaster startup time
*/
PgStartTime = GetCurrentTimestamp();
+ PgReloadTime = PgStartTime;
/* PostmasterRandom wants its own copy */
gettimeofday(&random_start_time, NULL);
***
*** 1931,1936
--- 1933,1943
/* Update the starting-point file for future children */
write_nondefault_variables(PGC_SIGHUP);
#endif
+
+ /*
+ * Remember config load time
+ */
+ PgReloadTime = GetCurrentTimestamp();
}
PG_SETMASK(&UnBlockSig);
***
*** 4263,4268
--- 4270,4276
param->PostmasterPid = PostmasterPid;
param->PgStartTime = PgStartTime;
+ param->PgReloadTime = PgReloadTime;
param->redirection_done = redirection_done;
*** ./src/backend/tcop/postgres.c.orig 2008-04-29 23:48:58.866600196 -0400
--- ./src/backend/tcop/postgres.c 2008-04-30 12:21:40.476913468 -0400
***
*** 58,63
--- 58,64
#include "storage/ipc.h"
#include "storage/proc.h"
#include "storage/sinval.h"
+ #include "storage/spin.h"
#include "tcop/fastpath.h"
#include "tcop/pquery.h"
#include "tcop/tcopprot.h"
***
*** 3375,3380
--- 3376,3382
*/
if (!IsUnderPostmaster)
PgStartTime = GetCurrentTimestamp();
+ PgReloadTime = PgStartTime;
/*
* POSTGRES main processing loop begins here
***
*** 3550,3555
--- 3552,3564
{
got_SIGHUP = false;
ProcessConfigFile(PGC_SIGHUP);
+
+ /*
+ * Remember config load time
+ */
+ LWLockAcquire(ReloadTimeLock, LW_EXCLUSIVE);
+ PgReloadTime = GetCurrentTimestamp();
+ LWLockRelease(ReloadTimeLock);
}
/*
*** ./src/backend/utils/adt/timestamp.c.orig 2008-04-29 23:49:46.359354923 -0400
--- ./src/backend/utils/adt/timestamp.c 2008-04-30 12:23:52.456779063 -0400
***
*** 42,47
--- 42,49
/* Set at postmaster start */
TimestampTz PgStartTime;
+ /* Set at configuration reload */
+ TimestampTz PgReloadTime;
static TimeOffset time2t(const int hour, const int min, const int sec, const fsec_t fsec);
***
*** 1162,1167
--- 1164,1179
PG_RETURN_TIMESTAMPTZ(PgStartTime);
}
+ Datum
+ pgsql_conf_load_time(PG_FUNCTION_ARGS)
+ {
+ TimestampTz ti
Re: [PATCHES] Patch to add a feature to pg_standby
On Wed, 2008-04-30 at 08:29 -0700, David Fetter wrote: > On Wed, Apr 30, 2008 at 03:43:54PM +0100, Simon Riggs wrote: > > On Wed, 2008-04-30 at 07:31 -0700, David Fetter wrote: > > > On Wed, Apr 30, 2008 at 12:49:44PM +0100, Simon Riggs wrote: > > > > On Wed, 2008-04-30 at 11:29 +0100, Heikki Linnakangas wrote: > > > > > This could be implemented by a "pass-through" restore_command, > > > > > that calls pg_standby, and does the custom action when > > > > > pg_standby returns successfully. > > > > > > > > Yes, that's the preferred route for most cases. > > > > > > > > pg_standby was designed to be customisable, so if it works for > > > > Chris, thats OK. > > > > > > > > After some mulling on this, I'm not sure we need to include this > > > > in pg_standby however. If we did we'd end up having before/after > > > > commands and retry options etc. > > > > > > Would those be good things to have as a whole package? > > > > I think the answer is we already do. It's called bash. > > Just a stray thought...bash doesn't run very well on common Windows > installations. True, but you can run anything you choose... -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to add a feature to pg_standby
On Wed, Apr 30, 2008 at 03:43:54PM +0100, Simon Riggs wrote: > On Wed, 2008-04-30 at 07:31 -0700, David Fetter wrote: > > On Wed, Apr 30, 2008 at 12:49:44PM +0100, Simon Riggs wrote: > > > On Wed, 2008-04-30 at 11:29 +0100, Heikki Linnakangas wrote: > > > > This could be implemented by a "pass-through" restore_command, > > > > that calls pg_standby, and does the custom action when > > > > pg_standby returns successfully. > > > > > > Yes, that's the preferred route for most cases. > > > > > > pg_standby was designed to be customisable, so if it works for > > > Chris, thats OK. > > > > > > After some mulling on this, I'm not sure we need to include this > > > in pg_standby however. If we did we'd end up having before/after > > > commands and retry options etc. > > > > Would those be good things to have as a whole package? > > I think the answer is we already do. It's called bash. Just a stray thought...bash doesn't run very well on common Windows installations. 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-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to add a feature to pg_standby
On Wed, 2008-04-30 at 07:31 -0700, David Fetter wrote: > On Wed, Apr 30, 2008 at 12:49:44PM +0100, Simon Riggs wrote: > > On Wed, 2008-04-30 at 11:29 +0100, Heikki Linnakangas wrote: > > > This could be implemented by a "pass-through" restore_command, > > > that calls pg_standby, and does the custom action when pg_standby > > > returns successfully. > > > > Yes, that's the preferred route for most cases. > > > > pg_standby was designed to be customisable, so if it works for > > Chris, thats OK. > > > > After some mulling on this, I'm not sure we need to include this in > > pg_standby however. If we did we'd end up having before/after > > commands and retry options etc. > > Would those be good things to have as a whole package? I think the answer is we already do. It's called bash. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to add a feature to pg_standby
On Wed, Apr 30, 2008 at 12:49:44PM +0100, Simon Riggs wrote: > On Wed, 2008-04-30 at 11:29 +0100, Heikki Linnakangas wrote: > > This could be implemented by a "pass-through" restore_command, > > that calls pg_standby, and does the custom action when pg_standby > > returns successfully. > > Yes, that's the preferred route for most cases. > > pg_standby was designed to be customisable, so if it works for > Chris, thats OK. > > After some mulling on this, I'm not sure we need to include this in > pg_standby however. If we did we'd end up having before/after > commands and retry options etc. Would those be good things to have as a whole package? 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-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] fix for pl/pythons named OUT parameter handling
Before this patch, pl/python will not do the right thing if OUT
parameters are present
Hannu
Index: plpython/plpython.c
===
RCS file: /projects/cvsroot/pgsql/src/pl/plpython/plpython.c,v
retrieving revision 1.106
diff -c -r1.106 plpython.c
*** plpython/plpython.c 2 Jan 2008 03:10:27 - 1.106
--- plpython/plpython.c 29 Apr 2008 20:40:53 -
***
*** 1159,1167
bool isnull;
int i,
rv;
- Datum argnames;
- Datum *elems;
- int nelems;
procStruct = (Form_pg_proc) GETSTRUCT(procTup);
--- 1159,1164
***
*** 1250,1304
* now get information required for input conversion of the
* procedure's arguments.
*/
! proc->nargs = procStruct->pronargs;
! if (proc->nargs)
! {
! argnames = SysCacheGetAttr(PROCOID, procTup, Anum_pg_proc_proargnames, &isnull);
! if (!isnull)
! {
! /* XXX this code is WRONG if there are any output arguments */
! deconstruct_array(DatumGetArrayTypeP(argnames), TEXTOID, -1, false, 'i',
! &elems, NULL, &nelems);
! if (nelems != proc->nargs)
! elog(ERROR,
! "proargnames must have the same number of elements "
! "as the function has arguments");
! proc->argnames = (char **) PLy_malloc(sizeof(char *) * proc->nargs);
! memset(proc->argnames, 0, sizeof(char *) * proc->nargs);
! }
! }
! for (i = 0; i < proc->nargs; i++)
! {
HeapTuple argTypeTup;
Form_pg_type argTypeStruct;
! argTypeTup = SearchSysCache(TYPEOID,
! ObjectIdGetDatum(procStruct->proargtypes.values[i]),
! 0, 0, 0);
! if (!HeapTupleIsValid(argTypeTup))
! elog(ERROR, "cache lookup failed for type %u",
! procStruct->proargtypes.values[i]);
! argTypeStruct = (Form_pg_type) GETSTRUCT(argTypeTup);
! /* Disallow pseudotype argument */
! if (argTypeStruct->typtype == TYPTYPE_PSEUDO)
! ereport(ERROR,
! (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
! errmsg("plpython functions cannot take type %s",
! format_type_be(procStruct->proargtypes.values[i];
!
! if (argTypeStruct->typtype != TYPTYPE_COMPOSITE)
! PLy_input_datum_func(&(proc->args[i]),
! procStruct->proargtypes.values[i],
! argTypeTup);
! else
! proc->args[i].is_rowtype = 2; /* still need to set I/O funcs */
! ReleaseSysCache(argTypeTup);
! /* Fetch argument name */
! if (proc->argnames)
! proc->argnames[i] = PLy_strdup(DatumGetCString(DirectFunctionCall1(textout, elems[i])));
}
/*
--- 1247,1309
* now get information required for input conversion of the
* procedure's arguments.
*/
!
! if (procStruct->pronargs) {
HeapTuple argTypeTup;
Form_pg_type argTypeStruct;
! Oid *types;
! char **names,
! *modes;
! int i,
! pos,
! total;
!
! total = get_func_arg_info(procTup, &types, &names, &modes);
! if (modes == NULL)
! proc->nargs = procStruct->pronargs;
! else
! /* count number of 'i?' args into proc->nargs*/
! for (i = 0;i < total;i++) {
! if (modes[i] != 'o') (proc->nargs)++;
! }
! proc->argnames = (char **) PLy_malloc(sizeof(char *) * proc->nargs);
! for (i = pos = 0;i < total;i++) {
! if (modes && modes[i] == 'o') /* skip OUT arguments */
! continue;
!
! Assert(types[i] == procStruct->proargtypes.values[i]);
!
! argTypeTup = SearchSysCache(TYPEOID,ObjectIdGetDatum(types[i]), 0, 0, 0);
! if (!HeapTupleIsValid(argTypeTup))
! elog(ERROR, "cache lookup failed for type %u",
! procStruct->proargtypes.values[i]);
! argTypeStruct = (Form_pg_type) GETSTRUCT(argTypeTup);
!
! switch (argTypeStruct->typtype) {
! case TYPTYPE_PSEUDO:
! ereport(ERROR,
! (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
! errmsg("plpython functions cannot take type %s",
! format_type_be(types[i];
! case TYPTYPE_COMPOSITE:
! proc->args[pos].is_rowtype = 2; /* set IO funcs at first call*/
! break;
! default:
! PLy_input_datum_func(&(proc->args[pos]),
! types[i],
! argTypeTup);
! }
! ReleaseSysCache(argTypeTup);
! /* get argument name */
! proc->argnames[pos] = names ? PLy_strdup(names[i]) : NULL;
!
! pos++;
!
! }
}
/*
Index: plpython/expected/plpython_function.out
===
RCS file: /projects/cvsroot/pgsql/src/pl/plpython/expected/plpython_function.out,v
retrieving revision 1.10
diff -c -r1.10 plpython_function.out
*** plpython/expected/plpython_function.out 16 Oct 2006 21:13:57 - 1.10
--- plpython/expected/plpython_function.out 29 Apr 2008 20:40:59 -
***
*** 436,438
--- 436,447
type_record.second = second
return type_record
$$ LANGUAGE plpythonu;
+ CREATE FUNCTION test_in_out_params(f
Re: [PATCHES] Patch to add a feature to pg_standby
Simon Riggs <[EMAIL PROTECTED]> wrote on 04/30/2008 07:49:44 AM: > On Wed, 2008-04-30 at 11:29 +0100, Heikki Linnakangas wrote: > > [EMAIL PROTECTED] wrote: > > > When using pg_standby to remain in recovery mode on a warm standby system, > > > if there is a need to perform other actions in coordination with recovery > > > actions, the -x option implemented by this patch > > > enables that coordination. I considered adding the ability to > override the > > > restoreCommand, however by keeping this separate and optional it is > > > possible to force retries of the auxiliary command until successful and > > > still utilize pg_usleep instead of looping within an external script or > > > command. And the previous behavior of pg_standby remains unchanged (other > > > than debug logging and documenting the option in usage) if the new option > > > is omitted. > > > > > > I added this feature to help with synchronization of a content repository > > > consisting of a PostgreSQL db for meta-information and a separate file > > > store for content. > > > The auxiliary command enables forcing an rsync of the file storethat is at > > > least as current as the found WAL segment file's db changes, and prevents > > > recovery of that WAL file unless the rsync can be performed successfully. > > > > > > (See attached file: pg_standby.c.diff) > > > > This could be implemented by a "pass-through" restore_command, that > > calls pg_standby, and does the custom action when pg_standby returns > > successfully. > > Yes, that's the preferred route for most cases. > > pg_standby was designed to be customisable, so if it works for Chris, > thats OK. > > After some mulling on this, I'm not sure we need to include this in > pg_standby however. If we did we'd end up having before/after commands > and retry options etc. > > -- > Simon Riggs > 2ndQuadrant http://www.2ndQuadrant.com > I did not wish to presume that the WAL file being copied or linked into the destination would cause no issues should the engine be shutdown during my custom action or retry loop, and subsequently restarted in recovery mode. Which is why I chose to insert executing the command after determining that the file was available, but before the mv/cp. I like your suggestion of before/after commands and retry options. It offers flexibility in pg_standby far beyond my specific needs. Not having studied internals of postgres I am not sure, but it seemed to me that the other value provided by this implementation instead of a 'pass-through' restore command is the use of pg_usleep in retry loops. If pg_standby were not to provide that retry loop for the after command, then another program would need to be written to do that. Adding the feature to pg_standby seemed the more elegant implementation. But if pg_usleep accomplishes nothing more than a sleep in a script would, then implementing the loop in pg_standby provides a trivial advantage. Chris -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Documentation: ALTER ROLE - no password
Andreas 'ads' Scherbaum wrote: > > Hello, > > i've seen the question "how to remove a password" now several times in > the last weeks. Attached is a small patch which add a new example for > the "ALTER ROLE" documentation. Applied, thanks. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] pg_postmaster_reload_time() patch
George Gensure escribió: > I've done a quick write up for reload time reporting from the > administration TODO. I was a little paranoid with the locking, but > didn't want problems to occur with signals on the postmaster and the > read side. I'd say too much -- postmaster runs with signals blocked all the time (except during select()) so this is not necessary there. Regarding the locking on backends, I admit I am not sure if this is really a problem enough that you need a spinlock for it. Anyway we tend not to use spinlocks too much -- probably an LWLock would be more apropos, if a lock is really needed. (A bigger question is whether the reload time should be local for each backend, or exposed globally through MyProc. I don't think it's interesting enough to warrant that, but perhaps others think differently.) Lastly, I didn't read the patch close enough to tell if it would work on both the EXEC_BACKEND case and the regular one. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to add a feature to pg_standby
On Wed, 2008-04-30 at 11:29 +0100, Heikki Linnakangas wrote: > [EMAIL PROTECTED] wrote: > > When using pg_standby to remain in recovery mode on a warm standby system, > > if there is a need to perform other actions in coordination with recovery > > actions, the -x option implemented by this patch > > enables that coordination. I considered adding the ability to override the > > restoreCommand, however by keeping this separate and optional it is > > possible to force retries of the auxiliary command until successful and > > still utilize pg_usleep instead of looping within an external script or > > command. And the previous behavior of pg_standby remains unchanged (other > > than debug logging and documenting the option in usage) if the new option > > is omitted. > > > > I added this feature to help with synchronization of a content repository > > consisting of a PostgreSQL db for meta-information and a separate file > > store for content. > > The auxiliary command enables forcing an rsync of the file store that is at > > least as current as the found WAL segment file's db changes, and prevents > > recovery of that WAL file unless the rsync can be performed successfully. > > > > (See attached file: pg_standby.c.diff) > > This could be implemented by a "pass-through" restore_command, that > calls pg_standby, and does the custom action when pg_standby returns > successfully. Yes, that's the preferred route for most cases. pg_standby was designed to be customisable, so if it works for Chris, thats OK. After some mulling on this, I'm not sure we need to include this in pg_standby however. If we did we'd end up having before/after commands and retry options etc. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to add a feature to pg_standby
[EMAIL PROTECTED] wrote: When using pg_standby to remain in recovery mode on a warm standby system, if there is a need to perform other actions in coordination with recovery actions, the -x option implemented by this patch enables that coordination. I considered adding the ability to override the restoreCommand, however by keeping this separate and optional it is possible to force retries of the auxiliary command until successful and still utilize pg_usleep instead of looping within an external script or command. And the previous behavior of pg_standby remains unchanged (other than debug logging and documenting the option in usage) if the new option is omitted. I added this feature to help with synchronization of a content repository consisting of a PostgreSQL db for meta-information and a separate file store for content. The auxiliary command enables forcing an rsync of the file store that is at least as current as the found WAL segment file's db changes, and prevents recovery of that WAL file unless the rsync can be performed successfully. (See attached file: pg_standby.c.diff) This could be implemented by a "pass-through" restore_command, that calls pg_standby, and does the custom action when pg_standby returns successfully. Or perhaps you could run the custom action in whatever script is copying the files to the directory. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] pg_postmaster_reload_time() patch
Gurjeet Singh wrote: On Wed, Apr 30, 2008 at 9:53 AM, George Gensure <[EMAIL PROTECTED]> wrote: I've done a quick write up for reload time reporting from the administration TODO. I was a little paranoid with the locking, but didn't want problems to occur with signals on the postmaster and the read side. IMHO, the function should return NULL if the postmaster never reloaded; that is, it was started, but never signaled to reload. I think it's useful to get the server startup time if the configuration has never been reloaded. That's when the configuration was loaded, if no reload has been triggered since. Perhaps the function should be named to reflect that better. pg_configuration_load_time() ? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
