Re: [HACKERS] Recent buildfarm failures involving statement_timeout
Andrew Dunstan wrote: Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: pgbfprod=# select sysname, snapshot from build_status_log where branch = 'HEAD' and log_stage = 'check.log' and log_text ~ $$\+ ERROR: canceling statement due to statement timeout$$; sysname | snapshot -+- fennec | 2008-03-06 01:10:02 heron | 2008-03-11 18:06:01 heron | 2008-03-11 23:06:01 heron | 2008-04-20 00:06:01 cobra | 2008-04-26 04:15:02 heron | 2008-04-27 00:06:01 (6 rows) Hmm, were there any matches in non-HEAD tests? sysname | snapshot |branch -+-+--- lionfish | 2007-04-19 09:30:27 | REL8_2_STABLE lionfish | 2007-05-29 23:30:07 | REL8_1_STABLE lionfish | 2007-09-22 23:30:07 | REL8_1_STABLE lionfish is(or rather was - powersupply got fried and I have no replacement yet) one of the slowest machines(250MHZ mipsel,48MB RAM) on the buildfarm (took about 5-6h for a complete run). Stefan -- 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] MERGE Specification
On Fri, 2008-04-25 at 09:10 -0400, Alvaro Herrera wrote: > Simon Riggs wrote: > > > I'm now happy that we can get a spec-compliant end result by always > > forcing NOT MATCHED rules to occur before MATCHED rules, when we have at > > least one unique index. > > ... and raise an ERROR when there is no unique index? No, I think an ERROR is not required, nor desirable. In the absence of a unique index we allow exactly duplicate rows to exist in a table. This is effectively user defined behaviour, albeit the default setting. We have two choices of behaviour: 1. If a MERGE statement runs and sees a row in the target table is NOT MATCHED then it will insert a row. It is possible that a concurrent MERGE statement could also see the row in the target table as NOT MATCHED and then insert a duplicate row. 2. In the absence of a Unique Index, throw an ERROR because a concurrent MERGE *might* result in duplicate Inserts. (i.e. prevent the above). (1) is a situation possible with concurrent INSERTs into a table without a unique index, so I see no reason to make MERGE follow (2) when INSERTs do not. Also, it is possible for a MERGE to generate duplicate rows in a table if the INSERT clause contained constants for example. In the absence of an applicable rule the MERGE will generate INSERT DEFAULT VALUES, i.e. an all-constant insert will take place. So the MERGE spec allows the inserting of duplicate rows without error. We could include additional options to control this behaviour, if anyone thinks it worthwhile, but ISTM more restrictive than protective. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.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] Re: [COMMITTERS] pgsql: Update: < * Allow adding enumerated values to an existing
> I don't understand this if it's calling option 2 the monolithic > implementation. I was intending that the values be permanent tokens if > you like, so that ZERO rewriting would be required for any types of > modification. So I don't see where locking comes in. I don't want > rewriting either. I think you are not considering existing btree indexes here (for the reordering case) ? So +1 on a solution that has naturally sorting keys (e.g. your 1). Andreas -- 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] MERGE Specification
On 4/25/08, Robert Treat <[EMAIL PROTECTED]> wrote: > On Thursday 24 April 2008 23:40, Tom Lane wrote: > > Robert Treat <[EMAIL PROTECTED]> writes: > > > Perhaps a better option would be to implement Merge per spec, and then > > > implement a "replace into" command for the oltp scenario. This way you > > > keep the spec behavior for the spec syntax, and have a clearly non-spec > > > command for non-spec behavior. > > > > In that case, it's a fair question to ask just who will use the "spec" > > syntax. As far as I can tell from years of watching the mailing lists, > > there is plenty of demand for a concurrent-safe insert-or-update > > behavior, and *exactly zero* demand for the other. I challenge you to > > find even one request for the "spec" behavior in the mailing list > > archives. (Simon doesn't count.) > > > > > AIUI the current implementation is designed to avoid race conditions partially > at the cost of being insert friendly and somewhat update unfriendly. My guess > is that most of the people wanting this for OLTP use want an update friendly > implementation (that's certainly been the majority of cases I've needed > myself, and that I have seen others use). This seems to hint that there should be 2 variants of merge/upsert - insert-friendly and update-friendly... It seems unlikely one implementation can be both. And especially bad would be implementation that is neither. -- marko -- 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] Proposed patch - psql wraps at window width
"Bryce Nesbitt" <[EMAIL PROTECTED]> writes: > Unless they are in the habit of doing: > > # COLUMNS=$COLUMNS ls -C |cat Some of us are actually in the habit of doing that because it's easier to use the standard interface than remembering the different command-line option for each command. I quite often do precisely that with dpkg, for example. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres 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] MERGE Specification
On Mon, 2008-04-28 at 11:57 +0300, Marko Kreen wrote: > On 4/25/08, Robert Treat <[EMAIL PROTECTED]> wrote: > > On Thursday 24 April 2008 23:40, Tom Lane wrote: > > > Robert Treat <[EMAIL PROTECTED]> writes: > > > > Perhaps a better option would be to implement Merge per spec, and then > > > > implement a "replace into" command for the oltp scenario. This way you > > > > keep the spec behavior for the spec syntax, and have a clearly non-spec > > > > command for non-spec behavior. > > > > > > In that case, it's a fair question to ask just who will use the "spec" > > > syntax. As far as I can tell from years of watching the mailing lists, > > > there is plenty of demand for a concurrent-safe insert-or-update > > > behavior, and *exactly zero* demand for the other. I challenge you to > > > find even one request for the "spec" behavior in the mailing list > > > archives. (Simon doesn't count.) > > > > > > > > > AIUI the current implementation is designed to avoid race conditions > > partially > > at the cost of being insert friendly and somewhat update unfriendly. My > > guess > > is that most of the people wanting this for OLTP use want an update > > friendly > > implementation (that's certainly been the majority of cases I've needed > > myself, and that I have seen others use). > > This seems to hint that there should be 2 variants of merge/upsert > - insert-friendly and update-friendly... It seems unlikely one implementation > can be both. And especially bad would be implementation that is neither. Not sure what an option that was "neither" would look like ... I would summarise the two MERGE behaviour proposals as 1. Correctly protects against concurrent inserts. Uses one sub-transaction per row and leaves 2 dead rows per update. Requires us to perform tasks in different order than required by SQL spec, but the end result seems identical to me (now). Has been noted as suitable for OLTP, and poor for bulk data maintenance. Has been described as "insert-friendly" and "non-spec". 2. Does not protect against concurrent inserts. Leaves 1 dead row per update. Much more efficient for updates, not sure about any efficiency gain for inserts. Has been noted as being unsuitable for OLTP, though likely to offer more acceptable performance for bulk operations. Has been described as "update-friendly". By consensus, I'm doing (1). It looks likely that doing (2) should be fairly small change and so can be offered as an option. For example, we can have an additional action-order clause with two options (the first of which is default) [INSERT BEFORE UPDATE ACTION ORDER | DEFAULT ACTION ORDER] So the default is to force inserts to occur before updates, as required by (1). The other option "DEFAULT ACTION ORDER" tests the WHEN clauses in the order specified in the statement, allowing the user to choose whether they want to test for updates or inserts first. Overall, the difference between these behaviours is small in comparison with making MERGE work in the first place... -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] SRF in SFRM_ValuePerCall mode
Hi all,
I am working on implementation of custom "C" SRF for our team. The SRF uses
SFRM_ValuePerCall mode. I know that sometimes even in SFRM_ValuePerCall mode
all the rows returned from SRF are "materialized" (for performing JOINs, for
example). But it looks like even in cases when SELECT is very simple and
it's obvious that no more rows will be read from the SRF, SRF is being
iterated till it returns SRF_RETURN_DONE(...). So, in case when the SRF
returns 1000 rows but the SELECT is querying only the first one (with LIMIT
1), all 1000 iterations will be performed and 999 rows will be created,
allocated, returned and thrown away.
Is there a way to avoid unnecessary calls of SRF in this case? Is it a
"feature"?
In the attachment you can find the simplest example of SRF function working
in SFRM_ValuePerCall mode.
I have created it while researching the issue. After building it, use the
following SQLs:
-- this creates the test function
CREATE OR REPLACE FUNCTION vpc() RETURNS setof record
AS 'plbsh.dll', 'vpc' LANGUAGE 'C';
-- this returns 10 rows
SELECT * FROM vpc() AS T(a INT, b TEXT);
-- this returns 1 row, but performs 10 calls
SELECT * FROM vpc() AS T(a INT, b TEXT) LIMIT 1;
Regards,
Denis
#include "executor/spi.h"
#include "fmgr.h"
#include "funcapi.h"
#include "miscadmin.h"
#include "postgres.h"
#include "access/heapam.h"
#include "catalog/pg_proc.h"
#include "catalog/pg_type.h"
#include "commands/trigger.h"
#include "storage/ipc.h"
#include "utils/date.h"
#include "utils/memutils.h"
#include "utils/syscache.h"
#ifdef PG_MODULE_MAGIC
PG_MODULE_MAGIC;
#endif
/*
CREATE OR REPLACE FUNCTION vpc() RETURNS setof record
AS 'plbsh.dll', 'vpc' LANGUAGE 'C';
SELECT * FROM vpc() AS T(a INT, b TEXT);
SELECT * FROM vpc() AS T(a INT, b TEXT) LIMIT 1;
*/
extern Datum vpc(PG_FUNCTION_ARGS);
PG_FUNCTION_INFO_V1(vpc);
Datum vpc(PG_FUNCTION_ARGS)
{
ReturnSetInfo* rsinfo;
FuncCallContext *funcctx;
int current = 0;
rsinfo = (ReturnSetInfo*) fcinfo->resultinfo;
if (!rsinfo)
ereport(ERROR, (errmsg("Invalid ReturnSetInfo in SRF")));
if (!(rsinfo->allowedModes & SFRM_ValuePerCall))
ereport(ERROR, (errmsg("Function must support returning a SETOF
composite type in SFRM_ValuePerCall mode")));
if (SRF_IS_FIRSTCALL())
{
MemoryContext oldcontext;
funcctx = SRF_FIRSTCALL_INIT();
oldcontext =
MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
funcctx->attinmeta =
TupleDescGetAttInMetadata(rsinfo->expectedDesc);
funcctx->user_fctx = (void*)(int*)palloc(sizeof(int));
*((int*)funcctx->user_fctx) = 0;
MemoryContextSwitchTo(oldcontext);
}
rsinfo->returnMode = SFRM_ValuePerCall;
rsinfo->setDesc = rsinfo->expectedDesc;
funcctx = SRF_PERCALL_SETUP();
current = *((int*)funcctx->user_fctx);
ereport(WARNING, (errmsg("## Call#%d", current)));
if(current >= 10)
{
ereport(WARNING, (errmsg("## Last Call")));
SRF_RETURN_DONE(funcctx);
}
else
{
char buffer[100];
char* values[2];
HeapTuple tuple;
Datum result;
sprintf(buffer, "%d", current++);
*((int*)funcctx->user_fctx) = current;
values[0] = buffer;
values[1] = buffer;
tuple = BuildTupleFromCStrings(funcctx->attinmeta, values);
result = TupleGetDatum(slot, tuple);
ereport(WARNING, (errmsg("## (return)", current)));
SRF_RETURN_NEXT(funcctx, result);
}
}
--
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] SRF in SFRM_ValuePerCall mode
dv @ nabble wrote: I am working on implementation of custom "C" SRF for our team. The SRF uses SFRM_ValuePerCall mode. I know that sometimes even in SFRM_ValuePerCall mode all the rows returned from SRF are "materialized" (for performing JOINs, for example). Yep, they are unfortunately always materialized. Back when set returning functions were implemented, the original patch did actually support true "value per call" mode, where the whole result set was not materialized. However, it was dropped because of some issues I can't remember off the top of my head. The value-per-call API was committed, so that it was already in place when someone gets around to implement the backend support for it. However, no-one has bothered to do that to this date. Hannu Krosing showed some interest in it recently, though: http://archives.postgresql.org/pgsql-hackers/2008-04/msg00345.php. I would love to see it happen. -- 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] Re: [COMMITTERS] pgsql: Update: < * Allow adding enumerated values to an existing
On Mon, Apr 28, 2008 at 2:24 PM, Zeugswetter Andreas OSB SD <[EMAIL PROTECTED]> wrote: > I think you are not considering existing btree indexes here > (for the reordering case) ? You're quite right, I had not considered existing indexes. There's no easy way to deal with that other than rebuilding them. :( I *still* think someone with a big table would prefer to drop/create their indexes rather than go through a nasty ALTER COLUMN which would have the seemingly much worse outcome of rebuilding their whole table AND any indexes. But whatever - I'll implement option 1 and submit it, as a marked improvement over the status quo. If I can make option 2 work fast enough I'll consider submitting it as a feature improvement thereafter, but given the general consensus for option 1 I'm not pushing option 2 much any more. Cheers Tom -- 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] we don't have a bugzilla
Shane Ambler wrote: > Andrew Sullivan wrote: >> Maybe because there's a perfectly functional archive link in the mail >> headers? And because there's an RFC that tells us how such headers >> are supposed to work? > > As a lot of people use gui apps, (I do seem to recall that mail cli > shows the full headers) most would never see the detailed headers of an > email. I know I very rarely look at the full source of an email. So the proper thing to do is complain to the writer of the GUI app so that it has an option for showing the list headers, perhaps adding a menu entry when they are found. CLI email clients do not typically show the full headers -- the user must ask for them, just like a GUI app. Most of the time I don't look at the source of emails either. -- 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
[HACKERS] PQexecPrepared with cursor to fetch single results
if you need a scrollable cursor for a prepared statement (to fetch single rows from huge result sets) while still being able to execute statements on the same connection you can do it this way: PGresult* res = PQprepare( con, "statement1", "declare cu1 scroll cursor with hold for select * from table where col1=$1", 0, NULL ); PGresult* res2 = PQdescribePrepared( con, "statement1" ); //now use PQnparams and PQnparamtype to determine parameter information //and set paramCount, paramValues and paramLength accordingly PGresult* res3 = PQexecPrepared( con, "statement1", paramCount, paramValues, paramLength, paramFormat, 0 ); PGresult* res4 = PQexec( con, "fetch forward 100 from cu1" ); //to receive 100 rows from the server //now with PQnfields, PQftype and PQfname and PQgetvalue access the result - and other queries can be executed on the same connection -- 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] pgstat SRF?
Magnus Hagander wrote:
> Tom Lane wrote:
> > Magnus Hagander <[EMAIL PROTECTED]> writes:
> > > While looking over the statistics-for-functions patch
> > > (http://archives.postgresql.org/pgsql-patches/2008-03/msg00300.php),
> > > I came back to a thought I've had before - why do we keep one
> > > function per column for pgstat functions, instead of using a set
> > > returning function? Is there some actual reason for this, or is it
> > > just legacy from a time when it was (much) harder to write SRFs?
> >
> > I think it's so that you can build your own stats views instead of
> > being compelled to select the data someone thought was good for you.
>
> You can still do that if it's an SRF. You could even make the SRF take
> an optional argument to either return a single value (filtered the
> same way the individual functions are) or when this one is set to
> NULL, return the whole table.
>
> It would make the overhead a lot lower in the most common case
> ("SELECT
> * FROM pg_stat_"), while only adding a little in the
> other cases, I think.
>
> Though I'm not sure that overhead is big enough to care about in the
> first place, but if you're VIEWs are longish it could be...
Actually, looking at this once more, the interface to the functions
sucked more than I thought. They're not actually accepting procpid as
parameters, but just an index into the current array in pgstats..
Basically, they're not supposed to be used in any other way than
accessing all the rows at once :-)
Attached is a version of the functions required for pg_stat_activity
implemented as a SRF instead of different functions. A quick benchmark
(grabbing the VIEW 10,000 times on a system with about 500 active
backends) shows it's about 20% faster than the function-per-value
approach, but the runtime per view is still very quick as it is today.
(And most of what overhead there is most likely comes from reading the
stats file)
However, it also implements the lookup-by-PID functionality that IMHO
makes a lot more sense than lookup-by-backend-array-index. This is
obviously a lot more performant than querying the VIEW for all rows -
something that might be a big win for monitoring apps that look for
info about a single backend.
Unsure if we want to go ahead and convert all functions, but I think we
can make a good argument for making *new* stats views (like the ones
about functions that in the queue) based on SRFs instead. It also has
the nice side-effect of less rows in the system tables ;)
Comments?
//Magnus
Index: src/backend/utils/adt/pgstatfuncs.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/adt/pgstatfuncs.c,v
retrieving revision 1.49
diff -c -r1.49 pgstatfuncs.c
*** src/backend/utils/adt/pgstatfuncs.c 25 Mar 2008 22:42:44 - 1.49
--- src/backend/utils/adt/pgstatfuncs.c 28 Apr 2008 13:36:57 -
***
*** 17,22
--- 17,24
#include "funcapi.h"
#include "miscadmin.h"
#include "pgstat.h"
+ #include "catalog/pg_type.h"
+ #include "access/heapam.h"
#include "utils/builtins.h"
#include "utils/inet.h"
#include "libpq/ip.h"
***
*** 39,44
--- 41,47
extern Datum pg_stat_get_last_autoanalyze_time(PG_FUNCTION_ARGS);
extern Datum pg_stat_get_backend_idset(PG_FUNCTION_ARGS);
+ extern Datum pg_stat_get_activity(PG_FUNCTION_ARGS);
extern Datum pg_backend_pid(PG_FUNCTION_ARGS);
extern Datum pg_stat_get_backend_pid(PG_FUNCTION_ARGS);
extern Datum pg_stat_get_backend_dbid(PG_FUNCTION_ARGS);
***
*** 363,368
--- 366,590
}
}
+ Datum
+ pg_stat_get_activity(PG_FUNCTION_ARGS)
+ {
+ FuncCallContext *funcctx;
+
+ if (SRF_IS_FIRSTCALL())
+ {
+ MemoryContext oldcontext;
+ TupleDesc tupdesc;
+
+ funcctx = SRF_FIRSTCALL_INIT();
+
+ oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
+
+ tupdesc = CreateTemplateTupleDesc(10, false);
+ TupleDescInitEntry(tupdesc, (AttrNumber) 1, "datid", OIDOID, -1, 0);
+ TupleDescInitEntry(tupdesc, (AttrNumber) 2, "procpid", INT4OID, -1, 0);
+ TupleDescInitEntry(tupdesc, (AttrNumber) 3, "usesysid", OIDOID, -1, 0);
+ TupleDescInitEntry(tupdesc, (AttrNumber) 4, "current_query", TEXTOID, -1, 0);
+ TupleDescInitEntry(tupdesc, (AttrNumber) 5, "waiting", BOOLOID, -1, 0);
+ TupleDescInitEntry(tupdesc, (AttrNumber) 6, "act_start", TIMESTAMPTZOID, -1, 0);
+ TupleDescInitEntry(tupdesc, (AttrNumber) 7, "query_start", TIMESTAMPTZOID, -1, 0);
+ TupleDescInitEntry(tupdesc, (AttrNumber) 8, "backend_start", TIMESTAMPTZOID, -1, 0);
+ TupleDescInitEntry(tupdesc, (AttrNumber) 9, "client_addr", INETOID, -1, 0);
+ TupleDescInitEntry(tupdesc, (AttrNumber) 10, "client_port", INT4OID, -1, 0);
+
+ funcctx->tuple_desc = BlessTupleDesc(tupdesc);
+
+ funcctx->user_fctx = palloc0(sizeof(int));
+ if (PG_ARGISNULL(0))
+ {
+ /* Get all backends */
+ funcctx->max_calls = pgstat_fetch_stat_numbackends();
+ }
+ else
+ {
+
Re: [HACKERS] SRF in SFRM_ValuePerCall mode
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes: > dv @ nabble wrote: >> I am working on implementation of custom "C" SRF for our team. The SRF uses >> SFRM_ValuePerCall mode. I know that sometimes even in SFRM_ValuePerCall >> mode >> all the rows returned from SRF are "materialized" (for performing JOINs, >> for >> example). > Yep, they are unfortunately always materialized. Back when set returning > functions were implemented, the original patch did actually support true > "value per call" mode, where the whole result set was not materialized. > However, it was dropped because of some issues I can't remember off the > top of my head. The value-per-call API was committed, so that it was > already in place when someone gets around to implement the backend > support for it. That's a rather revisionist view of history ;-) Value-per-call mode has always been there, just not in nodeFunctionscan.c. If you're not joining to the function result, and you don't need the ability to determine its result type on the fly, you could declare it as returning a specific rowtype and then call it in the targetlist: select vpc(); 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] we don't have a bugzilla
On Sun, Apr 27, 2008 at 11:58:01AM -0400, Alvaro Herrera wrote: > So the proper thing to do is complain to the writer of the GUI app so > that it has an option for showing the list headers, perhaps adding a > menu entry when they are found. At least in the case of Thunderbird, you already have an option: http://www.juergen-ernst.de/addons/mailinglistheader.html According to the manual, claws has a whole Message/Mailing-List submenu with built-in support for this. (This took me approximately 10 seconds to find through Google. The claws manual looks pretty good, I have to say.) I was unable to find the way to to this in Lookout! I don't use the Mac OS Mail client, but a quick look didn't yield anything obvious. However, these both allow you to look at the raw mail message, which has the header. Given that List-Archive was standardized in RFC2369, which came out in 1998, and that virtually every list server software shipping since about 2000 has it built in and turned on by default, I fail completely to see how using something as free-form as a signature footer is supposed to be an improvement. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.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] Recent buildfarm failures involving statement_timeout
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: >> sysname | snapshot |branch >> -+-+--- >> lionfish | 2007-04-19 09:30:27 | REL8_2_STABLE >> lionfish | 2007-05-29 23:30:07 | REL8_1_STABLE >> lionfish | 2007-09-22 23:30:07 | REL8_1_STABLE > lionfish is(or rather was - powersupply got fried and I have no > replacement yet) one of the slowest machines(250MHZ mipsel,48MB RAM) on > the buildfarm (took about 5-6h for a complete run). Unless someone has a better idea, I suggest we just raise the timeouts used in prepared_xacts from 1 sec to 2 sec. That should reduce the recurrence rate to something vanishingly small if the problem is just "it's too slow". If it's that something's actually getting stuck, then we'll continue to see failures and will know that closer investigation is needed. 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
[HACKERS] Re: [PATCHES] Removing typename from A_Const (was: Empty arrays with ARRAY[])
Brendan Jurd escribió: > Here's my attempt to remove the typename field from A_Const. There > were a few places (notably flatten_set_variable_args() in guc.c, and > typenameTypeMod() in parse_type.c) where the code expected to see an > A_Const with a typename, and I had to adjust for an A_Const within a > TypeCast. Nonetheless, there was an overall net reduction of 34 lines > of code, so I think this was a win. Do say ... why don't we do away with A_Const altogether and just replace it with Value? After this patch, I don't see what's the difference. -- 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] we don't have a bugzilla
[EMAIL PROTECTED] (Andrew Dunstan) writes: > Raphaël Jacquot wrote: >> would seem like a good idea, no ? >> >> http://www.murrayc.com/blog/permalink/2008/04/25/postgresql-has-no-bugzilla/ > > Before you come trolling on this (or any other) subject, please read > the voluminous debates that have taken place about it. Apparently you > think it's something we have never considered, which in light of the > product we maintain would be more than remarkable. > > Having done that, please endeavour to make an actual contribution to > the discussion. This seems more than a tad unfair. Yes, it is certainly fair to observe that there have been voluminous debates. But it will take a whole lot of "trolling around" in the archives to figure out the shape of the *conclusions* of those debates. Seeming relevant conclusions: - Yes, there probably ought to be some sort of structured bug tracker. - HOWEVER, there are many who prefer to use email for their work, as opposed to being forced into some sort of "webby thing." - That being said, experimentation is taking place for the "commitfests" with using a wiki to track statuses of patches and discussions. - It is hoped that out of this experimentation, patterns surrounding what is *truly* needful to structure will emerge. There is reason to be hopeful about this, as the wiki-based process has been showing some useful structures to impose already. -- select 'cbbrowne' || '@' || 'cbbrowne.com'; http://www3.sympatico.ca/cbbrowne/spreadsheets.html "I find it hard to believe a professional programmer could support the concept of Open Source." -- David J. Owens <[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] [PATCHES] Removing typename from A_Const (was: Empty arrays with ARRAY[])
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Brendan Jurd escribió: >> Here's my attempt to remove the typename field from A_Const. There >> were a few places (notably flatten_set_variable_args() in guc.c, and >> typenameTypeMod() in parse_type.c) where the code expected to see an >> A_Const with a typename, and I had to adjust for an A_Const within a >> TypeCast. Nonetheless, there was an overall net reduction of 34 lines >> of code, so I think this was a win. > Do say ... why don't we do away with A_Const altogether and just replace > it with Value? After this patch, I don't see what's the difference. They're logically different things, and after I get done putting a parse location field into A_Const, they'll still be physically different too. 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] [PATCHES] Removing typename from A_Const (was: Empty arrays with ARRAY[])
Tom Lane escribió: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Brendan Jurd escribi�: > >> Here's my attempt to remove the typename field from A_Const. There > >> were a few places (notably flatten_set_variable_args() in guc.c, and > >> typenameTypeMod() in parse_type.c) where the code expected to see an > >> A_Const with a typename, and I had to adjust for an A_Const within a > >> TypeCast. Nonetheless, there was an overall net reduction of 34 lines > >> of code, so I think this was a win. > > > Do say ... why don't we do away with A_Const altogether and just replace > > it with Value? After this patch, I don't see what's the difference. > > They're logically different things, and after I get done putting a parse > location field into A_Const, they'll still be physically different too. Aha. Are you working from Brendan's patch? I was going to commit it. -- 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] [PATCHES] Removing typename from A_Const (was: Empty arrays with ARRAY[])
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Tom Lane escribió: >> They're logically different things, and after I get done putting a parse >> location field into A_Const, they'll still be physically different too. > Aha. Are you working from Brendan's patch? I was going to commit it. Sure, go ahead. I was going to add the parse location at the same time, but it can perfectly well be done as a separate patch. 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] we don't have a bugzilla
Chris Browne wrote: [EMAIL PROTECTED] (Andrew Dunstan) writes: Raphaël Jacquot wrote: would seem like a good idea, no ? http://www.murrayc.com/blog/permalink/2008/04/25/postgresql-has-no-bugzilla/ Before you come trolling on this (or any other) subject, please read the voluminous debates that have taken place about it. Apparently you think it's something we have never considered, which in light of the product we maintain would be more than remarkable. Having done that, please endeavour to make an actual contribution to the discussion. This seems more than a tad unfair. I'm sorry, open season to beat me up on this closed 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] we don't have a bugzilla
On Mon, Apr 28, 2008 at 11:55:18AM -0400, Chris Browne wrote: > Yes, it is certainly fair to observe that there have been voluminous > debates. But it will take a whole lot of "trolling around" in the > archives to figure out the shape of the *conclusions* of those > debates. As one of those confused, it would be really nice if someone could summarise it all on a wiki page that we can point people to. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
[HACKERS] Protection from SQL injection
Hi, As you know, "SQL injection" is the main security problem of databases today. I think I found a solution: 'disabling literals'. Or you may call it 'enforcing the use of parameterized statements'. This means that SQL statements with embedded user input are rejected at runtime. My solution goes beyond saying "developers ~should~ use parameterized statements". That is not a solution because developers are lazy. My solution is: "developers MUST use parameterized statements". It goes like this: Literals are disabled using the SQL statement: SET ALLOW_LITERALS NONE; Afterwards, SQL statements with text are not allowed any more for this session. That means, SQL statement of the form "SELECT * FROM USERS WHERE PASSWORD='qerkllkj'" will fail with the exception 'Literals are not allowed, please use parameters'. It is like the database does not know what ='qerkllkj' means. Only statements of the secure form are allowed, for example "SELECT * FROM USERS WHERE PASSWORD=?". This solves the problem because SQL injection is almost impossible if user input is not directly embedded in SQL statements. The 'ALLOW_LITERALS NONE' mode is enabled by the developer itself, or by an administrator. It is still possible to generate SQL statements dynamically, and use the same APIs as before, as long as SQL statements don't include literals. Literals can still be used when using query tools, or in applications considered 'safe'. To ease converting the application to use parameterized queries, there should be a second mode where number literals are allowed: SET ALLOW_LITERALS NUMBERS. To allow all literals, execute SET ALLOW_LITERALS ALL (this is the default setting). So far this feature is implemented in my little database H2. More information about this feature is described here: http://www.h2database.com/html/advanced.html#sql_injection I know about the Perl taint mode, but this is only for Perl. I also know about disabling multi-statement commands (only solves part of the problem). PostgreSQL should also support database level 'constants' that are similar to constants in other programming languages, otherwise application level constants (such as 'active') can't be used in queries directly (I propose to add new SQL statements CREATE CONSTANT ... VALUE ... and DROP CONSTANT ..., example: CREATE CONSTANT STATE_ACTIVE VALUE 'active'). I also know the 'disabling literals' feature does not solve SQL injection completely: for example 'ORDER BY injection' where an application dynamically adds the column to sort on based on a hidden 'sort column' field in a web app. To solve that I suggest to support parameterized ORDER BY: ORDER BY ? where ? is an integer. Then, instead of using SET ALLOW_LITERALS NONE the use of literals should probably be two access right (REVOKE LITERAL_TEXT, LITERAL_NUMBER FROM APP_ROLE). Those are details that still need to be discussed. What do you think about it? Do you think it makes sense to implement this security feature in PostgreSQL as well? If not why not? Does PostgreSQL have another solution or plan to solve the SQL injection problem? Regards, Thomas P.S. I have send this proposal to [EMAIL PROTECTED] first and got replies, but I would like to get some feedback from the PostgreSQL developers as well. -- 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] Protection from SQL injection
Thomas, What do you think about it? Do you think it makes sense to implement this security feature in PostgreSQL as well? If not why not? Does PostgreSQL have another solution or plan to solve the SQL injection problem? Have you seen Meredith's libdejector? http://sourceforge.net/projects/libdejector --Josh Berkus -- 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] Protection from SQL injection
* Thomas Mueller ([EMAIL PROTECTED]) wrote: > As you know, "SQL injection" is the main security problem of databases today. I think there's a fallacy there- it's the main security problem of applications (particularly those on the web) today. It hasn't got much at all to do with the database's security. Also, hasn't this been discussed to death already? Stephen signature.asc Description: Digital signature
[HACKERS] WANTED: VACUUM SUMMARY
Hello, I would like to write a patch that provides the command: VACUUM SUMMARY This was discussed briefly here: http://archives.postgresql.org/pgsql-performance/2007-10/msg00165.php I know there are other plans for 8.4 but I was wondering if those plans appear to be happening or not? I don't want to waste people's time on the patch but if we aren't going to change the FSM stuff for 8.4, I as a DBA would find VACUUM SUMMARY useful. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit signature.asc Description: PGP signature
Re: [HACKERS] WANTED: VACUUM SUMMARY
Joshua D. Drake wrote: > I know there are other plans for 8.4 but I was wondering if those plans > appear to be happening or not? I don't want to waste people's time on > the patch but if we aren't going to change the FSM stuff for 8.4, I as > a DBA would find VACUUM SUMMARY useful. I think it would be more useful to move pg_freespacemap from contrib to core. -- 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] [PATCHES] Removing typename from A_Const (was: Empty arrays with ARRAY[])
Alvaro Herrera escribió: > Tom Lane escribió: > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > Tom Lane escribió: > > >> They're logically different things, and after I get done putting a parse > > >> location field into A_Const, they'll still be physically different too. > > > > > Aha. Are you working from Brendan's patch? I was going to commit it. > > > > Sure, go ahead. I was going to add the parse location at the same time, > > but it can perfectly well be done as a separate patch. > > I came up with the attached patch. I added the location bits (although > I am unsure if I got the locations right in the parser), but they are > unused -- figuring out how to use them would take me longer than I can > to spend on this. Hmm, I'm now wondering if the location should be added to Value as well, so that it can be passed down to Const? -- 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] Protection from SQL injection
As you know, "SQL injection" is the main security problem of databases
today.
I think I found a solution: 'disabling literals'. Or you may call it
'enforcing the use of parameterized statements'. This means that SQL
statements with embedded user input are rejected at runtime. My
solution goes beyond saying "developers ~should~ use parameterized
statements". That is not a solution because developers are lazy. My
solution is: "developers MUST use parameterized statements". It goes
like this: Literals are disabled using the SQL statement:
I have found that the little bit of code posted afterwards did eliminate
SQL holes in my PHP applications with zero developer pain, actually it is
MORE convenient to use than randomly pasting strings into queries.
You just call
db_query( "SELECT * FROM table WHERE column1=%s AND column2=%s",
array( $var1, $var2 ));
It is inspired from the Python interface which performs the same (but
slightly more elegantly).
I have removed the logging features for clarity.
function db_quote_query( $sql, $params=false )
{
// if no params, send query raw
if( $params === false ) return $sql;
if( !is_array( $params )) $params = array( $params );
// quote params
foreach( $params as $key => $val )
{
if( is_array( $val )) $params[$key] = implode( ', ', array_map( intval,
$val ));
else $params[$key] =
is_null($val)?'NULL':("'".pg_escape_string($val)."'");;
}
return vsprintf( $sql, $params );
}
function db_query( $sql, $params=false )
{
// it's already a query
if( is_resource( $sql ))
return $sql;
$sql = db_quote_query( $sql, $params );
$r = pg_query( $sql );
if( !$r )
{
echo "Erreur PostgreSQL :/>".htmlspecialchars(pg_last_error())."Requête :/>".$sql."Traceback :";
foreach( debug_backtrace() as $t ) xdump( $t );
echo "";
die();
}
return $r;
}
SET ALLOW_LITERALS NONE;
Afterwards, SQL statements with text are not allowed any more for this
session. That means, SQL statement of the form "SELECT * FROM USERS
WHERE PASSWORD='qerkllkj'" will fail with the exception 'Literals are
not allowed, please use parameters'. It is like the database does not
know what ='qerkllkj' means. Only statements of the secure form are
allowed, for example "SELECT * FROM USERS WHERE PASSWORD=?". This
solves the problem because SQL injection is almost impossible if user
input is not directly embedded in SQL statements.
The 'ALLOW_LITERALS NONE' mode is enabled by the developer itself, or
by an administrator. It is still possible to generate SQL statements
dynamically, and use the same APIs as before, as long as SQL
statements don't include literals. Literals can still be used when
using query tools, or in applications considered 'safe'. To ease
converting the application to use parameterized queries, there should
be a second mode where number literals are allowed: SET ALLOW_LITERALS
NUMBERS. To allow all literals, execute SET ALLOW_LITERALS ALL (this
is the default setting).
So far this feature is implemented in my little database H2. More
information about this feature is described here:
http://www.h2database.com/html/advanced.html#sql_injection
I know about the Perl taint mode, but this is only for Perl. I also
know about disabling multi-statement commands (only solves part of the
problem). PostgreSQL should also support database level 'constants'
that are similar to constants in other programming languages,
otherwise application level constants (such as 'active') can't be used
in queries directly (I propose to add new SQL statements CREATE
CONSTANT ... VALUE ... and DROP CONSTANT ..., example: CREATE CONSTANT
STATE_ACTIVE VALUE 'active'). I also know the 'disabling literals'
feature does not solve SQL injection completely: for example 'ORDER BY
injection' where an application dynamically adds the column to sort on
based on a hidden 'sort column' field in a web app. To solve that I
suggest to support parameterized ORDER BY: ORDER BY ? where ? is an
integer. Then, instead of using SET ALLOW_LITERALS NONE the use of
literals should probably be two access right (REVOKE LITERAL_TEXT,
LITERAL_NUMBER FROM APP_ROLE). Those are details that still need to be
discussed.
What do you think about it? Do you think it makes sense to implement
this security feature in PostgreSQL as well? If not why not? Does
PostgreSQL have another solution or plan to solve the SQL injection
problem?
Regards,
Thomas
P.S. I have send this proposal to [EMAIL PROTECTED] first and
got replies, but I would like to get some feedback from the PostgreSQL
developers as well.
--
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] [PATCHES] Removing typename from A_Const (was: Empty arrays with ARRAY[])
Alvaro Herrera <[EMAIL PROTECTED]> writes: > I came up with the attached patch. I wasn't envisioning anything anywhere near this invasive. We only need locations on constants in a few contexts, I think. BTW, you broke _equalAConst() ... it was a bad idea anyway to recast it on the assumption that there would never again be more than one field. 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] [PATCHES] Removing typename from A_Const (was: Empty arrays with ARRAY[])
Tom Lane escribió: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > I came up with the attached patch. > > I wasn't envisioning anything anywhere near this invasive. We only > need locations on constants in a few contexts, I think. Aha. OK, I'll commit the original patch and let you deal with the rest of it :-) > BTW, you broke _equalAConst() ... it was a bad idea anyway to recast > it on the assumption that there would never again be more than one > field. Oops, sorry, I had intended to revert that part and forgot. -- 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] [PATCHES] Removing typename from A_Const (was: Empty arrays with ARRAY[])
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Hmm, I'm now wondering if the location should be added to Value as well, > so that it can be passed down to Const? Just for the record, we don't want it in Const. Parse locations are only useful in the "raw grammar" output, mainly because they aren't helpful unless you still have the original query string laying about. 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] WANTED: VACUUM SUMMARY
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Joshua D. Drake wrote: >> I know there are other plans for 8.4 but I was wondering if those plans >> appear to be happening or not? I don't want to waste people's time on >> the patch but if we aren't going to change the FSM stuff for 8.4, I as >> a DBA would find VACUUM SUMMARY useful. > I think it would be more useful to move pg_freespacemap from contrib to > core. The free space map won't even exist in its current form when 8.4 is released. (If Heikki doesn't do it then I will...) So I see little value in expending further effort on the present design. 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] Protection from SQL injection
On Tue, Apr 29, 2008 at 7:00 AM, PFC <[EMAIL PROTECTED]> wrote:
> I have found that the little bit of code posted afterwards did eliminate
> SQL holes in my PHP applications with zero developer pain, actually it is
> MORE convenient to use than randomly pasting strings into queries.
>
> You just call
> db_query( "SELECT * FROM table WHERE column1=%s AND column2=%s", array(
> $var1, $var2 ));
>
Implementing this for yourself is crazy; PHP's Postgres extension
already does this for you since 5.1.0:
$result = pg_query_params("SELECT foo FROM bar WHERE baz = $1", array($baz));
http://www.php.net/manual/en/function.pg-query-params.php
Cheers,
BJ
--
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] Protection from SQL injection
On Mon, Apr 28, 2008 at 08:55:34PM +0200, Thomas Mueller wrote: > As you know, "SQL injection" is the main security problem of databases today. > > I think I found a solution: 'disabling literals'. I personally think this is wrong, I often have schemas that mean I have to do things like: SELECT a.x, a.y, b.z FROM a, b WHERE a.a = b.a AND a.f = 'lit' AND b.g = 'lit' AND b.h = $1; So a big query, with lots of literals and only very few of them actually come from an untrusted source. Also remember that any literal (i.e. not just strings) can be quoted, think of dates in queries. One option I like would be if the programming language (that you're calling the database from) recorded "tainting" of variables, preferably if this is done statically in the type system but languages like PHP seem to prefer to do this sort of thing at run time. Microsoft's approach of integrating SQL into the language would work as well, the programmer can't get the quoting wrong then. But I prefer the approach taken by HaskellDB as it doesn't require new syntax/semantics to be designed/integrated. HaskellDB is a bit heavy though. Sam -- 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] Proposed patch - psql wraps at window width
Gregory Stark wrote: > "Bryce Nesbitt" <[EMAIL PROTECTED]> writes: > > > Unless they are in the habit of doing: > > > > # COLUMNS=$COLUMNS ls -C |cat > > Some of us are actually in the habit of doing that because it's easier to use > the standard interface than remembering the different command-line option for > each command. I quite often do precisely that with dpkg, for example. Yes, this is true, but it assume the application is not going to set $COLUMNS itself, like psql does in interactive mode: test=> \echo `echo $COLUMNS` 127 $ sql -c '\echo `echo $COLUMNS`' test (empty) Now, we could get fancy and honor $COLUMNS only in non-interactive mode, but that seems confusing. -- 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] Re: [COMMITTERS] pgsql: Add generate_subscripts, a series-generation function which
Tom Lane wrote: > [EMAIL PROTECTED] (Alvaro Herrera) writes: > > Add generate_subscripts, a series-generation function which generates an > > array's subscripts. > > Why are these marked volatile in pg_proc? Surely they generate the > same outputs given the same inputs, and therefore qualify as immutable. Hmm, true. I'll change the four generate_series variants too -- they are marked volatile as well. -- 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] [COMMITTERS] pgsql: Add generate_subscripts, a series-generation function which
Alvaro Herrera <[EMAIL PROTECTED]> writes: > I'll change the four generate_series variants too -- they are marked > volatile as well. I don't think the system actually pays much attention to the volatility marking of set-returning functions at the moment, so it wouldn't be too surprising if they were all wrong :-(. Still, we may as well get the catalog entries right for possible future use. 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] Proposed patch - psql wraps at window width
"Bruce Momjian" <[EMAIL PROTECTED]> writes: > Gregory Stark wrote: >> "Bryce Nesbitt" <[EMAIL PROTECTED]> writes: >> >> > Unless they are in the habit of doing: >> > >> > # COLUMNS=$COLUMNS ls -C |cat >> >> Some of us are actually in the habit of doing that because it's easier to use >> the standard interface than remembering the different command-line option for >> each command. I quite often do precisely that with dpkg, for example. > > Yes, this is true, but it assume the application is not going to set > $COLUMNS itself, like psql does in interactive mode: > > test=> \echo `echo $COLUMNS` > 127 > > $ sql -c '\echo `echo $COLUMNS`' test > (empty) > > Now, we could get fancy and honor $COLUMNS only in non-interactive mode, > but that seems confusing. We could always read COLUMNS early on before readline is initialized and stash the value away in a variable. But... We would only look at COLUMNS if the ioctl for window size failed. Does psql/readline do anything to COLUMNS in that case? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- 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] Proposed patch - psql wraps at window width
Gregory Stark wrote: > > Now, we could get fancy and honor $COLUMNS only in non-interactive mode, > > but that seems confusing. > > We could always read COLUMNS early on before readline is initialized and stash > the value away in a variable. But... > > We would only look at COLUMNS if the ioctl for window size failed. Does > psql/readline do anything to COLUMNS in that case? We do look at COLUMNS if the ioctl() fails, but not for file/pipe output. -- 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] Proposed patch - psql wraps at window width
"Bruce Momjian" <[EMAIL PROTECTED]> writes: > Gregory Stark wrote: >> > Now, we could get fancy and honor $COLUMNS only in non-interactive mode, >> > but that seems confusing. >> >> We could always read COLUMNS early on before readline is initialized and >> stash >> the value away in a variable. But... >> >> We would only look at COLUMNS if the ioctl for window size failed. Does >> psql/readline do anything to COLUMNS in that case? > > We do look at COLUMNS if the ioctl() fails, but not for file/pipe > output. Yeah, it looks like your most recent patch still has the bug that if the user specifies wrapped there are some complicated rules creating cases where it will ignore the user's request and use un-wrapped output instead. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- 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: Increase the statement_timeout value used in the prepared_xacts
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Increase the statement_timeout value used in the prepared_xacts > regression test. We have seen some buildfarm failures that seem > to be due to this limit being unexpectedly exceeded when the machine > is under load. Just as a data point, I thought I saw fennec in the list of machines exhibiting this problem, and I can safely vouch that it extremely unlikely the machine was under load at the time. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200804282359 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkgWnRMACgkQvJuQZxSWSsgG9QCgqVUvOnE5diN64OSRa6TmDvyz wSkAn2y9sP+lnc9NllP3SY1gRRm68BK8 =HQwP -END PGP SIGNATURE- -- 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: Increase the statement_timeout value used in the prepared_xacts
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes: >> Increase the statement_timeout value used in the prepared_xacts >> regression test. We have seen some buildfarm failures that seem >> to be due to this limit being unexpectedly exceeded when the machine >> is under load. > Just as a data point, I thought I saw fennec in the list of machines > exhibiting this problem, and I can safely vouch that it extremely unlikely > the machine was under load at the time. Yeah, I'm not totally sold that this is a "fix" either --- although there's at least one prior case of an intermittent buildfarm failure that went away when we increased the timeout sufficiently. I think a 2-line change is an appropriate amount of effort for now. If we keep seeing the failure then we'll know we need to look closer. 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
