Re: [HACKERS] [Mingw-users] mingw64
Hi Peter, * Peter Rosin wrote on Mon, Feb 14, 2011 at 09:14:03AM CET: > Den 2011-02-12 11:10 skrev Ralf Wildenhues: > > * Peter Rosin wrote on Sat, Jan 29, 2011 at 02:26:24PM CET: > >> Or is plain 'ar' used somewhere instead of 'x86_64-w64-mingw32-ar'? > > > > Automake outputs 'AR = ar' in Makefile.in for rules creating old > > libraries iff neither AC_PROG_LIBTOOL nor another method to define > > AR correctly is used in configure.ac. > > A good workaround, as already mentioned, is to use this in configure.ac: > > AC_CHECK_TOOL([AR], [ar], [false]) > > I just cannot understand why the workaround isn't always working in > this case. > > There was a log posted with this in it > (in http://archives.postgresql.org/pgsql-hackers/2011-01/msg02697.php): [...] > configure:6164: checking for x86_64-w64-mingw32-ar > configure:6180: found /mingw/bin/x86_64-w64-mingw32-ar > configure:6191: result: x86_64-w64-mingw32-ar [...] > Which seem to match this snippet from configure.in: > > ... > AC_PROG_RANLIB > PGAC_CHECK_STRIP > AC_CHECK_TOOL(AR, ar, ar) > if test "$PORTNAME" = "win32"; then > AC_CHECK_TOOL(DLLTOOL, dlltool, dlltool) > AC_CHECK_TOOL(DLLWRAP, dllwrap, dllwrap) > AC_CHECK_TOOL(WINDRES, windres, windres) > fi > ... > > Sure, AC_CHECK_TOOL has under-quoted arguments and the last argument is > 'ar' instead of 'false'. But that shouldn't really matter here. (Or > does it?) No, that's irrelevant. > Still, elsewhere in the thread there's a report about the wrong ar being > used. > (in http://archives.postgresql.org/pgsql-hackers/2011-01/msg02713.php) Well, the poster wrote that it worked now though: http://archives.postgresql.org/pgsql-hackers/2011-01/msg02806.php > Sure, the configure log and the "wrong ar"-report are not from the same > person, but the configure script should be the same for everybody (git > log hints that this part of configure has been stable for a couple of > years). > > It just doesn't add up. FWIW, I don't see enough evidence of breakage to be able to analyze it. Thanks, Ralf -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
I'm not trying to fix the signature. I want exactly that signature. I want to return 1 UDT as an OUT parameter from a function. Somewhere between JDBC and the database, this signature is lost, and JDBC's internal code tells me that I have to bind 6 OUT parameters, instead of 1. It happens to be so, because the UDT contains 6 attributes, so somehow the JDBC/database protocol flattens the UDT, and I think that's a bug, either in JDBC or in the protocol or in the database. My findings were that I can correctly read the UDT OUT parameter using the pgAdmin III tool, so I excluded the database as a bug holder candidate. Cheers Lukas 2011/2/15 Robert Haas > On Sat, Feb 12, 2011 at 6:16 AM, Lukas Eder wrote: > > I had tried that before. That doesn't seem to change anything. JDBC still > > expects 6 OUT parameters, instead of just 1... > > Oh, hrm. I thought you were trying to fix the return value, rather > than the signature. > > I am not sure how to fix the signature. Can you just make it return > RECORD? > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: [HACKERS] why two dashes in extension load files
2011/2/16 Alex Hunsaker : > On Tue, Feb 15, 2011 at 14:12, Robert Haas wrote: >> On Tue, Feb 15, 2011 at 3:26 PM, marcin mank wrote: >>> how about : we use a single dash as the separator, and if the >>> extension author insists on having a dash in the name, as a punishment >>> he must duplicate the dash, i.e.: >>> uuid--ossp-1.0--5.5.sql >> >> That has a certain poetic justice to it. > > Im not sure I see the poetic justice in trying to punish others for > *our* arbitrary naming rules. *shrug* > We are going to push arbitrary rules anyway. I now believe (after chating wiht Dim) that the current rules are the less intrusive and the simplest at the time. Obviously it is new rules, but after all the -- help a good visibility for the human eye too. my-2coolextension--1.2alpha--go2beta.sql -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et 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: FDW API
On 15.02.2011 23:00, Tom Lane wrote:
Heikki Linnakangas writes:
On 15.02.2011 21:13, Tom Lane wrote:
Hmm. I don't have a problem with adding relkind to the planner's
RelOptInfo, but it seems to me that if parse analysis needs to know
this, you have put functionality into parse analysis that does not
belong there.
Possibly. We throw the existing errors, for example if you try to do
"FOR UPDATE OF foo" where foo is a set-returning function, in
transformLockingClause(), so it seemed like the logical place to check
for foreign tables too.
Hmm, one approach would be to go ahead and create the RowMarkClauses for
all relations in the parse analysis phase, foreign or not, and throw the
error later, in preprocess_rowmarks().
I think moving the error check downstream would be a good thing.
Ok, I tried moving the error checks to preprocess_rowmarks().
Unfortunately RelOptInfos haven't been built at that stage yet, so you
still have to do the catalog lookup to get the relkind. That defeats the
purpose.
We could delay the error checking further, but preprocess_rowmarks()
would need to distinguish foreign tables anyway, so that it can mark
them with ROW_MARK_COPY instead of ROW_MARK_REFERENCE.
IIRC, at the moment we're basically duplicating the tests between parse
analysis and the planner, but it's not clear what the value of that is.
There's duplicate logic in parse analysis and rewriter, to be precise.
And then there's this one check in make_outerjoininfo:
>/*
> * Presently the executor cannot support FOR UPDATE/SHARE marking of
rels
> * appearing on the nullable side of an outer join. (It's somewhat
unclear
> * what that would mean, anyway: what should we mark when a result
row is
> * generated from no element of the nullable relation?) So, complain if
> * any nullable rel is FOR UPDATE/SHARE.
> *
> * You might be wondering why this test isn't made far upstream in the
> * parser. It's because the parser hasn't got enough info --- consider
> * FOR UPDATE applied to a view. Only after rewriting and flattening do
> * we know whether the view contains an outer join.
> *
> * We use the original RowMarkClause list here; the PlanRowMark list
would
> * list everything.
> */
>foreach(l, root->parse->rowMarks)
>{
>RowMarkClause *rc = (RowMarkClause *) lfirst(l);
>
>if (bms_is_member(rc->rti, right_rels) ||
>(jointype == JOIN_FULL && bms_is_member(rc->rti,
left_rels)))
>ereport(ERROR,
>(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> errmsg("SELECT FOR UPDATE/SHARE cannot be applied to the
nullable side of an outer join")));
>}
--
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] Fwd: [JDBC] Weird issues when reading UDT from stored function
On Wed, Feb 16, 2011 at 3:30 AM, Lukas Eder wrote: > I'm not trying to fix the signature. I want exactly that signature. I want > to return 1 UDT as an OUT parameter from a function. > > Somewhere between JDBC and the database, this signature is lost, and JDBC's > internal code tells me that I have to bind 6 OUT parameters, instead of 1. > It happens to be so, because the UDT contains 6 attributes, so somehow the > JDBC/database protocol flattens the UDT, and I think that's a bug, either in > JDBC or in the protocol or in the database. My findings were that I can > correctly read the UDT OUT parameter using the pgAdmin III tool, so I > excluded the database as a bug holder candidate. Oh, OK. Sorry, I can't help you any with the JDBC side... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
On 17/02/11 00:58, Robert Haas wrote: > On Wed, Feb 16, 2011 at 3:30 AM, Lukas Eder wrote: >> I'm not trying to fix the signature. I want exactly that signature. I want >> to return 1 UDT as an OUT parameter from a function. >> >> Somewhere between JDBC and the database, this signature is lost, and JDBC's >> internal code tells me that I have to bind 6 OUT parameters, instead of 1. >> It happens to be so, because the UDT contains 6 attributes, so somehow the >> JDBC/database protocol flattens the UDT, and I think that's a bug, either in >> JDBC or in the protocol or in the database. My findings were that I can >> correctly read the UDT OUT parameter using the pgAdmin III tool, so I >> excluded the database as a bug holder candidate. > > Oh, OK. Sorry, I can't help you any with the JDBC side... Well, the underlying problem is that "SELECT * from function_with_one_out_parameter()" is returning *6* columns, not 1 column. I don't know if that's expected or not on the plpgsql side, but the JDBC driver has no way of distinguishing that sort of result from a function that has 6 OUT parameters. Oliver -- 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] DROP SCHEMA xxx CASCADE: ERROR: could not open relation with OID yyy
On Thu, Feb 10, 2011 at 12:03:49AM -0500, Tom Lane wrote: > strk writes: > > I've finally completed the debugging phase and have > > a minimal self-contained testcase showing the problem. > > It has to do with INITIALLY DEFERRED constraints. > > I looked into this and find that the issue is you're trying to drop a > table that has unfired AFTER TRIGGER events pending. When they finally > fire, they can't find the table anymore. > > I'm inclined to think that we should disallow that; or even more to the > point, that it'd be a good thing to apply CheckTableNotInUse() when > about to drop a table. If we disallow such cases for ALTER TABLE, then > a fortiori we should do so for DROP TABLE. Makes sense to me disallowing drop. An intuitive error message is all I was looking for. --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html -- 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] Change pg_last_xlog_receive_location not to move backwards
On Wed, Feb 16, 2011 at 12:59 AM, Fujii Masao wrote: > On Tue, Feb 15, 2011 at 9:41 PM, Robert Haas wrote: >> On Tue, Feb 15, 2011 at 12:34 AM, Fujii Masao wrote: >>> You suggest that the shared variable Stream tracks the WAL write location, >>> after it's set to the replication starting position? I don't think >>> that the write >>> location needs to be tracked in the shmem because other processes than >>> walreceiver don't use it. >> >> Well, my proposal was to expose it, on the theory that it's useful. >> As we stream the WAL, we write it, so I think for all intents and >> purposes write == stream. But using it to convey the starting >> position makes more sense if you call it stream than it does if you >> call it write. > > Umm.. I could not find any use case to expose the WAL write location > besides flush one. So I'm not sure if it's really useful to track the > write location in the shmem besides the walreceiver-local memory. > What use case do you think of? Well, we're currently exposing that on the master via pg_stat_replication. I guess we could rip that out, but I think that if nothing else we're imagining eventually supporting a sync rep mode where the standby acknowledges WAL upon receipt rather than upon write. And the lag between the write and flush positions can be up to 16MB, so it doesn't seem entirely academic. Basically, the write position is the most WAL that could be on disk on standby and the flush is the most WAL that we're SURE is on disk on the standby. > Personally the term "stream" sounds more ambiguous than "write". > I cannot imagine what location the pg_last_xlog_stream_location or > stream_location actually returns, from the function name; WAL > location that has been received? written? flushed? replayed? > Since the "write" sounds cleaner, I like it. Well, the problem with receivedUpto is that it's really being used for two different things, neither of which is how much WAL has been received. One is where streaming is to start (hence, stream) and the other is how much we've flushed to disk (hence, flush). So you might think there were four positions: streaming start, write, flush, apply. But I think the first two are really the same: once you've received at least one byte, the position that you're streaming from and the write position are the same, so I think the name stream can span both concepts. OTOH, stream-start and flush are clearly NOT the same - there is a small but potentially significant delay between stream/write and flush. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
On Wed, Feb 16, 2011 at 7:07 AM, Lukas Eder wrote: > So what should I do? File a bug to the main Postgres mailing list? Or just > not support that feature? Well, I thought you just said you'd ruled out a PG bug? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
On Wed, Feb 16, 2011 at 7:03 AM, Oliver Jowett wrote: > On 17/02/11 00:58, Robert Haas wrote: >> On Wed, Feb 16, 2011 at 3:30 AM, Lukas Eder wrote: >>> I'm not trying to fix the signature. I want exactly that signature. I want >>> to return 1 UDT as an OUT parameter from a function. >>> >>> Somewhere between JDBC and the database, this signature is lost, and JDBC's >>> internal code tells me that I have to bind 6 OUT parameters, instead of 1. >>> It happens to be so, because the UDT contains 6 attributes, so somehow the >>> JDBC/database protocol flattens the UDT, and I think that's a bug, either in >>> JDBC or in the protocol or in the database. My findings were that I can >>> correctly read the UDT OUT parameter using the pgAdmin III tool, so I >>> excluded the database as a bug holder candidate. >> >> Oh, OK. Sorry, I can't help you any with the JDBC side... > > Well, the underlying problem is that "SELECT * from > function_with_one_out_parameter()" is returning *6* columns, not 1 > column. I don't know if that's expected or not on the plpgsql side, but > the JDBC driver has no way of distinguishing that sort of result from a > function that has 6 OUT parameters. If you do SELECT function_with_one_out_parameter() rather than SELECT * FROM function_with_one_out_parameter(), you'll get just one argument. Does that help at all? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
If I may give some suggestion, I was tried to investigate this, and maybe some this will help When you create procedure with out parameters then return type of this is implicit calculated and may be record or base type (if exactly one out param is defined). In many places I saw comparison of return type to recordoid or complex type, but check against complex type is through pg_types only, if typtype is marked 'c'. Unfortunately both rows and STRUCT (complex) has there 'c' - and this is OK for situation when procedure will return "table". But for complex types not being recordoid I think additional check should go. I mean to use get_rel_relkind() and e.g. check if it is pure complex type. By the way, Actually, based on above I saw funny things - I can create table with column type being other table :) And now If my one output parameter will be of complex type and relkind row type, what should I get? On Wed, 16 Feb 2011 09:30:43 +0100, Lukas Eder wrote: I'm not trying to fix the signature. I want exactly that signature. I want to return 1 UDT as an OUT parameter from a function. Somewhere between JDBC and the database, this signature is lost, and JDBC's internal code tells me that I have to bind 6 OUT parameters, instead of 1. It happens to be so, because the UDT contains 6 attributes, so somehow the JDBC/database protocol flattens the UDT, and I think that's a bug, either in JDBC or in the protocol or in the database. My findings were that I can correctly read the UDT OUT parameter using the pgAdmin III tool, so I excluded the database as a bug holder candidate. Cheers Lukas 2011/2/15 Robert Haas On Sat, Feb 12, 2011 at 6:16 AM, Lukas Eder wrote: > I had tried that before. That doesn't seem to change anything. JDBC still > expects 6 OUT parameters, instead of just 1... Oh, hrm. I thought you were trying to fix the return value, rather than the signature. I am not sure how to fix the signature. Can you just make it return RECORD? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com [2] The Enterprise PostgreSQL Company Links: -- [1] mailto:lukas.e...@gmail.com [2] http://www.enterprisedb.com [3] mailto:robertmh...@gmail.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] Fwd: [JDBC] Weird issues when reading UDT from stored function
On 17/02/11 01:10, Robert Haas wrote:
> If you do SELECT function_with_one_out_parameter() rather than SELECT
> * FROM function_with_one_out_parameter(), you'll get just one
> argument. Does that help at all?
Unfortunately, not really, because it doesn't work for cases where
there's more than one OUT parameter (if you use the SELECT f() form in
that case, you get one gigantic result column, not one column per OUT
parameter)
I dug into the code and it's actually slightly different to what I
originally described. Currently given a JDBC escape of the form
"{ call f(?,?,?,?) }"
it will rewrite that to:
"SELECT * FROM f($1,$2,$3,$4) AS RESULT"
and this rewriting happens before we know which parameters are bound as
OUT parameters. So we can't special-case the one-OUT-parameter case
without quite a rewrite (no pun intended).
Once we get to the point of query execution, we know which parameters
are OUT parameters, and we bind void parameter values to those (v3
protocol). You have to do a PREPARE/EXECUTE to pass in void parameter
types to get the equivalent via psql, as far as I can tell.
Anyway, it's a bit counterintuitive that
SELECT * FROM f($1,$2) AS RESULT
where f() takes two OUT parameters always returns two columns, but
SELECT * FROM f($1) AS RESULT
might return any number of columns! Is that really the correct behavior
here?
Oliver
--
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] [PERFORM] pgbench to the MAXINT
Tom Lane wrote: I think that might be a good idea --- it'd reduce the cross-platform variability of the results quite a bit, I suspect. random() is not to be trusted everywhere, but I think erand48 is pretty much the same wherever it exists at all (and src/port/ provides it elsewhere). Given that pgbench will run with threads in some multi-worker configurations, after some more portability research I think odds are good we'd get nailed by http://sourceware.org/bugzilla/show_bug.cgi?id=10320 : "erand48 implementation not thread safe but POSIX says it should be". The AIX docs have a similar warning on them, so who knows how many versions of that library have the same issue. Maybe we could make sure the one in src/port/ is thread safe and make sure pgbench only uses it. This whole area continues to be messy enough that I think the patch needs to brew for another CF before it will all be sorted out properly. I'll mark it accordingly and can pick this back up later. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
That was my opinion, but you're saying that JDBC is not the cause either? 2011/2/16 Robert Haas > On Wed, Feb 16, 2011 at 7:07 AM, Lukas Eder wrote: > > So what should I do? File a bug to the main Postgres mailing list? Or > just > > not support that feature? > > Well, I thought you just said you'd ruled out a PG bug? > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: [HACKERS] Fwd: [JDBC] Weird issues when reading UDT from stored function
Hmm, good point. I should try that. I have only tried these syntaxes:
connection.prepareStatement("select * from p_enhance_address2()");
connection.prepareCall("{ call p_enhance_address2(?) }"); // with an
output parameter registered
Since I'm doing this for my database abstraction tool
http://jooq.sourceforge.net, I could add a specialised Postgres stored
procedures abstraction and hide these details from the outside world...
Thanks for the hint!
2011/2/16 Robert Haas
> On Wed, Feb 16, 2011 at 7:03 AM, Oliver Jowett
> wrote:
> > On 17/02/11 00:58, Robert Haas wrote:
> >> On Wed, Feb 16, 2011 at 3:30 AM, Lukas Eder
> wrote:
> >>> I'm not trying to fix the signature. I want exactly that signature. I
> want
> >>> to return 1 UDT as an OUT parameter from a function.
> >>>
> >>> Somewhere between JDBC and the database, this signature is lost, and
> JDBC's
> >>> internal code tells me that I have to bind 6 OUT parameters, instead of
> 1.
> >>> It happens to be so, because the UDT contains 6 attributes, so somehow
> the
> >>> JDBC/database protocol flattens the UDT, and I think that's a bug,
> either in
> >>> JDBC or in the protocol or in the database. My findings were that I can
> >>> correctly read the UDT OUT parameter using the pgAdmin III tool, so I
> >>> excluded the database as a bug holder candidate.
> >>
> >> Oh, OK. Sorry, I can't help you any with the JDBC side...
> >
> > Well, the underlying problem is that "SELECT * from
> > function_with_one_out_parameter()" is returning *6* columns, not 1
> > column. I don't know if that's expected or not on the plpgsql side, but
> > the JDBC driver has no way of distinguishing that sort of result from a
> > function that has 6 OUT parameters.
>
> If you do SELECT function_with_one_out_parameter() rather than SELECT
> * FROM function_with_one_out_parameter(), you'll get just one
> argument. Does that help at all?
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
Re: [HACKERS] Fwd: [JDBC] Weird issues when reading UDT from stored function
So what should I do? File a bug to the main Postgres mailing list? Or just not support that feature? 2011/2/16 Oliver Jowett > On 17/02/11 00:58, Robert Haas wrote: > > On Wed, Feb 16, 2011 at 3:30 AM, Lukas Eder > wrote: > >> I'm not trying to fix the signature. I want exactly that signature. I > want > >> to return 1 UDT as an OUT parameter from a function. > >> > >> Somewhere between JDBC and the database, this signature is lost, and > JDBC's > >> internal code tells me that I have to bind 6 OUT parameters, instead of > 1. > >> It happens to be so, because the UDT contains 6 attributes, so somehow > the > >> JDBC/database protocol flattens the UDT, and I think that's a bug, > either in > >> JDBC or in the protocol or in the database. My findings were that I can > >> correctly read the UDT OUT parameter using the pgAdmin III tool, so I > >> excluded the database as a bug holder candidate. > > > > Oh, OK. Sorry, I can't help you any with the JDBC side... > > Well, the underlying problem is that "SELECT * from > function_with_one_out_parameter()" is returning *6* columns, not 1 > column. I don't know if that's expected or not on the plpgsql side, but > the JDBC driver has no way of distinguishing that sort of result from a > function that has 6 OUT parameters. > > Oliver >
Re: [HACKERS] Fwd: [JDBC] Weird issues when reading UDT from stored function
On Feb16, 2011, at 13:43 , Oliver Jowett wrote: > Anyway, it's a bit counterintuitive that > > SELECT * FROM f($1,$2) AS RESULT > > where f() takes two OUT parameters always returns two columns, but > > SELECT * FROM f($1) AS RESULT > > might return any number of columns! Is that really the correct behavior > here? Hm, I've browsed through the code and it seems that the current behaviour was implemented on purpose. build_function_result_tupdesc_d() in funcapi.c explicitly does /* * If there is no output argument, or only one, the function does not * return tuples. */ if (numoutargs < 2) return NULL; and examine_parameter_list() in functioncmds.c takes care to set requiredResultType to RECORDOID only if there is more than one OUT parameter, otherwise it gets set to the (one) OUT parameter's type. Might make sense to check the list archives, maybe there is something there that elucidates the reasoning behind this... best regards, Florian Pflug -- 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] new clang report
Peter Eisentraut wrote: > The lastest clang svn tip (2.9-to-be, I guess) builds PostgreSQL out of > the box and most tests pass. Specifically, it no longer chokes on > -D_GNU_SOURCE on Linux, which was the previously reported blocker. > > Warnings: > > Lots of these: > clang: warning: argument unused during compilation: '-mthreads' > clang: warning: argument unused during compilation: '-mt' FYI, our threading code throws every flag it can at the compiler --- it is very imprecise. > Possible fix, check both link and compile invocations for warnings in > configure: > > diff --git i/config/acx_pthread.m4 w/config/acx_pthread.m4 > index ceb161a..ee181f9 100644 > --- i/config/acx_pthread.m4 > +++ w/config/acx_pthread.m4 > @@ -142,7 +142,7 @@ main (int argc, char **argv) > } > _ACEOF > rm -f conftest.$ac_objext conftest$ac_exeext > -if test "`(eval $ac_link 2>&1 1>&5)`" = ""; then > +if test "`(eval $ac_link 2>&1 1>&5)`" = "" && test "`(eval > $ac_compile 2>&1 1>&5)`" = ""; then > # we continue with more flags because Linux needs -lpthread > # for libpq builds on PostgreSQL. The test above only > # tests for building binaries, not shared libraries. Yep, looks good. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Fix for Index Advisor related hooks
On Tue, Feb 15, 2011 at 11:59 AM, Tom Lane wrote:
> Gurjeet Singh writes:
> > Also attached is the patch expose_IndexSupportInitialize.patch, that
> makes
> > the static function IndexSupportInitialize() global so that the Index
> > Advisor doesn't have to reinvent the wheel to prepare an index structure
> > with opfamilies and opclasses.
>
> We are *not* doing that. That's a private function and will remain so.
>
I understand that we need to hide guts of an implementation. But without
this the Index Advisor will have to emulate what LookupOpclassInfo() does
and that's a lot of code that I am afraid, if emulated by another function
in Index Advisor, is more prone to obsolecence than calling
IndexSupportInitialize().
Regards,
--
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com
singh.gurjeet@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet
Mail sent from my BlackLaptop device
Re: [HACKERS] Fix for Index Advisor related hooks
On Tue, Feb 15, 2011 at 12:51 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > On Tue, Feb 15, 2011 at 8:24 AM, Heikki Linnakangas <
> > heikki.linnakan...@enterprisedb.com> wrote:
> >> On 11.02.2011 22:44, Gurjeet Singh wrote:
> >>> One one hand get_actual_variable_range() expects that virtual indexes
> do
> >>> not
> >>> have an OID assigned, on the other hand explain_get_index_name_hook()
> is
> >>> handed just an index's OID to get its name back; IMHO these are based
> on
> >>> two
> >>> conflicting assumptions about whether a virtual index will have an OID
> >>> assigned.
>
> >> The new hook takes an index oid as argument, so I gather that you
> resolved
> >> the contradiction by deciding that fictitious indexes have OIDs. How do
> you
> >> assign those OIDs? Do fictitious indexes have entries in pg_index?
>
> > No, a fictitious index does not touch pg_index. The Index Advisor uses
> > GetNewOid(pg_class) to generate a new OID for the fictitious index.
>
> That seems like a very expensive, and lock-inducing, way of assigning a
> fictitious OID. They don't need to be globally unique.
They need to be unique for a run a session, and be distinguishable from
normal indexes so that explain_get_index_name_hook() can get a generated
name for the hypothetical index.
> I suggest you
> consider the idea I suggested back in 2007:
>
> * In this toy example we just assign all hypothetical indexes
> * OID 0, and the explain_get_index_name hook just prints
> * . In a realistic situation we'd probably
> * assume that OIDs smaller than, say, 100 are never the OID of
> * any real index, allowing us to identify one of up to 100
> * hypothetical indexes per plan. Then we'd need to save aside
> * some state data that would let the explain hooks print info
> * about the selected index.
>
> As far as the immediate problem goes, I agree that
> get_actual_variable_range is mistaken, but I think a cleaner and cheaper
> solution would be to add a bool "hypothetical" to IndexOptInfo.
>
Currently there are 2 sites interested in knowing if an index is
hypothetical:
1) explain_get_index_name_hook
2) get_actual_variable_range()
With this bool isHypothetical in place, explain_get_index_name() would
be unchanged, and the Index Advisor can use a locally generated Oid (not
from pg_class) to uniquely identify a hypothetical index.
And get_actual_variable_range() would be changed so:
-if (!OidIsValid(index->indexoid))
+if (index->ishypothetical)
I can code submit a patch for that.
BTW, you use the term 'fictitious' in the comments, would it be better
to standardize the term used for such an index? So either the comment would
be changed to call it hypothetical, or the structure member would be changed
to isfictitious.
Regards,
--
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com
singh.gurjeet@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet
Mail sent from my BlackLaptop device
Re: [HACKERS] Fwd: [JDBC] Weird issues when reading UDT from stored function
Florian Pflug writes: > Hm, I've browsed through the code and it seems that the current behaviour > was implemented on purpose. Yes, it's 100% intentional. The idea is to allow function authors to use OUT-parameter notation (in particular, the convention of assigning to a named variable to set the result) without forcing them into the overhead of returning a record when all they want is to return a scalar. So a single OUT parameter is *supposed* to work just like a function that does "returns whatever" without any OUT parameters. Even if you think this was a bad choice, which I don't, it's far too late to change it. 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] Fix for Index Advisor related hooks
Gurjeet Singh writes: > I understand that we need to hide guts of an implementation. But without > this the Index Advisor will have to emulate what LookupOpclassInfo() does > and that's a lot of code that I am afraid, if emulated by another function > in Index Advisor, is more prone to obsolecence than calling > IndexSupportInitialize(). The only reason you'd need that code is if you were trying to construct a fake Relation structure, which seems unnecessary and undesirable. 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] Fix for Index Advisor related hooks
Gurjeet Singh writes: > BTW, you use the term 'fictitious' in the comments, would it be better > to standardize the term used for such an index? So either the comment would > be changed to call it hypothetical, or the structure member would be changed > to isfictitious. Yeah, hypothetical is the more-established term I think. 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] Sync Rep for 2011CF1
On Tue, Feb 15, 2011 at 10:13 PM, Fujii Masao wrote: > On Wed, Feb 16, 2011 at 2:08 AM, Robert Haas wrote: >> On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao wrote: >>> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas >>> wrote: I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it also sends a status update every time the WAL is flushed. If the walreceiver is busy receiving and flushing, that would happen once per WAL segment, which seems sensible. >>> >>> This change can make the callback function "WalRcvDie()" call ereport(ERROR) >>> via XLogWalRcvFlush(). This looks unsafe. >> >> Good catch. Is the cleanest solution to pass a boolean parameter to >> XLogWalRcvFlush() indicating whether we're in the midst of dying? > > Agreed if the comment about why such a boolean parameter is > required is added. OK, done. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Sync Rep for 2011CF1
On Tue, 2011-02-15 at 12:08 -0500, Robert Haas wrote: > On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao wrote: > > On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas > > wrote: > >> I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it also > >> sends a status update every time the WAL is flushed. If the walreceiver is > >> busy receiving and flushing, that would happen once per WAL segment, which > >> seems sensible. > > > > This change can make the callback function "WalRcvDie()" call ereport(ERROR) > > via XLogWalRcvFlush(). This looks unsafe. > > Good catch. Is the cleanest solution to pass a boolean parameter to > XLogWalRcvFlush() indicating whether we're in the midst of dying? Surely if you do this then sync rep will fail to respond correctly if WalReceiver dies. Why is it OK to write to disk, but not OK to reply? -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and 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] multiset patch review
On Tue, Feb 15, 2011 at 7:13 AM, Robert Haas wrote: > On Tue, Feb 15, 2011 at 4:31 AM, Itagaki Takahiro > wrote: >> array_flatten() no longer exists. I added array_trim() as an alias >> to trim_array() because it would be a FAQ. > > I don't like the alias thing - let's add one name or the other, not both. > > Similarly, let's NOT add array_union_all as an alias for array_concat. > > 'cannot use multi-dimensional arrays' reads awkwardly to me. I think > it should say something like "sorting of multi-dimensional arrays is > not supported". > > multi-demensional -> multi-dimensional > > slaces -> slices > > The formula in the trim_array comment is apparently misparenthesized. I think we're out of time to keep bikeshedding this. Let's revisit it for 9.2. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] [PERFORM] pgbench to the MAXINT
Greg Smith writes: > Given that pgbench will run with threads in some multi-worker > configurations, after some more portability research I think odds are > good we'd get nailed by > http://sourceware.org/bugzilla/show_bug.cgi?id=10320 : "erand48 > implementation not thread safe but POSIX says it should be". The AIX > docs have a similar warning on them, so who knows how many versions of > that library have the same issue. FWIW, I think that bug report is effectively complaining that if you use both drand48 and erand48, the former can impact the latter. If you use only erand48, I don't see that there's any problem. 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] Sync Rep for 2011CF1
On 16.02.2011 17:36, Simon Riggs wrote: On Tue, 2011-02-15 at 12:08 -0500, Robert Haas wrote: On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao wrote: On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas wrote: I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it also sends a status update every time the WAL is flushed. If the walreceiver is busy receiving and flushing, that would happen once per WAL segment, which seems sensible. This change can make the callback function "WalRcvDie()" call ereport(ERROR) via XLogWalRcvFlush(). This looks unsafe. Good catch. Is the cleanest solution to pass a boolean parameter to XLogWalRcvFlush() indicating whether we're in the midst of dying? Surely if you do this then sync rep will fail to respond correctly if WalReceiver dies. Why is it OK to write to disk, but not OK to reply? Because the connection might be dead. A broken connection is a likely cause of walreceiver death. -- 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
[HACKERS] Determining period between 2 dates
Hi all, I'm wondering what people think of introducing some kind of function to extract the number of units between 2 dates? At the moment there's no way to do this. Take the following example: Event 1 is '1985-10-26 01:22:00' Event 2 is now. How many minutes between these 2 events? What I don't want is how many years, months, days and hours there are between them. This could potentially involve implementing age(timestamp, timestamp, interval), like: postgres=# SELECT age(current_date, '1985-10-26 01:22:00'::timestamp, '1 second') as age_in_seconds; age_in_seconds 798733367 (1 row) Is this easily done? Thanks -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 -- 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] Determining period between 2 dates
On Wed, Feb 16, 2011 at 10:47 AM, Thom Brown wrote:
> Hi all,
>
> I'm wondering what people think of introducing some kind of function
> to extract the number of units between 2 dates? At the moment there's
> no way to do this. Take the following example:
>
> Event 1 is '1985-10-26 01:22:00'
> Event 2 is now.
>
> How many minutes between these 2 events? What I don't want is how
> many years, months, days and hours there are between them.
>
> This could potentially involve implementing age(timestamp, timestamp,
> interval), like:
>
> postgres=# SELECT age(current_date, '1985-10-26 01:22:00'::timestamp,
> '1 second') as age_in_seconds;
> age_in_seconds
>
> 798733367
> (1 row)
>
> Is this easily done?
How about something like this:
rhaas=# select (extract('epoch' from now()) - extract('epoch' from
timestamptz '1985-10-26 01:22:00')) / 60;
?column?
--
13311989.7435394
(1 row)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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] Determining period between 2 dates
On Wed, 2011-02-16 10:52:13 -0500, Robert Haas wrote:
> On Wed, Feb 16, 2011 at 10:47 AM, Thom Brown wrote:
> > I'm wondering what people think of introducing some kind of function
> > to extract the number of units between 2 dates? At the moment there's
> > no way to do this. Take the following example:
> >
> > Event 1 is '1985-10-26 01:22:00'
> > Event 2 is now.
> >
> > How many minutes between these 2 events? What I don't want is how
> > many years, months, days and hours there are between them.
> >
> > This could potentially involve implementing age(timestamp, timestamp,
> > interval), like:
> >
> > postgres=# SELECT age(current_date, '1985-10-26 01:22:00'::timestamp,
> > '1 second') as age_in_seconds;
> > age_in_seconds
> >
> > 798733367
> > (1 row)
> >
> > Is this easily done?
>
> How about something like this:
>
> rhaas=# select (extract('epoch' from now()) - extract('epoch' from
> timestamptz '1985-10-26 01:22:00')) / 60;
> ?column?
> --
> 13311989.7435394
> (1 row)
Even shorter, an interval can be used directly:
emails=# select extract(epoch from now() - '2010-01-01 11:45:13'::timestamp)/60;
?column?
592150.7494153
(1 row)
--
Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481
Signature of: Friends are relatives you make for yourself.
the second :
signature.asc
Description: Digital signature
Re: [HACKERS] Determining period between 2 dates
On 16 February 2011 15:57, Jan-Benedict Glaw wrote:
> On Wed, 2011-02-16 10:52:13 -0500, Robert Haas wrote:
>> On Wed, Feb 16, 2011 at 10:47 AM, Thom Brown wrote:
>> > I'm wondering what people think of introducing some kind of function
>> > to extract the number of units between 2 dates? At the moment there's
>> > no way to do this. Take the following example:
>> >
>> > Event 1 is '1985-10-26 01:22:00'
>> > Event 2 is now.
>> >
>> > How many minutes between these 2 events? What I don't want is how
>> > many years, months, days and hours there are between them.
>> >
>> > This could potentially involve implementing age(timestamp, timestamp,
>> > interval), like:
>> >
>> > postgres=# SELECT age(current_date, '1985-10-26 01:22:00'::timestamp,
>> > '1 second') as age_in_seconds;
>> > age_in_seconds
>> >
>> > 798733367
>> > (1 row)
>> >
>> > Is this easily done?
>>
>> How about something like this:
>>
>> rhaas=# select (extract('epoch' from now()) - extract('epoch' from
>> timestamptz '1985-10-26 01:22:00')) / 60;
>> ?column?
>> --
>> 13311989.7435394
>> (1 row)
>
> Even shorter, an interval can be used directly:
>
> emails=# select extract(epoch from now() - '2010-01-01
> 11:45:13'::timestamp)/60;
> ?column?
>
> 592150.7494153
> (1 row)
For the number of fortnights, that becomes:
select extract(epoch from now() - '2010-01-01 11:45:13'::timestamp)/60/60/24/14;
You'd think with PostgreSQL having such a rich type system, it
wouldn't need to come to that. It's just asking for the number of
intervals between 2 timestamps rather than the number of seconds and
dividing it to the point you get your answer.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
--
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] CommitFest 2011-01 as of 2011-02-04
On Tue, 2011-02-15 at 06:49 +0200, Peter Eisentraut wrote: > On mån, 2011-02-14 at 11:49 -0500, Stephen Frost wrote: > > Perhaps a thought for next time would be to offset things a bit. eg: > > > > CF 2011-03 (or whatever): > > 2011-02-14: Patches should all be submitted > > 2011-02-14: Reviewers start > > 2011-03-01: Committers start w/ 'Ready for Committer' patches > > 2011-03-14: Patches not marked 'Ready for Committer' get bounced > > 2011-03-31: All patches committed > > > > I'm not against the 'waiting on author' approach, but I do feel like > > if we're going to continue to have it, we need to spread it out a bit > > more. > > I don't think it is realistic to add even more dates and bounds and > guidelines. Though I agree with that, I see Stephen's suggested sequence of events as a useful one for CFs managers. > People are already widely ignoring the current ones. I don't think people are ignoring things deliberately. List traffic is high and unless you are 100% full time on this, you can't possibly hope to read them all, respond to the relevant ones and do your own work too. Especially when many folk have a day job as well. > If you want to have the ability the bounce things more aggressively, I'd > argue for shorter and more frequent commitfests. Say, one week per > month. That is the blink of an eye for me, so don't want more frequent CFs. The focus should be on organising ourselves so that the most number of high quality features get into Postgres. I don't see anything to be gained by bouncing things aggressively; strict time-boxing works on 2 weekly cycles, not on annual ones. We're doing OK. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and 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] contrib loose ends: 9.0 to 9.1 incompatibilities
Robert Haas writes: > On Tue, Feb 15, 2011 at 7:10 PM, Tom Lane wrote: >> 2. We could add extra pg_proc.h entries matching the old signatures. >> For the moment these would be stub functions that call the same C code, >> though eventually perhaps they could be changed to throw errors. > +1. OK, that's about what I thought too. >> A related issue is that we similarly changed the signatures of GIN >> support functions that properly belong to intarray and tsearch2. >> That affects what the "unpackaged" conversion scripts need to expect. >> >> What I'm inclined to do there is just change the scripts to absorb >> the old functions as-is without trying to correct their signatures. >> Doing otherwise is a bit painful because they are operator class >> members, and there's no easy way to unhook them from the opclasses >> without dropping the opclasses. The only other fix I can think of >> is a direct UPDATE on pg_proc to fix the proargtypes entries, which >> would work but seems even uglier. > Hmm. Can we just invent a way to hook them from the opclasses? I > have a feeling that now that this extension stuff is in we're going to > discover a bunch of these little utility commands that we managed to > get by without in the past but now that we're getting more organized > about it, we'll need 'em. Maybe so. My thought is that extension update scripts are going to be executed in very well-defined circumstances and it might not be so bad to let them do direct UPDATEs on the system catalogs instead of writing lots of special-purpose ALTER commands. In the particular case here, unhooking, deleting, recreating, and rehooking the functions seems like way more trouble than it's worth. >> But there's no other answer except embarking on a project to materially >> upgrade the capabilities of ALTER OPERATOR CLASS/FAMILY, something I >> really don't want to be doing right now. > Or maybe that answers my question. Yeah. Even granted that we should do it someday, today is not that day. 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] Sync Rep for 2011CF1
On Wed, 2011-02-16 at 17:40 +0200, Heikki Linnakangas wrote: > On 16.02.2011 17:36, Simon Riggs wrote: > > On Tue, 2011-02-15 at 12:08 -0500, Robert Haas wrote: > >> On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao > >> wrote: > >>> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas > >>> wrote: > I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it > also > sends a status update every time the WAL is flushed. If the walreceiver > is > busy receiving and flushing, that would happen once per WAL segment, > which > seems sensible. > >>> > >>> This change can make the callback function "WalRcvDie()" call > >>> ereport(ERROR) > >>> via XLogWalRcvFlush(). This looks unsafe. > >> > >> Good catch. Is the cleanest solution to pass a boolean parameter to > >> XLogWalRcvFlush() indicating whether we're in the midst of dying? > > > > Surely if you do this then sync rep will fail to respond correctly if > > WalReceiver dies. > > > > Why is it OK to write to disk, but not OK to reply? > > Because the connection might be dead. A broken connection is a likely > cause of walreceiver death. Would it not be possible to check that? -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and 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] Determining period between 2 dates
Thom Brown wrote: > For the number of fortnights, that becomes: > > select extract(epoch from now() - '2010-01-01 > 11:45:13'::timestamp)/60/60/24/14; > > You'd think with PostgreSQL having such a rich type system, it > wouldn't need to come to that. It's just asking for the number of > intervals between 2 timestamps rather than the number of seconds > and dividing it to the point you get your answer. The SQL standard has syntax to support getting that in YEAR, MONTH, DAY, HOUR, MINUTE, or SECOND (with the ability to specify decimal positions for SECOND). Nothing in there about fortnights, however. I seem to remember previous discussions where people have resisted implementing this part of the standard, although I can't remember the reason. I'll probably be reminded soon... :-) -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] Determining period between 2 dates
On Wed, Feb 16, 2011 at 18:03, Thom Brown wrote: > For the number of fortnights, that becomes: > > select extract(epoch from now() - '2010-01-01 > 11:45:13'::timestamp)/60/60/24/14; > > You'd think with PostgreSQL having such a rich type system, it > wouldn't need to come to that. It's just asking for the number of > intervals between 2 timestamps rather than the number of seconds and > dividing it to the point you get your answer. I think a good generic solution would be an interval/interval operator that returns numeric. Then the above becomes: SELECT (now() - timestamp '2010-01-01 11:45:13') / interval '2 weeks'; However, looking at the code, it's not so obvious what to do if the intervals contain months. Regards, Marti -- 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] arrays as pl/perl input arguments [PATCH]
On Sat, Feb 12, 2011 at 02:17:12AM +0200, Alexey Klyukin wrote: > > So, here is the v8. Instead of rewriting the encode_array_literal I've added > another function, encode_type_literal (could use a better name). Given that encode_array_literal() encodes an _array_ as a literal, I'd assume encode_type_literal() encodes a _type_ as a literal. I'd suggest encode_typed_literal() as a better name. Tim [just passing though] -- 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] contrib loose ends: 9.0 to 9.1 incompatibilities
On Wed, Feb 16, 2011 at 11:29 AM, Tom Lane wrote: >> Hmm. Can we just invent a way to hook them from the opclasses? I >> have a feeling that now that this extension stuff is in we're going to >> discover a bunch of these little utility commands that we managed to >> get by without in the past but now that we're getting more organized >> about it, we'll need 'em. > > Maybe so. My thought is that extension update scripts are going to be > executed in very well-defined circumstances and it might not be so bad > to let them do direct UPDATEs on the system catalogs instead of writing > lots of special-purpose ALTER commands. In the particular case here, > unhooking, deleting, recreating, and rehooking the functions seems like > way more trouble than it's worth. The trouble is that we have no mechanism for conditional logic in upgrade scripts, so if the system catalog structure should change in a way that causes the hook and unhook mechanism to require different logic depending on which PG major version is in use, we're hosed. Or at the very least third-party extension authors are hosed. While I have to hold my nose every time I think about the architecture of pg_upgrade, one thing that it does do for us is provide a significant degree of insulation against problems caused by system catalog changes. Ultimately, the effect of being unable to change on disk format, system catalogs, or other aspects of the system between version is that important and valuable improvements get shot down on compatibility grounds. Inventing mechanisms that protect us from that is important. I invented the extensible EXPLAIN-options syntax not so much because I wanted to be able to get XML output out of it as because I figured that, once we had a way of adding options without fighting with the syntax, people who weren't me would figure out what those options should be and add them. And so it proved: EXPLAIN (BUFFERS) is a very nice feature, much more useful to me personally than EXPLAIN (FORMAT), and I think eventually we'll have more. I don't feel that bad about releasing 9.1 without this unhook-and-rehook machinery because I think we've done pretty well to get this feature as far as we have, and at this point I'm definitely in the camp of wanting a release sooner rather than wanting to squeeze more stuff into it. Having said that, these kinds of problems are impossible to correct without pain if you wait until you're actually backed against the wall. Push will come to shove when someone wants to change the system catalog representation in a way that makes the UPDATE commands used for previous releases no longer work. At that point, regardless of whether you add the unhook-and-rehook mechanism or whether you just modify the UPDATE commands to work with the new structure, you've now imposed a minimum major PG version requirement on that extension that is otherwise unnecessary, or else you now have to distribute two different versions of the extension based on associated major PG release. If we add the unhook-and-rehook mechanism in 9.2, there's a good chance that by the time we need it, a few releases will have gone by and no great pain will result. If not, then at some point there will be a flag day. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Debian readline/libedit breakage
Tom Lane wrote: > Robert Haas writes: > > On Fri, Feb 11, 2011 at 3:10 PM, Tom Lane wrote: > >> We have code that exists in both psql and the backend (cf src/port/) > >> so I'm not sure this really will satisfy the more rabid GPL partisans. > >> And this whole discussion is about satisfying the most rabid of them, > >> remember. ?I don't really think that anything other than "relicense all > >> of Postgres as GPL" will make them happy. > > > Which, by the way, *no one* has the authority to do. > > Right. So the long term solution in my mind is to migrate away from > readline and towards libedit. I'm just not sufficiently worried about > this to put any of my own cycles into making libedit good enough. Agreed. If we can create a database, someone can get libedit to work 100%! There is no excuse for this not being done, seeing that libreadline has been (viral) GPL forever and has changed APIs regularly and broken things for us. Even going with GNUTLS does not help us with that. Can someone take ownership of this, get involved with the libedit folks, get Debian to use their fixes, and solve this problem for us? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Sync Rep for 2011CF1
On Wed, Feb 16, 2011 at 11:32 AM, Simon Riggs wrote: > On Wed, 2011-02-16 at 17:40 +0200, Heikki Linnakangas wrote: >> On 16.02.2011 17:36, Simon Riggs wrote: >> > On Tue, 2011-02-15 at 12:08 -0500, Robert Haas wrote: >> >> On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao >> >> wrote: >> >>> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas >> >>> wrote: >> I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it >> also >> sends a status update every time the WAL is flushed. If the walreceiver >> is >> busy receiving and flushing, that would happen once per WAL segment, >> which >> seems sensible. >> >>> >> >>> This change can make the callback function "WalRcvDie()" call >> >>> ereport(ERROR) >> >>> via XLogWalRcvFlush(). This looks unsafe. >> >> >> >> Good catch. Is the cleanest solution to pass a boolean parameter to >> >> XLogWalRcvFlush() indicating whether we're in the midst of dying? >> > >> > Surely if you do this then sync rep will fail to respond correctly if >> > WalReceiver dies. >> > >> > Why is it OK to write to disk, but not OK to reply? >> >> Because the connection might be dead. A broken connection is a likely >> cause of walreceiver death. > > Would it not be possible to check that? I'm not actually sure that it matters that much whether we do or not. ISTM that the WAL receiver is normally going to exit the main loop (in WalReceiverMain) right here: /* Process any requests or signals received recently */ ProcessWalRcvInterrupts(); But to get to that point, we either have to be making our first pass through the loop (in which case nothing interesting has happened yet) or we have to have just completed an iteration through the loop (in which case we just sent a reply). I think that the only thing that can have changed since the last reply is the replay position, which this version of the sync rep patch doesn't care about anyway. Even if it did, I'm not sure it'd be worth complicating the die path to squeeze in one final reply. Actually, on further reflection, I'm not even sure why we bother with the fsync. It seems like a useful safeguard but I'm not seeing how we can get to that point without having fsync'd everything anyway. Am I missing something? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] contrib loose ends: 9.0 to 9.1 incompatibilities
On Wed, Feb 16, 2011 at 12:24 PM, Heikki Linnakangas wrote: > On 16.02.2011 19:17, Robert Haas wrote: >> >> The trouble is that we have no mechanism for conditional logic in >> upgrade scripts,... > > Can't you put a DO-block there? It's not pretty, but should work.. Tom has repeatedly objected to that solution on the grounds that someone could DROP LANGUAGE plpgsql. In practice, I am sure many third-party extensions will do just that if we don't provide suitable core infrastructure, but not pretty definitely covers it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] contrib loose ends: 9.0 to 9.1 incompatibilities
Robert Haas writes: > The trouble is that we have no mechanism for conditional logic in > upgrade scripts, so if the system catalog structure should change in a > way that causes the hook and unhook mechanism to require different > logic depending on which PG major version is in use, we're hosed. Well, actually, we *do* have such a mechanism (plpgsql), we just don't want to use it unless we have to. I wouldn't feel too bad about saying "upgrading tsearch2 directly from 9.0 to 9.4 requires that you have plpgsql installed when you issue the CREATE EXTENSION command". I grant all your points about abstraction being a good thing. But there are only so many hours in the day, and writing (and then maintaining) thousands of lines of C code on the grounds that maybe that will let somebody avoid writing some ugly code someday is not going to get to the top of my to-do list anytime in the foreseeable future. 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] contrib loose ends: 9.0 to 9.1 incompatibilities
On 16.02.2011 19:17, Robert Haas wrote: The trouble is that we have no mechanism for conditional logic in upgrade scripts,... Can't you put a DO-block there? It's not pretty, but should work.. -- 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] Sync Rep for 2011CF1
On 16.02.2011 19:29, Robert Haas wrote: Actually, on further reflection, I'm not even sure why we bother with the fsync. It seems like a useful safeguard but I'm not seeing how we can get to that point without having fsync'd everything anyway. Am I missing something? WalRcvDie() is called on error. For example, if the connection dies unexpectedly during walrcv_receive(). -- 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] Debian readline/libedit breakage
On 02/16/2011 12:29 PM, Bruce Momjian wrote: Tom Lane wrote: Robert Haas writes: On Fri, Feb 11, 2011 at 3:10 PM, Tom Lane wrote: We have code that exists in both psql and the backend (cf src/port/) so I'm not sure this really will satisfy the more rabid GPL partisans. And this whole discussion is about satisfying the most rabid of them, remember. �I don't really think that anything other than "relicense all of Postgres as GPL" will make them happy. Which, by the way, *no one* has the authority to do. Right. So the long term solution in my mind is to migrate away from readline and towards libedit. I'm just not sufficiently worried about this to put any of my own cycles into making libedit good enough. Agreed. If we can create a database, someone can get libedit to work 100%! There is no excuse for this not being done, seeing that libreadline has been (viral) GPL forever and has changed APIs regularly and broken things for us. Even going with GNUTLS does not help us with that. Can someone take ownership of this, get involved with the libedit folks, get Debian to use their fixes, and solve this problem for us? You're assuming a fact not in evidence, namely the existence of an identifiable group of "libedit folks". Last time I looked there was no such group. I'm not greatly in favor of encouraging people to spend lots of time on this. If they have cycles to spend I'd rather they spent them on Postgres features, rather than a project we'd probably end up owning forever. (And we shouldn't assume that GnuTLS is the right replacement for OpenSSL either, BTW). 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] Sync Rep for 2011CF1
On Wed, Feb 16, 2011 at 12:34 PM, Heikki Linnakangas wrote: > On 16.02.2011 19:29, Robert Haas wrote: >> >> Actually, on further reflection, I'm not even sure why we bother with >> the fsync. It seems like a useful safeguard but I'm not seeing how we >> can get to that point without having fsync'd everything anyway. Am I >> missing something? > > WalRcvDie() is called on error. For example, if the connection dies > unexpectedly during walrcv_receive(). Ah, OK. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] contrib loose ends: 9.0 to 9.1 incompatibilities
On Wed, Feb 16, 2011 at 12:31 PM, Tom Lane wrote: > Robert Haas writes: >> The trouble is that we have no mechanism for conditional logic in >> upgrade scripts, so if the system catalog structure should change in a >> way that causes the hook and unhook mechanism to require different >> logic depending on which PG major version is in use, we're hosed. > > Well, actually, we *do* have such a mechanism (plpgsql), we just don't > want to use it unless we have to. I wouldn't feel too bad about saying > "upgrading tsearch2 directly from 9.0 to 9.4 requires that you have > plpgsql installed when you issue the CREATE EXTENSION command". > > I grant all your points about abstraction being a good thing. But there > are only so many hours in the day, and writing (and then maintaining) > thousands of lines of C code on the grounds that maybe that will let > somebody avoid writing some ugly code someday is not going to get to > the top of my to-do list anytime in the foreseeable future. Well, it sounds like we're in agreement at least about 9.1, so we can leave the rest of the argument to another day. I *am* surprised that you think it would take *thousands* of lines of code. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] contrib loose ends: 9.0 to 9.1 incompatibilities
Robert Haas writes: > Well, it sounds like we're in agreement at least about 9.1, so we can > leave the rest of the argument to another day. I *am* surprised that > you think it would take *thousands* of lines of code. Well, it all depends on how much ALTER stuff you want to add. An open-ended commitment to write anything anybody could ever want would certainly run to thousands of lines. A narrow focus on fixing proven problems would probably be a lot more manageable ... but if you have ambitions of fixing problems before anyone has hit them, it's going to be hard to keep it small. 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] Debian readline/libedit breakage
On Wed, 2011-02-16 at 12:29 -0500, Bruce Momjian wrote: > Tom Lane wrote: > Can someone take ownership of this, get involved with the libedit folks, > get Debian to use their fixes, and solve this problem for us? That is a lot easier said that done. To be frank, I thought it was something that I would put CMD to task with because it would help not only Pg but the much wider community as well. However, the project is not small and I don't want CMD being solely responsible for something that will generate exactly 0 dollars. It is hard enough that we make well over 98% of our dollars not working on PostgreSQL but instead working with it. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- 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] Fix for Index Advisor related hooks
On Wed, Feb 16, 2011 at 10:25 AM, Tom Lane wrote:
> Gurjeet Singh writes:
> > I understand that we need to hide guts of an implementation. But without
> > this the Index Advisor will have to emulate what LookupOpclassInfo() does
> > and that's a lot of code that I am afraid, if emulated by another
> function
> > in Index Advisor, is more prone to obsolecence than calling
> > IndexSupportInitialize().
>
> The only reason you'd need that code is if you were trying to construct
> a fake Relation structure, which seems unnecessary and undesirable.
>
The planner requires IndexOptInfo, and for the planner to choose the
hypothetical index we need to fill in the fwdsortop, revsortop, opfamily and
opcintype, and this is the information that IndexAdvisor populates using
IndexSupportInitialize() (at least until c0b5fac7 changed the function
signature.
I am trying to populate an IndexOptInfo just like get_relation_info() does
after the 'info = makeNode(IndexOptInfo);' line.
What would be the best way to build an IndexOptInfo for a plain BTREE index
for different data types?
Regards,
--
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com
singh.gurjeet@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet
Mail sent from my BlackLaptop device
Re: [HACKERS] arrays as pl/perl input arguments [PATCH]
Excerpts from Tim Bunce's message of mié feb 16 14:08:11 -0300 2011: > On Sat, Feb 12, 2011 at 02:17:12AM +0200, Alexey Klyukin wrote: > > > > So, here is the v8. Instead of rewriting the encode_array_literal I've added > > another function, encode_type_literal (could use a better name). > Given that encode_array_literal() encodes an _array_ as a literal, > I'd assume encode_type_literal() encodes a _type_ as a literal. > > I'd suggest encode_typed_literal() as a better name. FYI I'm looking at this patch (v10), and I'll incorporate Tim's suggestion. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. 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] Spontaneous PITR standby activiation
On 26 November 2009 07:26, Heikki Linnakangas wrote: > David Christensen wrote: >> 1) is there a hard limit of the number of times the archive_command will >> attempt? I didn't see anything documented about this in the PITR or >> config docs, so I'm guessing the 10 failures I saw in the log were just >> coincidental. > > There's no limit. It will try forever. > >> 2) are the archive_command failures in the master's log responsible for >> the redo records? > > No, archive_command failures shouldn't affect the standby. > >> 3) would a Pg forced shutdown cause issues with the generated WAL when >> replaying? > > No. > >> 4) at first I thought it had to do with a bug/failure in pg_standby, but >> I'm wondering if it has to do with the "record with zero length" >> referenced in the standby's logs. Thoughts? > > That basically means that WAL replay reached end of WAL. The rest of the > WAL file is probably full of zeros. It's quite normal in crash recovery, > for example. But I have no explanation for why such a WAL file was archived. Were any conclusions made out of this during any discussion, or bug fixes made as a result? -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 -- 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] Extensions vs PGXS' MODULE_PATHNAME handling
Tom Lane writes: > [ scratches head ... ] Why is your version generating so many > unnecessary @extschema@ uses? I just ran create table tomlist as select your query and create table dimlist as select my query, then: dim=# select * from tomlist except select * from dimlist; desc -- ALTER EXTENSION hstore ADD operator family @extschema@.gin_hstore_ops for access method gin; ALTER EXTENSION hstore ADD operator class @extschema@.btree_hstore_ops for access method btree; ALTER EXTENSION hstore ADD operator family @extschema@.hash_hstore_ops for access method hash; ALTER EXTENSION hstore ADD operator class @extschema@.gist_hstore_ops for access method gist; ALTER EXTENSION hstore ADD operator family @extschema@.gist_hstore_ops for access method gist; ALTER EXTENSION hstore ADD cast from text[] to @extschema@.hstore; ALTER EXTENSION hstore ADD operator class @extschema@.gin_hstore_ops for access method gin; ALTER EXTENSION hstore ADD operator family @extschema@.btree_hstore_ops for access method btree; ALTER EXTENSION hstore ADD operator class @extschema@.hash_hstore_ops for access method hash; (9 rows) No difference on @extschema@ use here. dim=# select t.desc, d.desc from tomlist t natural join dimlist d limit 1; -[ RECORD 1 ]- desc | ALTER EXTENSION hstore ADD type @extschema@.hstore; desc | ALTER EXTENSION hstore ADD type @extschema@.hstore; dim=# select t.desc, d.desc from tomlist t natural join dimlist d limit 1 offset 10; -[ RECORD 1 ]--- desc | ALTER EXTENSION hstore ADD function @extschema@.slice(@extschema@.hstore,text[]); desc | ALTER EXTENSION hstore ADD function @extschema@.slice(@extschema@.hstore,text[]); Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- 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: Cleanup ClusterInfo initialization in pg_upgrade
Alvaro Herrera wrote:
> Cleanup ClusterInfo initialization in pg_upgrade
Global structs are already initialized to zero, so no need to initialize
them. I discussed this with Alvaro, and he suggested that there is no
need to free memory before we exit. The attached, applied patch makes
both changes.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/contrib/pg_upgrade/info.c b/contrib/pg_upgrade/info.c
index 7a5a050..0c518a2 100644
*** a/contrib/pg_upgrade/info.c
--- b/contrib/pg_upgrade/info.c
*** static void free_rel_infos(RelInfoArr *r
*** 22,33
static void print_db_infos(DbInfoArr *dbinfo);
static void print_rel_infos(RelInfoArr *arr);
- void
- initialize_cluster_info(ClusterInfo *cluster)
- {
- cluster->dbarr.ndbs = 0;
- cluster->dbarr.dbs = NULL;
- }
/*
* gen_db_file_maps()
--- 22,27
diff --git a/contrib/pg_upgrade/pg_upgrade.c b/contrib/pg_upgrade/pg_upgrade.c
index 319ee79..061544c 100644
*** a/contrib/pg_upgrade/pg_upgrade.c
--- b/contrib/pg_upgrade/pg_upgrade.c
*** main(int argc, char **argv)
*** 63,71
char *deletion_script_file_name = NULL;
bool live_check = false;
- initialize_cluster_info(&old_cluster);
- initialize_cluster_info(&new_cluster);
-
parseCommandLine(argc, argv);
output_check_banner(&live_check);
--- 63,68
*** set_frozenxids(void)
*** 428,458
static void
cleanup(void)
{
- int tblnum;
char filename[MAXPGPATH];
! for (tblnum = 0; tblnum < os_info.num_tablespaces; tblnum++)
! pg_free(os_info.tablespaces[tblnum]);
! pg_free(os_info.tablespaces);
!
! free_db_and_rel_infos(&old_cluster.dbarr);
! free_db_and_rel_infos(&new_cluster.dbarr);
! pg_free(log_opts.filename);
! pg_free(os_info.user);
! pg_free(old_cluster.controldata.lc_collate);
! pg_free(new_cluster.controldata.lc_collate);
! pg_free(old_cluster.controldata.lc_ctype);
! pg_free(new_cluster.controldata.lc_ctype);
! pg_free(old_cluster.controldata.encoding);
! pg_free(new_cluster.controldata.encoding);
! pg_free(old_cluster.tablespace_suffix);
! pg_free(new_cluster.tablespace_suffix);
!
! if (log_opts.fd != NULL)
! {
fclose(log_opts.fd);
- log_opts.fd = NULL;
- }
if (log_opts.debug_fd)
fclose(log_opts.debug_fd);
--- 425,434
static void
cleanup(void)
{
char filename[MAXPGPATH];
! if (log_opts.fd)
fclose(log_opts.fd);
if (log_opts.debug_fd)
fclose(log_opts.debug_fd);
diff --git a/contrib/pg_upgrade/pg_upgrade.h b/contrib/pg_upgrade/pg_upgrade.h
index 598625b..4461952 100644
*** a/contrib/pg_upgrade/pg_upgrade.h
--- b/contrib/pg_upgrade/pg_upgrade.h
*** void check_loadable_libraries(void);
*** 326,332
/* info.c */
- void initialize_cluster_info(ClusterInfo *cluster);
FileNameMap *gen_db_file_maps(DbInfo *old_db,
DbInfo *new_db, int *nmaps, const char *old_pgdata,
const char *new_pgdata);
--- 326,331
--
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] Fix corner case for binary upgrade: extension functions in pg_catalog.
Tom Lane writes: > Fix corner case for binary upgrade: extension functions in pg_catalog. Do we only want to care about functions here? What about the following? CREATE EXTENSION hstore WITH SCHEMA pg_catalog; When not doing binary upgrade, this will issue the right pg_dump command, but it seems to me that you're saying that binary upgrades in such a case would be a problem still. > Normally, pg_dump summarily excludes functions in pg_catalog from > consideration. However, some extensions may create functions in pg_catalog > (adminpack already does that, and extensions for procedural languages will > likely do it too). In binary-upgrade mode, we have to dump such functions, > or the extension will be incomplete after upgrading. Per experimentation > with adminpack. > > * [DBH] src/bin/pg_dump/pg_dump.c Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et 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] Debian readline/libedit breakage
On mån, 2011-02-14 at 15:01 +0200, Devrim GÜNDÜZ wrote: > On Mon, 2011-02-14 at 13:52 +0100, Cédric Villemain wrote: > > "Consider providing debian packages at debian.postgresql.org" > > apt.postgresql.org, please. :) APT is not necessarily tied to Debian, nor is a Debian package repository necessarily tied to APT. -- 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] contrib loose ends: 9.0 to 9.1 incompatibilities
Tom Lane writes: > Well, actually, we *do* have such a mechanism (plpgsql), we just don't > want to use it unless we have to. I wouldn't feel too bad about saying > "upgrading tsearch2 directly from 9.0 to 9.4 requires that you have > plpgsql installed when you issue the CREATE EXTENSION command". We will then need "build"-time requires (build-depends would say debian) so that the system knows what's needed to run the install or upgrade scripts. I've been thinking that's for 9.2, but maybe that would be a simpler fix for you here. Oh and it needs to be able to define plpgsql as such a dependency, so it will probably need to be an extension… Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et 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] Usability tweaks for extension commands
Tom Lane writes: > ERROR: version to install or update to must be different from old version > > On reflection it seems like this is overly paranoid, and it'd be more > useful if the ALTER just reported a NOTICE along the lines of "version > so-and-so is already installed". Any objections? I see that's too late, but FWIW, +1 :) > Another thought is that it'd probably be useful for there to be a > "CREATE OR REPLACE EXTENSION" syntax, with the behavior of "install the > extension if it's not present, else make sure it's of the specified or > default version"; this behavior parallels CREATE OR REPLACE LANGUAGE > which is something we've been refining for awhile. I am not however > entirely sure what to do with the SCHEMA option if the extension already > exists --- we might be able to do SET SCHEMA, but perhaps that's too > aggressive. > > Thoughts? By all means, let's learn from our history. +1. I would expect CORE to be able to change things in the database, so I would vote for doing the SET SCHEMA here if needed. But if we do that, then certainly we should also automatically handle upgrades too when possible, right? That would be very useful, so still +1. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et 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] using a lot of maintenance_work_mem
On mån, 2011-02-14 at 10:11 -0500, Tom Lane wrote: > But before expending time on that, I'd want to see some evidence that > it's actually helpful for production situations. I'm a bit dubious > that you're going to gain much here. If you want to build an index on a 500GB table and you have 1TB RAM, then being able to use >>1GB maintenance_work_mem can only be good, no? -- 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] Add support for logging the current role
On Tue, Feb 15, 2011 at 1:02 PM, Stephen Frost wrote: > * Andrew Dunstan (and...@dunslane.net) wrote: >> On 02/15/2011 11:13 AM, Stephen Frost wrote: >> >Think I suggested that at one point. I'm all for doing that on a major >> >version change like this one, but I think we already had some concerns >> >about that on this thread (Andrew maybe?). >> >> I could live with it for a release if I thought we had a clear path >> ahead, but I think there are some design issues that we need to >> think about before we start providing for header lines and variable >> formats in CSV logs, particularly w.r.t. log rotation etc. So I'm >> slightly nervous about going ahead with this right now. > > I believe the suggestion that Robert and I were talking about above was > to just unilatterally change the CSV log file output format to include > current_role. No header lines, no variable output format, etc. > > I do think we can make header lines and variable output work, if we can > get agreement on what the semantics should be. I think we're back to not having a consensus on a reasonable way to proceed here. Let's take this up again for 9.2. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] btree_gist (was: CommitFest progress - or lack thereof)
On Sat, Feb 12, 2011 at 8:19 AM, Robert Haas wrote: > On Sat, Feb 12, 2011 at 7:47 AM, Stephen Frost wrote: >> Oleg, >> >> * Oleg Bartunov (o...@sai.msu.su) wrote: >>> what do you need for documentation ? From users point of view we add just >>> knn support and all examples are available in btree_gist.sql and sql >>> subdirectory. Contact me directly, if you have questions. >> >> It sure seems like >> http://www.postgresql.org/docs/9.0/static/btree-gist.html could be and >> should be improved, in general.. If this module is really still just a >> test bed for GiST, then perhaps it's not a big deal.. > > I agree that the documentation there could be a lot better, but I > don't think that's a commit-blocker for this patch. However, "us > reaching beta" will be a commit-blocker. Teodor, are you intending to commit this? If so, it needs to be soon. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] contrib loose ends: 9.0 to 9.1 incompatibilities
Dimitri Fontaine writes: > Tom Lane writes: >> Well, actually, we *do* have such a mechanism (plpgsql), we just don't >> want to use it unless we have to. I wouldn't feel too bad about saying >> "upgrading tsearch2 directly from 9.0 to 9.4 requires that you have >> plpgsql installed when you issue the CREATE EXTENSION command". > We will then need "build"-time requires (build-depends would say debian) > so that the system knows what's needed to run the install or upgrade > scripts. Huh? It's still an install-time dependency, and anyway the failure would be pretty obvious. Please let us not spend time garnishing this facility with unnecessary stuff, when the list of actually *important* missing stuff is still a mile long. Think about what's needed to support procedural languages as extensions, for starters. I'll give you a hint: none of it has anything whatever to do with copying features from RPM or Debian. 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] pika failing since the per-column collation patch
Le 14 févr. 2011 à 19:27, Rémi Zara a écrit : > > Le 12 févr. 2011 à 18:51, Peter Eisentraut a écrit : > >> >> It's only failing on this one machine, but there isn't anything >> platform-specific in this code, so I'd look for memory management faults >> on the code or a compiler problem. Try with lower optimization for a >> start. >> > > > Same failure with -O0 (and more shared memory). > Hi, Without me changing anything (still at -O0), the same error occurred but at the installCheck step, rather than the check step (which passed) Anything else to try ? Regards, Rémi Zara -- 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] contrib loose ends: 9.0 to 9.1 incompatibilities
On Feb 16, 2011, at 1:20 PM, Dimitri Fontaine wrote: > We will then need "build"-time requires (build-depends would say debian) > so that the system knows what's needed to run the install or upgrade > scripts. I've been thinking that's for 9.2, but maybe that would be a > simpler fix for you here. > > Oh and it needs to be able to define plpgsql as such a dependency, so it > will probably need to be an extension… With a version number… David -- 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] tsearch Parser Hacking
On Feb 14, 2011, at 11:44 PM, Oleg Bartunov wrote: >> IMO, sooner or later we need to trash that code and replace it with >> something a bit more modification-friendly. > > We thought about configurable parser, but AFAIR, we didn't get any support > for this at that time. What would it take to change the requirement such that *any* SQL function could be a parser, not only C functions? Maybe require that they turn a nested array of tokens? That way I could just write a function in PL/Perl quite easily. Best, David -- 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] arrays as pl/perl input arguments [PATCH]
I cleaned up the patch a bit -- result is v11, attached. I'll give it another look tomorrow and hopefully commit it. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support pg_to_perl_arrays_v11.patch.gz Description: GNU Zip compressed data -- 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] Add support for logging the current role
On 02/16/2011 04:24 PM, Robert Haas wrote: On Tue, Feb 15, 2011 at 1:02 PM, Stephen Frost wrote: * Andrew Dunstan (and...@dunslane.net) wrote: On 02/15/2011 11:13 AM, Stephen Frost wrote: Think I suggested that at one point. I'm all for doing that on a major version change like this one, but I think we already had some concerns about that on this thread (Andrew maybe?). I could live with it for a release if I thought we had a clear path ahead, but I think there are some design issues that we need to think about before we start providing for header lines and variable formats in CSV logs, particularly w.r.t. log rotation etc. So I'm slightly nervous about going ahead with this right now. I believe the suggestion that Robert and I were talking about above was to just unilatterally change the CSV log file output format to include current_role. No header lines, no variable output format, etc. I do think we can make header lines and variable output work, if we can get agreement on what the semantics should be. I think we're back to not having a consensus on a reasonable way to proceed here. Let's take this up again for 9.2. That's up to you. I can certainly live with what is suggested in Stephen's penultimate para above. 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] arrays as pl/perl input arguments [PATCH]
On 02/16/2011 05:54 PM, Alvaro Herrera wrote: I cleaned up the patch a bit -- result is v11, attached. I'll give it another look tomorrow and hopefully commit it. Thanks for picking this up. 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] Usability tweaks for extension commands
Dimitri Fontaine writes: > Tom Lane writes: >> Another thought is that it'd probably be useful for there to be a >> "CREATE OR REPLACE EXTENSION" syntax, with the behavior of "install the >> extension if it's not present, else make sure it's of the specified or >> default version"; this behavior parallels CREATE OR REPLACE LANGUAGE >> which is something we've been refining for awhile. I am not however >> entirely sure what to do with the SCHEMA option if the extension already >> exists --- we might be able to do SET SCHEMA, but perhaps that's too >> aggressive. > By all means, let's learn from our history. +1. > I would expect CORE to be able to change things in the database, so I > would vote for doing the SET SCHEMA here if needed. But if we do that, > then certainly we should also automatically handle upgrades too when > possible, right? That would be very useful, so still +1. According to our prior discussions of C.O.R. commands, the general principle that such a command ought to follow is that upon success, the object exists with exactly the properties implied by the command's arguments. So (1) if the extension isn't in the stated or default schema, we must move it there, or report failure if we can't; (2) if it's not of the stated or default version, we must update to that version, or fail if we can't. That seems straightforward enough, I'm just wondering whether applying that theory is leading to the right choices here. In particular, the default behavior if you didn't say "SCHEMA something" would be to automatically move the extension into whatever random schema happens to be the front of your search_path, which might well not be what you intended. Maybe it would be safer to not do a move on the basis of a defaulted schema selection. Anyway, I think this is all 9.2 material. I brought it up when I was wondering if there were a chance of making CREATE LANGUAGE translate into a CREATE EXTENSION operation for 9.1. I've since given that up, after realizing that we are nowhere near the point where we'd be able to allow non-superusers to execute CREATE EXTENSION. The permissions and security implications are too complicated to rush through. 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] Fix for Index Advisor related hooks
On Wed, Feb 16, 2011 at 10:26 AM, Tom Lane wrote:
> Gurjeet Singh writes:
> > BTW, you use the term 'fictitious' in the comments, would it be
> better
> > to standardize the term used for such an index? So either the comment
> would
> > be changed to call it hypothetical, or the structure member would be
> changed
> > to isfictitious.
>
> Yeah, hypothetical is the more-established term I think.
>
Please find the patch attached.
Regards,
--
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com
singh.gurjeet@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet
Mail sent from my BlackLaptop device
diff --git a/src/backend/utils/adt/selfuncs.c b/src/backend/utils/adt/selfuncs.c
index b3299b5..241f31c 100644
--- a/src/backend/utils/adt/selfuncs.c
+++ b/src/backend/utils/adt/selfuncs.c
@@ -4562,10 +4562,10 @@ get_actual_variable_range(PlannerInfo *root, VariableStatData *vardata,
continue;
/*
- * The index list might include fictitious indexes inserted by a
+ * The index list might include hypothetical indexes inserted by a
* get_relation_info hook --- don't try to access them.
*/
- if (!OidIsValid(index->indexoid))
+ if (index->ishypothetical)
continue;
/*
diff --git a/src/include/nodes/relation.h b/src/include/nodes/relation.h
index 49ce441..ec51b34 100644
--- a/src/include/nodes/relation.h
+++ b/src/include/nodes/relation.h
@@ -469,6 +469,7 @@ typedef struct IndexOptInfo
bool predOK; /* true if predicate matches query */
bool unique; /* true if a unique index */
+ bool ishypothetical; /* true if this index does not exist in pg_index */
bool amcanorderbyop; /* does AM support order by operator result? */
bool amoptionalkey; /* can query omit key for the first column? */
bool amsearchnulls; /* can AM search for NULL/NOT NULL entries? */
--
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] Extensions vs PGXS' MODULE_PATHNAME handling
Dimitri Fontaine writes: > Tom Lane writes: >> [ scratches head ... ] Why is your version generating so many >> unnecessary @extschema@ uses? > I just ran create table tomlist as select your query and create table > dimlist as select my query, then: > ... > No difference on @extschema@ use here. Well, when I did it I only got @extschema@ uses in tsearch2 (see the committed update scripts), so there's *something* different about what you're doing. I'm unsure what. 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] Fix corner case for binary upgrade: extension functions in pg_catalog.
Dimitri Fontaine writes: > Tom Lane writes: >> Fix corner case for binary upgrade: extension functions in pg_catalog. > Do we only want to care about functions here? Yes. Functions/aggregates are the only object type where pg_dump tries to suppress fetching any information at all about system-owned objects; it's the only case where there's so many system objects as to be worth the trouble. 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] SSI bug?
YAMAMOTO Takashi wrote: > might be unrelated to the loop problem, but... > > i got the following SEGV when runnning vacuum on a table. > vacuum on the table succeeded with the attached patch. Thanks! I appreciate the heavy testing and excellent diagnostics. On the face of it, this doesn't look related to the other problem, but I'll post again soon after closer review. -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] Usability tweaks for extension commands
On Feb 16, 2011, at 3:00 PM, Tom Lane wrote: > According to our prior discussions of C.O.R. commands, the general > principle that such a command ought to follow is that upon success, > the object exists with exactly the properties implied by the command's > arguments. So (1) if the extension isn't in the stated or default > schema, we must move it there, or report failure if we can't; > (2) if it's not of the stated or default version, we must update to that > version, or fail if we can't. That seems straightforward enough, > I'm just wondering whether applying that theory is leading to the > right choices here. In particular, the default behavior if you didn't > say "SCHEMA something" would be to automatically move the extension > into whatever random schema happens to be the front of your search_path, > which might well not be what you intended. Maybe it would be safer to > not do a move on the basis of a defaulted schema selection. Would it not be put into the schema with which the extension was associated? > Anyway, I think this is all 9.2 material. I brought it up when I was > wondering if there were a chance of making CREATE LANGUAGE translate > into a CREATE EXTENSION operation for 9.1. I've since given that up, > after realizing that we are nowhere near the point where we'd be able > to allow non-superusers to execute CREATE EXTENSION. The permissions > and security implications are too complicated to rush through. For the PGXN client, I was planning to allow, in addition to extension versions, one could specify that a version of PostgreSQL itself be a prerequisite, as well as any PL or core extension. I was just going to rely on PostgreSQL release version numbers for all of these. That way, one could specify that pl/pgsql is required in build_requires, for example, to make sure it's there for updates. Does that make sense? Best, David -- 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] Determining period between 2 dates
On 02/16/2011 09:07 AM, Marti Raudsepp wrote:
On Wed, Feb 16, 2011 at 18:03, Thom Brown wrote:
For the number of fortnights, that becomes:
select extract(epoch from now() - '2010-01-01 11:45:13'::timestamp)/60/60/24/14;
You'd think with PostgreSQL having such a rich type system, it
wouldn't need to come to that. It's just asking for the number of
intervals between 2 timestamps rather than the number of seconds and
dividing it to the point you get your answer.
I think a good generic solution would be an interval/interval operator
that returns numeric. Then the above becomes:
SELECT (now() - timestamp '2010-01-01 11:45:13') / interval '2 weeks';
However, looking at the code, it's not so obvious what to do if the
intervals contain months.
Regards,
Marti
Actually, what I would really like is an option in the to_char format
that would display an interval using an arbitrary combination of units.
For instance, right now I can display parts of an interval:
steve=# select to_char('10d 11h 21m 3s'::interval, 'DD');
to_char
-
10
steve=# select to_char('10d 11h 21m 3s'::interval, 'SS');
to_char
-
03
steve=# select to_char('10d 11h 21m 3s'::interval, 'MI');
to_char
-
21
But those formats extract portions of the interval. I would like to be
able to display the *entire* interval filling the largest portions first
and continuing to smaller units, say:
select to_char('10d 11h 21m 3s'::interval, 'XM SS');
to_char
904863
or
select to_char('10d 11h 21m 3s'::interval, 'XM MI:SS');
to_char
15081:03
And as long as I'm on the subject, decimal time display would be handy
as well (especially decimal hours and minutes).
The use case is anything that accumulates time - especially for billing
purposes: 2.4 hours for the attorney, 11434.8 minutes of long-distance
this month, etc.
I can write these myself, of course, but built-in would be nice.
-Steve
--
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] Debian readline/libedit breakage
Andrew Dunstan writes: > On 02/16/2011 12:29 PM, Bruce Momjian wrote: >> Can someone take ownership of this, get involved with the libedit folks, >> get Debian to use their fixes, and solve this problem for us? > You're assuming a fact not in evidence, namely the existence of an > identifiable group of "libedit folks". Last time I looked there was no > such group. FWIW, we are not the only people who are unhappy with the readline license situation. There has been muttering on the Fedora lists about trying to push libedit to the point where it'd be a usable drop-in replacement, even as recently as last week: http://lists.fedoraproject.org/pipermail/devel/2011-February/148473.html I'm not sure how much manpower is likely to emerge from that quarter, but it seems at least possible that something will get done without us having to do it. In the meantime, if there's anybody here who feels their talents are more suited to fixing libedit than to hacking Postgres, I encourage them to do so. But I don't think it's this project's charter to fix that problem. 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] Fix for Index Advisor related hooks
Gurjeet Singh writes: > On Wed, Feb 16, 2011 at 10:25 AM, Tom Lane wrote: >> The only reason you'd need that code is if you were trying to construct >> a fake Relation structure, which seems unnecessary and undesirable. > The planner requires IndexOptInfo, and for the planner to choose the > hypothetical index we need to fill in the fwdsortop, revsortop, opfamily and > opcintype, and this is the information that IndexAdvisor populates using > IndexSupportInitialize() (at least until c0b5fac7 changed the function > signature. Yeah, and the set of stuff you need in IndexOptInfo changed again last week; see collations. Direct access to IndexSupportInitialize is even less useful today than it was a week ago. This stuff has changed many times before, and it will change again in the future, and exporting a private function that has an unrelated purpose is not going to insulate you from needing to deal with that. > What would be the best way to build an IndexOptInfo for a plain BTREE index > for different data types? Fetch the values you need and stuff 'em in the struct. Don't expect relcache to do it for you. The only reason relcache is involved in the current workflow is that we try to cache the information across queries in order to save on planner startup time ... but I don't think that that concern is nearly as pressing for something like Index Advisor. You'll have enough to do tracking changes in IndexOptInfo, you don't need to have to deal with refactorings inside relcache as well. 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] Debian readline/libedit breakage
Andrew Dunstan wrote: You're assuming a fact not in evidence, namely the existence of an identifiable group of "libedit folks". Last time I looked there was no such group. There appear to be two people working periodically on the upstream NetBSD libedit: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/?sortby=date And a third who periodically packages that at http://www.thrysoee.dk/editline/ Those are the group as far as I can tell. It's not encouraging that the Debian issue with libedit+UTF8 has been documented for almost year a now: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579729 (And we shouldn't assume that GnuTLS is the right replacement for OpenSSL either, BTW). The idea of using NSS instead is an interesting one. Looking at http://en.wikipedia.org/w/index.php?title=Comparison_of_TLS_Implementations it does seem to match the basic feature set of OpenSSL. And the nss_compat_ossl compatibility layer might be useful: http://fedoraproject.org/wiki/Nss_compat_ossl I find it hard to get excited about working to replace the software that has a reasonable license here (readline) rather than trying to eliminate dependence on the one with an unreasonable license (OpenSSL). -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books -- 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] Add support for logging the current role
On Wed, Feb 16, 2011 at 5:55 PM, Andrew Dunstan wrote: > On 02/16/2011 04:24 PM, Robert Haas wrote: >> >> On Tue, Feb 15, 2011 at 1:02 PM, Stephen Frost wrote: >>> >>> * Andrew Dunstan (and...@dunslane.net) wrote: On 02/15/2011 11:13 AM, Stephen Frost wrote: > > Think I suggested that at one point. I'm all for doing that on a major > version change like this one, but I think we already had some concerns > about that on this thread (Andrew maybe?). I could live with it for a release if I thought we had a clear path ahead, but I think there are some design issues that we need to think about before we start providing for header lines and variable formats in CSV logs, particularly w.r.t. log rotation etc. So I'm slightly nervous about going ahead with this right now. >>> >>> I believe the suggestion that Robert and I were talking about above was >>> to just unilatterally change the CSV log file output format to include >>> current_role. No header lines, no variable output format, etc. >>> >>> I do think we can make header lines and variable output work, if we can >>> get agreement on what the semantics should be. >> >> I think we're back to not having a consensus on a reasonable way to >> proceed here. Let's take this up again for 9.2. >> > > That's up to you. I can certainly live with what is suggested in Stephen's > penultimate para above. OK. If no one objects further, Stephen and I will make that happen. Otherwise: he's dead, Jim. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
On 17/02/11 04:23, Tom Lane wrote: > Florian Pflug writes: >> Hm, I've browsed through the code and it seems that the current behaviour >> was implemented on purpose. > > Yes, it's 100% intentional. The idea is to allow function authors to > use OUT-parameter notation (in particular, the convention of assigning > to a named variable to set the result) without forcing them into the > overhead of returning a record when all they want is to return a scalar. > So a single OUT parameter is *supposed* to work just like a function > that does "returns whatever" without any OUT parameters. > > Even if you think this was a bad choice, which I don't, it's far too > late to change it. Any suggestions about how the JDBC driver can express the query to get the behavior that it wants? Specifically, the driver wants to call a particular function with N OUT or INOUT parameters (and maybe some other IN parameters too) and get a resultset with N columns back. The current approach is to say "SELECT * FROM f(params) AS RESULT" which works in all cases *except* for the case where there is exactly one OUT parameter and it has a record/UDT type. Oliver -- 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] Fix for Index Advisor related hooks
Gurjeet Singh writes: > On Wed, Feb 16, 2011 at 10:26 AM, Tom Lane wrote: >> Yeah, hypothetical is the more-established term I think. > Please find the patch attached. Applied with minor adjustments to HEAD and 9.0. 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] Debian readline/libedit breakage
On Thu, Feb 17, 2011 at 12:07 AM, Greg Smith wrote: > There appear to be two people working periodically on the upstream NetBSD > libedit: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/?sortby=date > > And a third who periodically packages that at http://www.thrysoee.dk/editline/ I'm really confused between libedit and libeditline. They both appear to be in Debian and I think they both trace their lineage to the original BSD library. Was one the NetBSD maintained one and the other the "upstream"? > I find it hard to get excited about working to replace the software that has > a reasonable license here (readline) rather than trying to eliminate > dependence on the one with an unreasonable license (OpenSSL). Personally I find there are plenty of technical reasons to run screaming from OpenSSL anyways. -- greg -- 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] Debian readline/libedit breakage
On Thu, 2011-02-17 at 00:28 +, Greg Stark wrote: > On Thu, Feb 17, 2011 at 12:07 AM, Greg Smith wrote: > > > There appear to be two people working periodically on the upstream NetBSD > > libedit: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/?sortby=date > > > > And a third who periodically packages that at > > http://www.thrysoee.dk/editline/ > > I'm really confused between libedit and libeditline. They both appear > to be in Debian and I think they both trace their lineage to the > original BSD library. Was one the NetBSD maintained one and the other > the "upstream"? > > > I find it hard to get excited about working to replace the software that has > > a reasonable license here (readline) rather than trying to eliminate > > dependence on the one with an unreasonable license (OpenSSL). > > Personally I find there are plenty of technical reasons to run > screaming from OpenSSL anyways. > Maybe we really should consider moving to NSS insread? http://www.mozilla.org/projects/security/pki/nss/ If it solves the license problem, it is well supported etc.. JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- 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] Debian readline/libedit breakage
Greg Smith writes: > I find it hard to get excited about working to replace the software that > has a reasonable license here (readline) rather than trying to eliminate > dependence on the one with an unreasonable license (OpenSSL). Hm? The trouble with readline is that it's GPL, not LGPL, and the former is actually *not* a reasonable license for a library. At least not for one that isn't trying to be viral. There's room for argument about whether dynamic linking exempts applications from the scope of the license, but in the end it would be cleanest from a licensing standpoint if we weren't using readline. The OpenSSL license is BSD-with-advertising, which is obnoxious in some respects but it isn't trying to force other people to change the license on their code. In particular, getting rid of use of OpenSSL would not be sufficient to satisfy the most rabid GPL partisans that we were in compliance. Whereas, if we get rid of readline, it no longer matters whether we depend on OpenSSL. 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] Add support for logging the current role
Robert Haas writes: >>> On Tue, Feb 15, 2011 at 1:02 PM, Stephen Frost wrote: I believe the suggestion that Robert and I were talking about above was to just unilatterally change the CSV log file output format to include current_role. No header lines, no variable output format, etc. > OK. If no one objects further, Stephen and I will make that happen. > Otherwise: he's dead, Jim. I can't remember at the moment: have we changed the CSV format in any releases since it was first created? And if so, did anyone complain? If there's precedent showing this isn't going to be a problem for CSV users, I won't object. Otherwise I think that we should try to have just one flag day for them, not two. 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] Fix for Index Advisor related hooks
On 16 February 2011 23:02, Gurjeet Singh wrote: > On Wed, Feb 16, 2011 at 10:26 AM, Tom Lane wrote: >> >> Gurjeet Singh writes: >> > BTW, you use the term 'fictitious' in the comments, would it be >> > better >> > to standardize the term used for such an index? So either the comment >> > would >> > be changed to call it hypothetical, or the structure member would be >> > changed >> > to isfictitious. >> >> Yeah, hypothetical is the more-established term I think. > > Please find the patch attached. For my benefit, could you explain how ishypothetical gets set to true? -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 -- 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] Fix for Index Advisor related hooks
Thom Brown writes: > For my benefit, could you explain how ishypothetical gets set to true? In the core, it never does. An index advisor plugin would set it in IndexOptInfo structs that it makes. 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] Fix for Index Advisor related hooks
On 17 February 2011 00:48, Tom Lane wrote: > Thom Brown writes: >> For my benefit, could you explain how ishypothetical gets set to true? > > In the core, it never does. An index advisor plugin would set it in > IndexOptInfo structs that it makes. I get the idea. Thanks Tom. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 -- 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] Debian readline/libedit breakage
Greg Stark writes: > On Thu, Feb 17, 2011 at 12:07 AM, Greg Smith wrote: >> There appear to be two people working periodically on the upstream NetBSD >> libedit: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/?sortby=date >> >> And a third who periodically packages that at >> http://www.thrysoee.dk/editline/ > I'm really confused between libedit and libeditline. They both appear > to be in Debian and I think they both trace their lineage to the > original BSD library. Was one the NetBSD maintained one and the other > the "upstream"? The one in Fedora/RHEL and the one in Mac OSX both definitely consider NetBSD to be the active upstream. Dunno where Debian's other version comes from. 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] Debian readline/libedit breakage
On Thu, Feb 17, 2011 at 2:39 AM, Tom Lane wrote: > Greg Smith writes: >> I find it hard to get excited about working to replace the software that >> has a reasonable license here (readline) rather than trying to eliminate >> dependence on the one with an unreasonable license (OpenSSL). > > Hm? > > The trouble with readline is that it's GPL, not LGPL, and the former is > actually *not* a reasonable license for a library. At least not for one > that isn't trying to be viral. There's room for argument about whether > dynamic linking exempts applications from the scope of the license, but > in the end it would be cleanest from a licensing standpoint if we > weren't using readline. Using libedit would fix the problem for 'psql', but ... > The OpenSSL license is BSD-with-advertising, > which is obnoxious in some respects but it isn't trying to force other > people to change the license on their code. ... you are forgetting all the GPL apps that link with libpq. They either need to use non-SSL libpq or add OpenSSL exception to their license (to have 100% feel-good licensing). Just pointing out that OpenSSL does not smell like roses... -- 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] Fix for Index Advisor related hooks
On Wed, Feb 16, 2011 at 7:25 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > On Wed, Feb 16, 2011 at 10:26 AM, Tom Lane wrote:
> >> Yeah, hypothetical is the more-established term I think.
>
> > Please find the patch attached.
>
> Applied with minor adjustments to HEAD and 9.0.
>
Thanks Tom.
--
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com
singh.gurjeet@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet
Mail sent from my BlackLaptop device
Re: [HACKERS] Debian readline/libedit breakage
On Thu, Feb 17, 2011 at 12:39 AM, Tom Lane wrote: > In particular, getting rid of use of OpenSSL would not be sufficient > to satisfy the most rabid GPL partisans that we were in compliance. Huh? In what way would we not be in compliance? Or rather, what part of the GPL would we be unable to comply with for distributing binaries? I think what you're getting at is that distributing source which can optionally link against GPL code might itself be a derivative work of the GPL code and need to be distributed under the GPL even if it's not built against it. I think that's just a straw man though, even the most ardent GPL partisan isn't going to claim that the Postgres source is a derivative work of readline because it has the option to link against readline for additional incidental functionality. To give context the case where this comes up are things like Gimp plugins *which are useless with thout the GIMP*. They're entirely dependent on the Gimp for their functionality. Claiming they're derivative works of the Gimp is a lot easier than claiming that Postgres is a derivative work of readline. A more borderline case was programs based on GMP. However even there it's hard to picture a useful program which needs GMP being able to do anything useful without GMP. Even then just providing a (much poorer) alternative implementation makes the case fall apart. > Whereas, if we get rid of readline, it no longer matters whether we > depend on OpenSSL. Not really, people still need to abide by the OpenSSL license rules which make our product less useful and less flexible. People might want to include Postgres in a product which uses other GPL'd code or which they don't want to alter their advertising. -- greg -- 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] Add support for logging the current role
On Wed, Feb 16, 2011 at 7:42 PM, Tom Lane wrote: > Robert Haas writes: On Tue, Feb 15, 2011 at 1:02 PM, Stephen Frost wrote: > I believe the suggestion that Robert and I were talking about above was > to just unilatterally change the CSV log file output format to include > current_role. No header lines, no variable output format, etc. > >> OK. If no one objects further, Stephen and I will make that happen. >> Otherwise: he's dead, Jim. > > I can't remember at the moment: have we changed the CSV format in any > releases since it was first created? And if so, did anyone complain? > > If there's precedent showing this isn't going to be a problem for CSV > users, I won't object. Otherwise I think that we should try to have > just one flag day for them, not two. CSV log files were introduced in 8.3.0 by commit fd801f4faa8e0f00bc314b16549e3d8e8aa1b653. There are several follow-on commits making adjustments, but they all appear to be 8.3-vintage: 230e8962f3a47cae4729ad7c017410d28caf1370 3bf66d6f1c3a8d266c3e6ed939e763a001179faf 77c166ba6cf6fe8f7e9737b7fe1793d886dd5cf8 -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Add support for logging the current role
* Tom Lane (t...@sss.pgh.pa.us) wrote: > I can't remember at the moment: have we changed the CSV format in any > releases since it was first created? And if so, did anyone complain? It was changed between 8.4 and 9.0 (application_name was added). I've looked around a bit in the archives w/ google and havn't found a single complaint. Perhaps google is failing me, but it seems this isn't too bad. We've had CSV log output since 8.3, for reference, so it was unchanged 8.3 -> 8.4, then changed between 8.4 -> 9.0. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Add support for logging the current role
On 02/16/2011 08:38 PM, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: I can't remember at the moment: have we changed the CSV format in any releases since it was first created? And if so, did anyone complain? It was changed between 8.4 and 9.0 (application_name was added). I've looked around a bit in the archives w/ google and havn't found a single complaint. Perhaps google is failing me, but it seems this isn't too bad. We've had CSV log output since 8.3, for reference, so it was unchanged 8.3 -> 8.4, then changed between 8.4 -> 9.0. Frankly, compared with other issues that we've sometimes inflicted on people upgrading, this one strikes me as fairly low grade. 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] Debian readline/libedit breakage
* Tom Lane (t...@sss.pgh.pa.us) wrote: > In particular, getting rid of use of OpenSSL would not be sufficient > to satisfy the most rabid GPL partisans that we were in compliance. I've never heard anyone argue that position, don't believe anyone would, and certainly don't agree with it. > Whereas, if we get rid of readline, it no longer matters whether we > depend on OpenSSL. I agree w/ the other responses to this, in particular from Stark, but I just wanted to point out that we're much more likely to come across other GPL-licensed things that we want to support linking against (and who might link against us..) than OpenSSL-type-licensed things.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Add support for logging the current role
* Robert Haas (robertmh...@gmail.com) wrote: > CSV log files were introduced in 8.3.0 by commit > fd801f4faa8e0f00bc314b16549e3d8e8aa1b653. There are several follow-on > commits making adjustments, but they all appear to be 8.3-vintage: > > 230e8962f3a47cae4729ad7c017410d28caf1370 > 3bf66d6f1c3a8d266c3e6ed939e763a001179faf > 77c166ba6cf6fe8f7e9737b7fe1793d886dd5cf8 This list appears to miss out on 8217cfbd991856d25d73b0f7afcf43d99f90b653 ..? Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] log_hostname and pg_stat_activity
On Thu, Feb 10, 2011 at 10:40 AM, Steve Singer wrote: > On 11-02-10 10:32 AM, Robert Haas wrote: >> I was assuming those changes were sufficiently trivial that they could >> be made at commit-time, especially if Peter is committing it himself. >> Of course if he'd like a re-review, he can always post an updated >> patch, but I just thought that was overly pedantic in this particular >> case. > > Sounds reasonable. I rebased this patch, wrote documentation, and fixed BackendStatusShmemSize. PFA. On further review, I'm inclined to go with Peter's original approach to displaying the hostname: show it if we have it, and don't if we don't. It's not that hard to document the relevant criteria, and it seems silly to suppress the information if we have it. I had a thought of declaring st_clienthostname as char st_clienthostname[NAMEDATALEN] rather than char *st_clienthostname. That would simplify the initialization code. But I believe that the protocol used for updating this data structure is unsafe unless the whole thing fits into a single cache line. I'm not positive that's going to be true on every architecture even as things stand. On my Mac, with this patch, it's 208 bytes (which means that it's presumably 200 without the patch, and that it would be 264 with the alternate approach proposed above). According to that font of knowledge, Wikipedia, the size of a cache line can vary from 8 to 512 bytes [citation needed]. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Debian readline/libedit breakage
On Wed, 2011-02-16 at 20:53 -0500, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > In particular, getting rid of use of OpenSSL would not be sufficient > > to satisfy the most rabid GPL partisans that we were in compliance. > > I've never heard anyone argue that position, don't believe anyone would, > and certainly don't agree with it. Yeah I am not sure I can buy Tom's argument here. The GPL is fairly clear and is compatible with the BSD/Postgres license. JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
