Re: [HACKERS] forming tuple as an attribute inside another tuple in c function
OK but what is the recommended way to get TupleDesc for p_type? I am aware
of RelationNameGetTupleDesc but I shouldn't use it since it is deprecated.
However by using it the code would look something like this (I tested it and
it works as expected):
Datum demo(PG_FUNCTION_ARGS) {
float8 xi = 1;
float8 yi = 2;
float8 xe = 3;
float8 ye = 4;
int32 id = 1;
bool isnull;
TupleDesc tupdesc;
TupleDesc tupdesc_p;
Datum values[3];
Datum vi[2];
Datum ve[2];
HeapTuple tuple;
HeapTuple i;
HeapTuple e;
tupdesc_p = *RelationNameGetTupleDesc*("p_type");
vi[0] = Float8GetDatum(xi);
vi[1] = Float8GetDatum(yi);
i = heap_form_tuple(tupdesc_p, vi, &isnull);
ve[0] = Float8GetDatum(xe);
ve[1] = Float8GetDatum(ye);
e = heap_form_tuple(tupdesc_p, ve, &isnull);
if (get_call_result_type(fcinfo, NULL, &tupdesc) != TYPEFUNC_COMPOSITE)
{
ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("function returning record called in context that cannot accept type
record")));
}
BlessTupleDesc(tupdesc);
* * values[0] = HeapTupleGetDatum(i);
values[1] = HeapTupleGetDatum(e);
values[2] = Int32GetDatum(id);
tuple = heap_form_tuple(tupdesc, values, &isnull);
PG_RETURN_DATUM(HeapTupleGetDatum(tuple));
}
On Mon, Sep 27, 2010 at 3:32 AM, Tom Lane wrote:
> You've omitted to tell us just
> what's going wrong for you.
>
>regards, tom lane
>
Re: [HACKERS] recovery.conf location
On Mon, Sep 27, 2010 at 10:55 AM, Robert Haas wrote: > Again, I think the real question is how to handle values that need to > be maintained PER SLAVE from values of which there is only one copy. Yep. One idea is to support something like "pg_ctl standby" and "pg_ctl pitr". If we do so, we would be able to get rid of standby_mode from recovery.conf, and move the others to postgresql.conf or elsewhere. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch: SQL/MED(FDW) DDL
sorry for my slow response. (2010/09/24 21:13), Robert Haas wrote: This is a good point. On the one hand, I do agree that the API for simple things like processing CSV files shouldn't be overly complex. So perhaps we could start with a simple API and extend it later. On the other hand, understanding how some of the more complex cases ought to work provides insight into handling the simpler cases. So I think we should aim to have at least a sketch of a design for the whole feature, and then if in phase 1 we want to implement only the easier parts, that's OK. Right. In any case, I should clearify what this API could cover by this patch and what could not. # And also how far I and my collaborator can implement.. As Itagaki points out, we have two types of FDW implementations in progress: flat file wrapper and postgresql wrapper. these items are described in wiki: http://wiki.postgresql.org/wiki/SQL/MED But it may be hard to get what this fdw routines 'could' provide, so I and my collaborator is now summarizing these items to discuss and ask for help. Anyway I think these items are needed to discuss further. - API design that is used in executor for a single external table. - simple FDW implements to clearfy what this API could provide. These items will be shown by my collaborator soon. thanks in advance, SAKAMOTO Masahiko NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center e-mail: sakamoto.masah...@oss.ntt.co.jp -- 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] recovery.conf location
On Mon, Sep 27, 2010 at 9:35 AM, Jaime Casanova wrote: > Maybe i'm missing something but this would be a problem if we put a > trigger file and the recovery.conf gets renamed to recovery.done, no? > at least that would be a problem for the standbys that still need to > be standbys That's not problem unless more than one standbys become master at the same time. Since recovery.conf is read by standby only at the start unless it's triggered, already-started standbys can work even if recovery.conf is renamed to recovery.done. Though it's somewhat tricky.. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO: You can alter it, but you can't view it
On Mon, Sep 27, 2010 at 2:19 PM, Josh Berkus wrote: > While working on some database maintenance, I was just tripped up by the > fact that there is no good way to query reloptions for tables. By "no good > way" I mean "no way which does not involve UNNEST and regexps or procedural > code". Can you use pg_options_to_table() for your purpose? =# CREATE TABLE tbl (i integer) with (fillfactor = 70); =# SELECT (pg_options_to_table(reloptions)).* FROM pg_class WHERE oid = 'tbl'::regclass; option_name | option_value -+-- fillfactor | 70 -- Itagaki Takahiro -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] TODO: You can alter it, but you can't view it
All, While working on some database maintenance, I was just tripped up by the fact that there is no good way to query reloptions for tables. By "no good way" I mean "no way which does not involve UNNEST and regexps or procedural code". This puts us in the wierd place that while one can ALTER various reloptions, one cannot check them to see if they *need* to be altered. That's a particularly bad situation given that changing reloptions requires a lock on the table (though less of one in 9.1). I propose that we have an additional system view, pg_class_reloptions (or pg_table_reloptions if reloptions aren't relevant for views and indexes). It would have the following columns: relid name setting_numeric setting_boolean setting_text comments/objections/something I missed in the internal functions or 9.1 patches which already does this? -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.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] security label support, revised
On Sat, Sep 25, 2010 at 7:04 AM, KaiGai Kohei wrote: > * The "dummy_esp" module and regression test for SECURITY LABEL statement. > This module allows only four labels: "unclassified", "classified", > "secret" and "top secret". The later two labels can be set by only > superusers. The new regression test uses this "dummy_esp" module to > find out future regression in SECURITY LABEL statement. > * A minimum description about external security provider at the tail > of Database Roles and Privileges chapter. > * Add pg_seclabels system view > * Revising pg_dump/pg_dumpall > - '--security-label' was replaced by '--no-security-label' > - implemented according to the manner in comments. > findSecLabels() and collectSecLabels() are added to reduce number of > SQL queries, in addition to dumpSecLabel(). Thanks, this looks like mostly good stuff. Here's a new version of the patch with some bug fixes, additional regression tests, and other cleanup. I think this is about ready to commit. I didn't adopt your documentation and I renamed your contrib module from dummy_esp to dummy_seclabel, but the rest I took more or less as you had it. For now, I don't want to use the term "external security provider" because that's not really what this provides - it just provides labels. I initially thought that an external security provider would really turn out to be a concept that was somewhat embedded in the system, but on further reflection I don't think that's the case. I think what we're going to end up with is a collection of hooks that might happen to be useful for security-related things, but not necessarily just those. Anyway, I feel that it's a bit premature to document too much about what this might do someday; the documentation already in the patch is adequate to explain what it does now. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company seclabel-v6.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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
David Christensen writes: > On Sep 26, 2010, at 2:24 PM, Tom Lane wrote: >> We could perhaps fix that if there were an inexpensive way to get the >> SHA1 of the master commit that each branch is sprouted from. > Particularly with PostgreSQL's linear branch history, `git merge-base` will > show you the point at which the branches diverged from master: > $ git merge-base origin/REL9_0_STABLE master > 1084f317702e1a039696ab8a37caf900e55ec8f2 Ah-hah, I figured there had to be some plumbing command that would get that. The current version of the script siphons the information off from git log --parents, but it'd likely be cleaner to do it with git merge-base. It might be a bit slower though --- some experimentation here says that git merge-base takes a bit of time, which isn't surprising if I'm right in guessing that it has to chase back from the two branch heads looking for a commit in common. That's going to basically duplicate work that git log has to do also. 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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
On Sep 26, 2010, at 2:24 PM, Tom Lane wrote: > I wrote: >> I think we could get that behavior fairly easily by remembering the last >> tag matching one of the commits on a branch, as we chase the branch >> backwards. > > I find that this works just fine for the branches, but not so well for > master, because more often than not the initial RELx_y_z tag is applied > on the release's branch and not on master. So for example commits on > master appear to jump from REL7_2 development to REL8_0 development, > because 7.3 and 7.4 have no release tag on the master branch. > > We could perhaps fix that if there were an inexpensive way to get the > SHA1 of the master commit that each branch is sprouted from. However, > I'm inclined to propose that we instead manually place a tag at each > sprout point. Any thoughts about that? In particular, what should > the naming convention for such tags be? I would have liked to use > RELx_y, but that's out because before 8.0 we named the initial > releases that way. Particularly with PostgreSQL's linear branch history, `git merge-base` will show you the point at which the branches diverged from master: $ git merge-base origin/REL9_0_STABLE master 1084f317702e1a039696ab8a37caf900e55ec8f2 $ git show 1084f317702e1a039696ab8a37caf900e55ec8f2 commit 1084f317702e1a039696ab8a37caf900e55ec8f2 Author: Marc G. Fournier Date: Fri Jul 9 02:43:12 2010 + tag beta3 Also, the `git describe` command can be used to identify the closest tag a specific commit is a part of: $ git describe --tags 6d297e0551a2a3cc048655796230cdff5e559952 REL9_0_BETA2-153-g6d297e0 This indicates that the indicated commit is the 153rd commit after the REL9_0_BETA2 tag (and includes the abbreviated SHA1 for unique identification in the case that there are multiple branches which have since been re-merged; not the case in this project, but still handy for uniqueness). The command `git branch --contains` will come in handy for commits which are the exact same content (ignoring the commit parentage and time and using only the patch-id (`git --help patch-id`)). This obviously won't catch commits where the changed content had to be modified in the back-patching process, but could serve as a quick basis. (In truth, this may be relatively useless, as I tried to find an example which included back-branches, but wasn't able to find an example off-hand.) In any case, the option exists... :-) $ git branch -a --contains 2314baef38248b31951d3c8e285e6f8e4fd7dd05 * master remotes/origin/HEAD -> origin/master remotes/origin/REL8_4_STABLE remotes/origin/REL8_5_ALPHA1_BRANCH remotes/origin/REL8_5_ALPHA2_BRANCH remotes/origin/REL8_5_ALPHA3_BRANCH remotes/origin/REL9_0_ALPHA4_BRANCH remotes/origin/REL9_0_ALPHA5_BRANCH remotes/origin/REL9_0_STABLE remotes/origin/master Regards, David -- David Christensen End Point Corporation da...@endpoint.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] Improving prep_buildtree used in VPATH builds
Attached is the patch that tries to speedup prep_buildtree script, which is
used in VPATH builds, from our configure script.
The idea is to ask `find` to emit directory listing in depth-first order so
that the `mkdir -p` will create the deepest directory first and any
subsequent `mkdir -p` on an intermediate directory will not have to do
anything.
Currently I am seeing a performance improvement of this script by only about
500 ms; say 11.8 seconds vs. 11.3 secs. But I remember distinctly that
yesterday I was able to see an improvement of 11% on the same virtual
machine, averaged on multiple runs; 42 sec vs 37 sec. It might be the case
that the host OS or my Linux virtual machine were loaded at that time and
the filesystem could not cache enough inodes.
Seems like it would improve performance in general, but more so under load
conditions when you actually need it. I am not sure if -depth option is
supported by all incarnations of 'find'.
I have been away from Postgres development for quite a while, so would
appreciate if someone could tell me if such a patch should be submitted for
commitfest (since this is not actually a source patch).
Regards,
--
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com
singh.gurj...@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet
Mail sent from my BlackLaptop device
prep_buildtree.patch
Description: Binary 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] recovery.conf location
On Sun, Sep 26, 2010 at 9:12 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, Sep 26, 2010 at 8:56 PM, Tom Lane wrote: >>> Yeah. The original design for recovery.conf envisioned that it has only >>> a short lifespan while you're doing an archive recovery. Putting >>> parameters for slave operation into it has contorted things beyond >>> recognition. I think we really need to take two steps back and >>> reconsider the whole "parameters" versus "status" distinction there. > >> Perhaps we should consider folding recovery.conf into postgresql.conf. > > To the extent that it carries long-lived parameters, that would be > sensible. I think there's also a status component to what it's doing > though. Also, if we're trying to put SR parameters somewhere other than > postgresql.conf, it might be better if the existing parameters migrated > there instead. Again, I think the real question is how to handle values that need to be maintained PER SLAVE from values of which there is only one copy. IMHO, whether or not it's related to HS/SR is not particularly interesting, or particularly well-defined. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres 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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
On Mon, Sep 27, 2010 at 3:20 AM, Robert Haas wrote:
> On Sun, Sep 26, 2010 at 9:14 PM, Gurjeet Singh
> wrote:
> > On Mon, Sep 27, 2010 at 3:03 AM, Robert Haas
> wrote:
> >>
> >> On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote:
> >> >
> >>
> >> I maintain that if someone else whacked around one of your commits the
> >> way you whacked this around, you'd bite their head off.
> >>
> >
> > :) Yes, he would. And you are not being any less forgiving either.
> >
> > #ilovepostgrescommunity
>
> I actually do love the PostgreSQL community, and I really enjoy
> working with Tom. This does not mean that we won't disagree about
> things some times, and I do put on my flame-retardant undergarments
> every time I sit down to read -hackers. That's OK. It's still an
> awesome community, and that is why I put the time and effort into it
> that I do (he writes at 9PM on a Sunday night).
>
>
Just to clarify my intentions, I wasn't trying to enjoy the disagreement,
nor trying to lablel it as or feed the flaming. Just trying to make a point
that here everyone is treated equal.
Regards,
--
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com
singh.gurj...@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet
Mail sent from my BlackLaptop device
Re: [HACKERS] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
On Sun, Sep 26, 2010 at 9:14 PM, Gurjeet Singh wrote: > On Mon, Sep 27, 2010 at 3:03 AM, Robert Haas wrote: >> >> On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote: >> > >> >> I maintain that if someone else whacked around one of your commits the >> way you whacked this around, you'd bite their head off. >> > > :) Yes, he would. And you are not being any less forgiving either. > > #ilovepostgrescommunity I actually do love the PostgreSQL community, and I really enjoy working with Tom. This does not mean that we won't disagree about things some times, and I do put on my flame-retardant undergarments every time I sit down to read -hackers. That's OK. It's still an awesome community, and that is why I put the time and effort into it that I do (he writes at 9PM on a Sunday night). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres 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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
On Mon, Sep 27, 2010 at 3:03 AM, Robert Haas wrote:
> On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote:
> >
>
> I maintain that if someone else whacked around one of your commits the
> way you whacked this around, you'd bite their head off.
>
>
:) Yes, he would. And you are not being any less forgiving either.
#ilovepostgrescommunity
--
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com
singh.gurj...@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet
Mail sent from my BlackLaptop device
Re: [HACKERS] recovery.conf location
Robert Haas writes: > On Sun, Sep 26, 2010 at 8:56 PM, Tom Lane wrote: >> Yeah. The original design for recovery.conf envisioned that it has only >> a short lifespan while you're doing an archive recovery. Putting >> parameters for slave operation into it has contorted things beyond >> recognition. I think we really need to take two steps back and >> reconsider the whole "parameters" versus "status" distinction there. > Perhaps we should consider folding recovery.conf into postgresql.conf. To the extent that it carries long-lived parameters, that would be sensible. I think there's also a status component to what it's doing though. Also, if we're trying to put SR parameters somewhere other than postgresql.conf, it might be better if the existing parameters migrated there instead. 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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
Robert Haas writes: > On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote: >> I looked at doing that but it didn't seem like an improvement. Take >> a look at the new version and see what you think. > I'm not really sure. I suppose I'll have to play with it for a while > to really form a clear opinion. Clearly, knowing which minor releases > a commit is in is a major improvement, but the whole thing is so > heavily re-engineered from my original version that I'm not really > sure whether there's anything else that I care about that got broken > in the process. In particular, I'm wondering to what extent we're > baking in branch management conventions from which we may wish to > depart at some point in the future. If we ever start doing things like sub-branches it's likely to need more work, but I suggest that that would have been true anyway. I don't believe that the current version shows a different set of commits from the original (other than endpoint bugs...). > I maintain that if someone else whacked around one of your commits the > way you whacked this around, you'd bite their head off. I apologize if I offended you. I hadn't believed that there was any particular consensus on how this script ought to behave; I thought it was something you'd whipped up in an hour based on my request for something like cvs2cl, and that making it work more like that would be uncontroversial. 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] recovery.conf location
On Sun, Sep 26, 2010 at 8:56 PM, Tom Lane wrote: > Jaime Casanova writes: >> On Sun, Sep 26, 2010 at 6:29 PM, Fujii Masao wrote: >>> On Mon, Sep 27, 2010 at 6:56 AM, Thom Brown wrote: I noticed that there's no way to specify the location of recovery.conf in postgresql.conf. > >>> +1 >>> >>> That parameter would be useful when user makes multiple standbys see >>> the same recovery.conf located in NFS or elsewhere. > >> Maybe i'm missing something but this would be a problem if we put a >> trigger file and the recovery.conf gets renamed to recovery.done, no? > > Yeah. The original design for recovery.conf envisioned that it has only > a short lifespan while you're doing an archive recovery. Putting > parameters for slave operation into it has contorted things beyond > recognition. I think we really need to take two steps back and > reconsider the whole "parameters" versus "status" distinction there. Perhaps we should consider folding recovery.conf into postgresql.conf. > This is pretty tightly tied to the ongoing argument about where to keep > parameters for synchronous replication, too. The thing about the parameters for synchronous replication that is a little different is that you need a whole set of parameters *for each standby*. There's not a terribly clean way to handle that in postgresql.conf as it exists today, but getting any agreement on non-trivial changes to postgresql.conf has proven to be next to impossible, despite the fact that AFAICT approximately no one is happy with the status quo. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres 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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane wrote: >>> Hah, I have a plan. Let's just run git log for "master..RELx_y_STABLE" >>> for each branch, rather than all the way back. > >> This doesn't seem more reliable to me in any way. Looking at the >> actual commit history must surely be more reliable than assuming you >> know what it is. I think what you should be doing is using git log >> --decorate and extracting the information from that as you go by. > > I looked at doing that but it didn't seem like an improvement. Take > a look at the new version and see what you think. I'm not really sure. I suppose I'll have to play with it for a while to really form a clear opinion. Clearly, knowing which minor releases a commit is in is a major improvement, but the whole thing is so heavily re-engineered from my original version that I'm not really sure whether there's anything else that I care about that got broken in the process. In particular, I'm wondering to what extent we're baking in branch management conventions from which we may wish to depart at some point in the future. I maintain that if someone else whacked around one of your commits the way you whacked this around, you'd bite their head off. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres 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] recovery.conf location
Jaime Casanova writes: > On Sun, Sep 26, 2010 at 6:29 PM, Fujii Masao wrote: >> On Mon, Sep 27, 2010 at 6:56 AM, Thom Brown wrote: >>> I noticed that there's no way to specify the location of recovery.conf >>> in postgresql.conf. >> +1 >> >> That parameter would be useful when user makes multiple standbys see >> the same recovery.conf located in NFS or elsewhere. > Maybe i'm missing something but this would be a problem if we put a > trigger file and the recovery.conf gets renamed to recovery.done, no? Yeah. The original design for recovery.conf envisioned that it has only a short lifespan while you're doing an archive recovery. Putting parameters for slave operation into it has contorted things beyond recognition. I think we really need to take two steps back and reconsider the whole "parameters" versus "status" distinction there. This is pretty tightly tied to the ongoing argument about where to keep parameters for synchronous replication, too. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] recovery.conf location
On Sun, Sep 26, 2010 at 6:29 PM, Fujii Masao wrote: > On Mon, Sep 27, 2010 at 6:56 AM, Thom Brown wrote: >> I noticed that there's no way to specify the location of recovery.conf >> in postgresql.conf. The pg_hba and pg_ident files can be altered, so >> I'm wondering why this file can't have a specified location. In >> Ubuntu, all configuration files are in a different location to the >> cluster by default, so the postgresql.conf file comes with the >> hba_file and ident_file parameters set to the configuration directory. >> I'd imagine it would be preferable to keep all conf files in the same >> place. > > +1 > > That parameter would be useful when user makes multiple standbys see > the same recovery.conf located in NFS or elsewhere. > Maybe i'm missing something but this would be a problem if we put a trigger file and the recovery.conf gets renamed to recovery.done, no? at least that would be a problem for the standbys that still need to be standbys -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- 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] forming tuple as an attribute inside another tuple in c function
Marios Vodas writes: > Is it posible? Either by using heap_form_tuple or BuildTupleFromCStrings. heap_form_tuple followed by HeapTupleGetDatum should work; that's what's done in ExecEvalRow() for instance. You've omitted to tell us just what's going wrong for you. 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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
Robert Haas writes: > On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane wrote: >> Hah, I have a plan. Let's just run git log for "master..RELx_y_STABLE" >> for each branch, rather than all the way back. > This doesn't seem more reliable to me in any way. Looking at the > actual commit history must surely be more reliable than assuming you > know what it is. I think what you should be doing is using git log > --decorate and extracting the information from that as you go by. I looked at doing that but it didn't seem like an improvement. Take a look at the new version and see what you 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] recovery.conf location
On Mon, Sep 27, 2010 at 6:56 AM, Thom Brown wrote: > I noticed that there's no way to specify the location of recovery.conf > in postgresql.conf. The pg_hba and pg_ident files can be altered, so > I'm wondering why this file can't have a specified location. In > Ubuntu, all configuration files are in a different location to the > cluster by default, so the postgresql.conf file comes with the > hba_file and ident_file parameters set to the configuration directory. > I'd imagine it would be preferable to keep all conf files in the same > place. +1 That parameter would be useful when user makes multiple standbys see the same recovery.conf located in NFS or elsewhere. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Heartbeat between Primary and Standby replicas
Ah, great. I missed looking there. Thanks. On Sun, Sep 26, 2010 at 4:19 PM, Fujii Masao wrote: > On Mon, Sep 27, 2010 at 7:46 AM, fazool mein wrote: > > I checked the code for the keepalive feature. It seems that the socket > > options are only set on the primary's socket connection. The tcp > connection > > created on the secondary for walreceiver does not use the keepalive > > parameters from the configuration. > > You can use libpq keepalive parameters for walreceiver. > > keepalives_idle > keepalives_interval > keepalives_count > http://developer.postgresql.org/pgdocs/postgres/libpq-connect.html > > Those can be set in primary_connection in recovery.conf. > > Regards, > > -- > Fujii Masao > NIPPON TELEGRAPH AND TELEPHONE CORPORATION > NTT Open Source Software Center >
Re: [HACKERS] Heartbeat between Primary and Standby replicas
On Mon, Sep 27, 2010 at 7:46 AM, fazool mein wrote: > I checked the code for the keepalive feature. It seems that the socket > options are only set on the primary's socket connection. The tcp connection > created on the secondary for walreceiver does not use the keepalive > parameters from the configuration. You can use libpq keepalive parameters for walreceiver. keepalives_idle keepalives_interval keepalives_count http://developer.postgresql.org/pgdocs/postgres/libpq-connect.html Those can be set in primary_connection in recovery.conf. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Heartbeat between Primary and Standby replicas
Hello again, I checked the code for the keepalive feature. It seems that the socket options are only set on the primary's socket connection. The tcp connection created on the secondary for walreceiver does not use the keepalive parameters from the configuration. Am I correct? Is this intended or some bug? Thanks. On Fri, Sep 17, 2010 at 7:05 PM, fazool mein wrote: > Apologies. I'm new to Postgres and I didn't see that feature. It satisfies > what I want to do. > > Thanks. > > > On Thu, Sep 16, 2010 at 7:34 PM, Fujii Masao wrote: > >> On Fri, Sep 17, 2010 at 6:49 AM, fazool mein >> wrote: >> > I am designing a heartbeat system between replicas to know when a >> replica >> > goes down so that necessary measures can be taken. As I see, there are >> two >> > ways of doing it: >> > >> > 1) Creating a separate heartbeat process on replicas. >> > 2) Creating a heartbeat message, and sending it over the connection that >> is >> > already established between walsender and walreceiver. >> > >> > With 2, sending heartbeat from walsender to walreceiver seems trivial. >> > Sending a heartbeat from walreceiver to walsender seems tricky. Going >> > through the code, it seems that the walreceiver is always in the >> > PGASYNC_COPY_OUT mode (except in the beginning when handshaking is >> done). >> > >> > Can you recommend the right way of doing this? >> >> The existing keepalive feature doesn't help? >> >> Regards, >> >> -- >> Fujii Masao >> NIPPON TELEGRAPH AND TELEPHONE CORPORATION >> NTT Open Source Software Center >> > >
[HACKERS] recovery.conf location
Hi, I noticed that there's no way to specify the location of recovery.conf in postgresql.conf. The pg_hba and pg_ident files can be altered, so I'm wondering why this file can't have a specified location. In Ubuntu, all configuration files are in a different location to the cluster by default, so the postgresql.conf file comes with the hba_file and ident_file parameters set to the configuration directory. I'd imagine it would be preferable to keep all conf files in the same place. 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] do we want to gitignore regression-test-failure files?
On Sun, Sep 26, 2010 at 4:28 PM, Tom Lane wrote: >> The reason I assumed we'd want to ignore these is because they're >> automatically generated files - unlike *.rej files, which are never >> going to end up in your tree as a result of make anything. It doesn't >> actually matter that much to me in practice, except that I fear >> creating a complex and indecipherable rule about what to ignore vs. >> not. > > I don't find it indecipherable. We're ignoring stuff that can be > expected to be present after a normal build and successful "make > check" or "make installcheck". As soon as we ignore more than that, > I'm going to insist on ignoring *~ ... do you want to open that can > of worms? What is this, some kind of game of chicken? Surely we're trying to settle on a sensible rule here, not get into a mud-wrestling match. I can live with the rule you've articulated but I think it's more complicated than necessary, and I certainly don't want to see it further complicated. Let's get it written down in a README file someplace and not be moving the goalposts henceforth. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres 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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane wrote: > I wrote: >> We could perhaps fix that if there were an inexpensive way to get the >> SHA1 of the master commit that each branch is sprouted from. However, >> I'm inclined to propose that we instead manually place a tag at each >> sprout point. > > Hah, I have a plan. Let's just run git log for "master..RELx_y_STABLE" > for each branch, rather than all the way back. Then we can identify the > sprout point as the parent of the last emitted commit for the branch. > The "post dated" or "double tagged" or whatever you call 'em branch > annotations for earlier master commits can then be inserted by hand, > rather than reverse-engineering them by matching author/message/etc. > This should be both faster and more reliable than the current method. This doesn't seem more reliable to me in any way. Looking at the actual commit history must surely be more reliable than assuming you know what it is. I think what you should be doing is using git log --decorate and extracting the information from that as you go by. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres 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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
I wrote: > We could perhaps fix that if there were an inexpensive way to get the > SHA1 of the master commit that each branch is sprouted from. However, > I'm inclined to propose that we instead manually place a tag at each > sprout point. Hah, I have a plan. Let's just run git log for "master..RELx_y_STABLE" for each branch, rather than all the way back. Then we can identify the sprout point as the parent of the last emitted commit for the branch. The "post dated" or "double tagged" or whatever you call 'em branch annotations for earlier master commits can then be inserted by hand, rather than reverse-engineering them by matching author/message/etc. This should be both faster and more reliable than the current method. Note: if using --since then this method won't necessarily identify the sprout point: we might end up with the SHA1 of some commit on the branch. But it won't matter, because we won't be going back far enough on the master branch for there to be any commits that need to be double-tagged for that branch. A possible objection to this method is that it might be difficult to scale it up to cases where you were interested in branches sprouting off of maintenance branches, rather than only branches sprouted directly from master. But I find it hard to foresee caring about such cases. 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] do we want to gitignore regression-test-failure files?
Robert Haas writes: > On Sun, Sep 26, 2010 at 3:45 PM, Tom Lane wrote: >> -1. If the lack of an ignore causes a problem for you, it indicates >> that you're trying to commit code that fails the regression tests. >> Is it really a good idea to let that happen without any manual cleanup? > I think it just means that the regression tests have failed at some > point since the last time you cleaned out your tree. Those files > don't get removed on a successful make check, do they? Yes, they do. If they are present, then your last attempted check failed. Maybe you fixed the problem afterwards, but you didn't prove it by retesting. > The reason I assumed we'd want to ignore these is because they're > automatically generated files - unlike *.rej files, which are never > going to end up in your tree as a result of make anything. It doesn't > actually matter that much to me in practice, except that I fear > creating a complex and indecipherable rule about what to ignore vs. > not. I don't find it indecipherable. We're ignoring stuff that can be expected to be present after a normal build and successful "make check" or "make installcheck". As soon as we ignore more than that, I'm going to insist on ignoring *~ ... do you want to open that can of worms? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] forming tuple as an attribute inside another tuple in c function
Is it posible? Either by using heap_form_tuple or BuildTupleFromCStrings.
CREATE TYPE p_type AS
(
x double precision,
y double precision
);
CREATE TYPE d_type AS
(
i p_type,
e p_type,
id integer
);
CREATE OR REPLACE FUNCTION demo()
RETURNS d_type
AS '/home/user/PostgreSQL/9.0/lib/mylib','demo'
LANGUAGE C STRICT;
Datum demo(PG_FUNCTION_ARGS) {
float8 xi = 1;
float8 yi = 2;
float8 xe = 3;
float8 ye = 4;
int32 id = 1;
bool isnull;
TupleDesc tupdesc;
Datum values[3];
HeapTuple tuple;
if (get_call_result_type(fcinfo, NULL, &tupdesc) != TYPEFUNC_COMPOSITE)
{
ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("function returning record called in context that cannot accept type
record")));
}
BlessTupleDesc(tupdesc);
*values[0] = ?; //how?**
*
*values[1] = ?;** //how?*
values[2] = Int32GetDatum(id);
tuple = heap_form_tuple(tupdesc, values, &isnull);
PG_RETURN_DATUM(HeapTupleGetDatum(tuple));
}
Re: [HACKERS] do we want to gitignore regression-test-failure files?
On Sun, Sep 26, 2010 at 3:45 PM, Tom Lane wrote: > Robert Haas writes: >> Seems like it's probably a good idea, but I wanted to double-check >> that no one has a different thought. > > -1. If the lack of an ignore causes a problem for you, it indicates > that you're trying to commit code that fails the regression tests. > Is it really a good idea to let that happen without any manual cleanup? I think it just means that the regression tests have failed at some point since the last time you cleaned out your tree. Those files don't get removed on a successful make check, do they? The reason I assumed we'd want to ignore these is because they're automatically generated files - unlike *.rej files, which are never going to end up in your tree as a result of make anything. It doesn't actually matter that much to me in practice, except that I fear creating a complex and indecipherable rule about what to ignore vs. not. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres 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] Patch: Extend NOT NULL representation to pg_constraint
Robert Haas writes: > I think his question was - how do we feel about the massive catalog > bloat this patch will create? It's a fair question. I can imagine designing things so that we don't create an explicit pg_constraint row for the simplest case of an unnamed, non-inherited NOT NULL constraint. Seems like it would complicate matters quite a lot though, in exchange for saving what in the end isn't an enormous amount of space. 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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
On Sun, Sep 26, 2010 at 3:24 PM, Tom Lane wrote:
> We could perhaps fix that if there were an inexpensive way to get the
> SHA1 of the master commit that each branch is sprouted from. However,
> I'm inclined to propose that we instead manually place a tag at each
> sprout point. Any thoughts about that? In particular, what should
> the naming convention for such tags be? I would have liked to use
> RELx_y, but that's out because before 8.0 we named the initial
> releases that way.
>
>
SPLITx_y, STAMPx_y, BRANCHx_y
--
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com
singh.gurj...@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet
Mail sent from my BlackLaptop device
Re: [HACKERS] do we want to gitignore regression-test-failure files?
Robert Haas writes: > Seems like it's probably a good idea, but I wanted to double-check > that no one has a different thought. -1. If the lack of an ignore causes a problem for you, it indicates that you're trying to commit code that fails the regression tests. Is it really a good idea to let that happen without any manual cleanup? I'm a bit surprised that you think this is a good idea while not favoring having, say, *.rej in the ignore configuration. I'd be inclined to put this in the category of things that people can ignore in their personal configurations if they think it's a good idea. If we were going to do this, we'd need it in a lot more places than just src/test/regress/ --- I think it'd really need to be a global ignore. 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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
Robert Haas writes: > On Sun, Sep 26, 2010 at 2:07 PM, Tom Lane wrote: >> ? It's not hard to offer an option for that, I guess, but I foresee an >> argument about what the default is going to be. > If there's no clear consensus, I'm OK with the time-honored tie-break > of "he who does the work...". How about Usage: git_changelog [--post-date/-p] [--since=SINCE] --post-date Show branches made after a commit occurred --since Print only commits dated since SINCE ? Got a better name for 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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
I wrote: > I think we could get that behavior fairly easily by remembering the last > tag matching one of the commits on a branch, as we chase the branch > backwards. I find that this works just fine for the branches, but not so well for master, because more often than not the initial RELx_y_z tag is applied on the release's branch and not on master. So for example commits on master appear to jump from REL7_2 development to REL8_0 development, because 7.3 and 7.4 have no release tag on the master branch. We could perhaps fix that if there were an inexpensive way to get the SHA1 of the master commit that each branch is sprouted from. However, I'm inclined to propose that we instead manually place a tag at each sprout point. Any thoughts about that? In particular, what should the naming convention for such tags be? I would have liked to use RELx_y, but that's out because before 8.0 we named the initial releases that way. 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] Patch: Extend NOT NULL representation to pg_constraint
On Sun, Sep 26, 2010 at 2:11 PM, Bernd Helmle wrote: > --On 25. September 2010 19:55:02 -0300 José Arthur Benetasso Villanova > wrote: > >> One thing that I take notice is when you create a simple table like this >> one: select count(*) from pg_constraint ; 12 rows appears in >> pg_constraint, 10 to the sequence. Is that ok? > > Not sure i get you here, can you elaborate more on this? I think his question was - how do we feel about the massive catalog bloat this patch will create? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres 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] Congratulations on leaving CVS
On Sat, Sep 25, 2010 at 14:49, Robert Haas wrote: > On Sat, Sep 25, 2010 at 8:28 AM, Michael Haggerty > wrote: >> It looks like your transition to git has been a success. Your very >> careful conversion from CVS to git and your exacting scrutiny of the >> results are a great check that cvs2git is not doing anything completely >> crazy. I will soon release a version 2.4 of cvs2svn that includes the >> many improvements that are in trunk, and your work has improved my >> confidence that it is ready. >> >> If nobody objects, I will add PostgreSQL to the list of famous projects >> that have used the cvs2* tools to convert their repositories. It's nice >> to be able to help out a great project like yours, even if only in a >> small way. >> With this, I'll be unsubscribing from your mailing list. Feel free to >> contact me at the cvs2svn mailing list if you discover any more issues, >> or if anybody would like to help out with the further development of the >> cvs2svn family of tools. > > Thanks very much for your help. It was invaluable. Thanks also for > your patience. I'm really glad we got through this conversion, and I > appreciate very much your help in making that happen. +1 on what Robert said :) Many thanks! -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Documentation, window functions
Robert Haas wrote: > Hmm... it is true that average will produce the same results on any > ordering of the same set of input values, though. Not exactly. For floating point approximations you get a more accurate sum (and therefore a more accurate average) if you add the values in ascending order of absolute value. Depending on the data, it can make quite a difference. -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] C function to return tuple
Do you think it would be better to change d_type to this? CREATE TYPE d_type AS ( xi double precision, yi double precision, xe double precision, ye double precision, id integer ); *Note: This is NOT something I want to do but if there is no other way to form d_type tuple from the variables...* On Sun, Sep 26, 2010 at 8:29 PM, Marios Vodas wrote: > Suppose I had the data that form the returning tuple in 5 variables like > this: > float8 xi = 1; > float8 yi = 2; > float8 xe = 3; > float8 ye = 4; > int32 id = 1; > > In addition the function wouldn't have any input parameters. It just > returns a tuple of type d_type. > Can you tell me how it is possible to form the tuple? My problem here is > that I DON'T have HeapTupleHeaders i and e already formed (those two are > of p_type) so I have to form them somehow. >
Re: [HACKERS] Patch: Extend NOT NULL representation to pg_constraint
--On 25. September 2010 19:55:02 -0300 José Arthur Benetasso Villanova wrote: One thing that I take notice is when you create a simple table like this one: select count(*) from pg_constraint ; 12 rows appears in pg_constraint, 10 to the sequence. Is that ok? Not sure i get you here, can you elaborate more on this? -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] do we want to gitignore regression-test-failure files?
Seems like it's probably a good idea, but I wanted to double-check that no one has a different thought. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company gitignore-regression-failures.patch Description: Binary 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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
On Sun, Sep 26, 2010 at 2:07 PM, Tom Lane wrote: > [Do you really want the behavior you said you wanted?] Yes. > ? It's not hard to offer an option for that, I guess, but I foresee an > argument about what the default is going to be. If there's no clear consensus, I'm OK with the time-honored tie-break of "he who does the work...". -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres 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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
Robert Haas writes: > But I still want an option for the original behavior. I have been > using it extensively and I like it. You really think this: Author: Tom Lane Branch: master [872c1497f] 2005-05-24 18:02:31 + Branch: REL9_0_STABLE [872c1497f] 2005-05-24 18:02:31 + Branch: REL8_4_STABLE [872c1497f] 2005-05-24 18:02:31 + Branch: REL8_3_STABLE [872c1497f] 2005-05-24 18:02:31 + Branch: REL8_2_STABLE [872c1497f] 2005-05-24 18:02:31 + Branch: REL8_1_STABLE [872c1497f] 2005-05-24 18:02:31 + Branch: REL8_0_STABLE [a94ace079] 2005-05-24 18:02:55 + Branch: REL7_4_STABLE [0a7b3a364] 2005-05-24 18:03:24 + Previous fix for "x FULL JOIN y ON true" failed to handle the case where there was also a WHERE-clause restriction that applied to the join. The check on restrictlist == NIL is really unnecessary anyway, because select_mergejoin_clauses already checked for and complained about any unmergejoinable join clauses. So just take it out. is preferable to something like Author: Tom Lane Branch: master Release: REL8_1 [872c1497f] 2005-05-24 18:02:31 + Branch: REL8_0_STABLE Release: REL8_0_4 [a94ace079] 2005-05-24 18:02:55 + Branch: REL7_4_STABLE Release: REL7_4_9 [0a7b3a364] 2005-05-24 18:03:24 + Previous fix for "x FULL JOIN y ON true" failed to handle the case where there was also a WHERE-clause restriction that applied to the join. The check on restrictlist == NIL is really unnecessary anyway, because select_mergejoin_clauses already checked for and complained about any unmergejoinable join clauses. So just take it out. ? It's not hard to offer an option for that, I guess, but I foresee an argument about what the default is going to be. 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] Documentation, window functions
> Hmm... it is true that average will produce the same results on any > ordering of the same set of input values, though. Perhaps the word > "partition" emcompass that, though then again maybe not. > > I'd be happy to fix this if I understand what to fix it to. I wish I knew how to rephrase it so it is both as simple as now and also totally clear. We can't complicate it, it's a tutorial. /Dennis -- 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] C function to return tuple
Suppose I had the data that form the returning tuple in 5 variables like this: float8 xi = 1; float8 yi = 2; float8 xe = 3; float8 ye = 4; int32 id = 1; In addition the function wouldn't have any input parameters. It just returns a tuple of type d_type. Can you tell me how it is possible to form the tuple? My problem here is that I DON'T have HeapTupleHeaders i and e already formed (those two are of p_type) so I have to form them somehow. On Sun, Sep 26, 2010 at 7:52 PM, Tom Lane wrote: > Marios Vodas writes: > > //I need to get this working > > *values[0] = e;* > > *values[1] = i;* > > Maybe you're missing HeapTupleGetDatum() there? Just from a data type > cleanliness standpoint, you shouldn't ever assign something to Datum or > vice versa without applying the correct conversion macro. > >regards, tom lane >
Re: [HACKERS] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
On Sun, Sep 26, 2010 at 1:25 PM, Tom Lane wrote: > I wrote: >> If we could figure out how to show which major release a master-branch >> commit antedated, and which point release a back-branch commit >> antedated, I think we would have something that's actually significantly >> more useful for both purposes than either of these behaviors. > > I think we could get that behavior fairly easily by remembering the last > tag matching one of the commits on a branch, as we chase the branch > backwards. However, I'm not seeing a convenient way to extract the > commit SHA1s pointed to by the available tags. git tag doesn't tell > this and git show provides way too much information. Anybody know the > right incantation for that? git rev-parse REL8_3_0 But I still want an option for the original behavior. I have been using it extensively and I like it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres 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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
I wrote: > If we could figure out how to show which major release a master-branch > commit antedated, and which point release a back-branch commit > antedated, I think we would have something that's actually significantly > more useful for both purposes than either of these behaviors. I think we could get that behavior fairly easily by remembering the last tag matching one of the commits on a branch, as we chase the branch backwards. However, I'm not seeing a convenient way to extract the commit SHA1s pointed to by the available tags. git tag doesn't tell this and git show provides way too much information. Anybody know the right incantation for that? 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] C function to return tuple
Marios Vodas writes: > //I need to get this working > *values[0] = e;* > *values[1] = i;* Maybe you're missing HeapTupleGetDatum() there? Just from a data type cleanliness standpoint, you shouldn't ever assign something to Datum or vice versa without applying the correct conversion macro. 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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
Robert Haas writes: > On Sun, Sep 26, 2010 at 12:08 PM, Tom Lane wrote: >> Hm? As far as I can tell, this fixes that not breaks it. The problem >> I was seeing was that commits would be attributed to a branch when in >> fact they were made before the branch ever existed. > But the commits are still on any subsequently-created branches. > Frequently, I'm trying to figure out the first release that contains > some particular change. Say, tablespaces. So I go back and look > through the git log and find the commit. And here it is: > 2467394ee1566e82d0314d12a0d1c0a5670a28c9. > Now I want to know which branches contain that commit. With the old > coding, I can just run this script, and it'll tell me all the branches > REL8_0_STABLE and higher have that commit. If the abbreviated SHA1 > hashes are the same, I know that the commit was actually done before > the branch points for those releases. If they're different, I know > that the commit was back-patched into those branches. Well, all I can say is that I find that unnecessarily verbose, and that in ten years of working with cvs2cl I can't recall ever once wishing that it would behave that way. What I do often wish is that it were easier to tell which point-releases a given patch was applied between, ie, if it's on the 8.4 branch did it appear in 8.4.1, 8.4.2, etc. But neither of these behaviors is useful for that. If we could figure out how to show which major release a master-branch commit antedated, and which point release a back-branch commit antedated, I think we would have something that's actually significantly more useful for both purposes than either of these behaviors. It would show you what you want without having to make nonobvious deductions from comparisons of commit hashes, and it would also ease my main use-case which is "which point release did that get fixed in?" I've experimented with git log --all --source but it tends to make unhelpful choices of which tag to report; maybe the secret would be to limit the set of tags it chases 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] C function to return tuple
I see what you mean and I changed the code BUT still my main problem is that
I want to know how to fill values array. I remind you that d_type contains
attributes of another composite type p_type.
I need a solution to that because I need to use it in other parts of the
code.
Datum d_swap(PG_FUNCTION_ARGS) {
HeapTupleHeader t = PG_GETARG_HEAPTUPLEHEADER(0);
HeapTupleHeader i;
HeapTupleHeader e;
bool isnull;
TupleDesc tupdesc;
Datum values[3];
HeapTuple tuple;
i = DatumGetHeapTupleHeader(GetAttributeByName(t, "i", &isnull));
e = DatumGetHeapTupleHeader(GetAttributeByName(t, "e", &isnull));
if (get_call_result_type(fcinfo, NULL, &tupdesc) != TYPEFUNC_COMPOSITE)
{
ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("function returning record called in context that cannot accept type
record")));
}
BlessTupleDesc(tupdesc);
//I need to get this working
*values[0] = e;*
*values[1] = i;*
*values[2] = GetAttributeByName(t, "id", &isnull);*
tuple = heap_form_tuple(tupdesc, values, &isnull);
PG_RETURN_DATUM(HeapTupleGetDatum(tuple));
}
On Sun, Sep 26, 2010 at 7:16 PM, Tom Lane wrote:
> Marios Vodas writes:
> > My problem is that I don't know how to construct the d_type tuple in the
> c
> > function.
>
> Seems like the main problem with that function is that you're passing
> an uninitialized "nulls" array to heap_form_tuple.
>
> I kinda wonder why you are using a fixed-length values array together
> with a variable-length, dynamically allocated nulls array, but that'
> just odd style not wrong in itself.
>
>regards, tom lane
>
Re: [HACKERS] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
On Sun, Sep 26, 2010 at 12:08 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane wrote: >>> Still more tweaking of git_changelog. > >> Uhm, could you stop massively changing the behavior of this script >> with no discussion at all? > > Uh, there was no discussion of the original behavior of the script > either. It was posted to the list weeks before it was committed and it was discussed by multiple people at that time. We didn't debate every detail of the behavior but there was certainly ample space for public comment. >> I happen to think that this is a >> distinctly bad idea. It defeats one of the major use cases of the >> original script, which is being able to easily figure out which >> branches a certain commit is in. > > Hm? As far as I can tell, this fixes that not breaks it. The problem > I was seeing was that commits would be attributed to a branch when in > fact they were made before the branch ever existed. But the commits are still on any subsequently-created branches. Frequently, I'm trying to figure out the first release that contains some particular change. Say, tablespaces. So I go back and look through the git log and find the commit. And here it is: 2467394ee1566e82d0314d12a0d1c0a5670a28c9. Now I want to know which branches contain that commit. With the old coding, I can just run this script, and it'll tell me all the branches REL8_0_STABLE and higher have that commit. If the abbreviated SHA1 hashes are the same, I know that the commit was actually done before the branch points for those releases. If they're different, I know that the commit was back-patched into those branches. With your changes, all I get is: Author: Tom Lane Branch: master [2467394ee] 2004-06-18 06:14:31 + ...which is much less useful, at least given that I don't have the dates of all the branch points memorized. > I was under the impression that the purpose of the script was to replace > cvs2cl and do approximately what cvs2cl did. If you have another > use-case then please explain what it is and why this change is bad > for it. See above. Thanks, -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres 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] Large objects.
Hey Robert, Yes, I am sure. I've tested it by test case in my original post. Do you can compile and reproduce it please? -- // Dmitriy.
Re: [HACKERS] C function to return tuple
Marios Vodas writes: > My problem is that I don't know how to construct the d_type tuple in the c > function. Seems like the main problem with that function is that you're passing an uninitialized "nulls" array to heap_form_tuple. I kinda wonder why you are using a fixed-length values array together with a variable-length, dynamically allocated nulls array, but that' just odd style not wrong in itself. 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] Large objects.
On Fri, Sep 24, 2010 at 9:13 AM, Dmitriy Igrishin wrote: > Tell me please, why lo_write() returns me the number of bytes "actually > written" > when current write location is out of 2GB ? IMO, in this case it should > returns > at least zero. > lo_read() returns zero in this case, and it is correct, IMO. Hmm, are you sure? If the behavior of lo_read and lo_write is not symmetric, that's probably not good, but I don't see anything obvious in the code to make me think that's the case. Returning 0 for a value >= 2^31 seems problematic unless there is no possibility of a short read (or write). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres 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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
Robert Haas writes: > On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane wrote: >> Still more tweaking of git_changelog. > Uhm, could you stop massively changing the behavior of this script > with no discussion at all? Uh, there was no discussion of the original behavior of the script either. > I happen to think that this is a > distinctly bad idea. It defeats one of the major use cases of the > original script, which is being able to easily figure out which > branches a certain commit is in. Hm? As far as I can tell, this fixes that not breaks it. The problem I was seeing was that commits would be attributed to a branch when in fact they were made before the branch ever existed. > If you want to have an option for > this behavior, fine, but please do not presume that everyone wants the > same thing as you (since that is evidently not the case) or that you > are the only person who is using it (if that were so, it should be > stored in your personal workspace, rather than our community > repository). I was under the impression that the purpose of the script was to replace cvs2cl and do approximately what cvs2cl did. If you have another use-case then please explain what it is and why this change is bad for 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] Documentation, window functions
On Thu, Sep 23, 2010 at 11:34 PM, Dennis Björklund wrote: >> On Wed, Sep 22, 2010 at 6:03 AM, Dennis Björklund wrote: >> But I confess that I'm sort of murky on how ORDER affects the window >> frame, or how to rephrase this more sensibly. > > The rows included in the calculation of the window function are per default > > RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW > > where CURRENT ROW include all the rows that are equal to the row you are > at according to the ordering. So if you say order by name then all the > rows up to your name and all rows with the same name are included, not > later rows. > > If you don't have any ordering, then all rows are "equal" and all rows are > included in the computation. That's why your example behaved like it did. > > At least that's my understanding of how these things work. I've not used > window functions very much myself. > > This is fairly difficult stuff and it probably don't belong in a tutorial > but the current wording suggest that you can add any ordering and it won't > affect the result. That is also a bad since it might teach people the > wrong thing. Hmm... it is true that average will produce the same results on any ordering of the same set of input values, though. Perhaps the word "partition" emcompass that, though then again maybe not. I'd be happy to fix this if I understand what to fix it to. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres 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] [COMMITTERS] pgsql: Still more tweaking of git_changelog.
On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane wrote: > Still more tweaking of git_changelog. > > 1. Don't assume there's only one candidate match; check them all and use the > one with the closest timestamp. Avoids funny output when someone makes > several successive commits with the same log message, as certain people > have been known to do. > > 2. When the same commit (with the same SHA1) is reachable from multiple > branch tips, don't report it for all the branches; instead report it only > for the first such branch. Given our development practices, this case > arises only for commits that occurred before a given branch split off from > master. The original coding blamed old commits on *all* the branches, > which isn't terribly useful; the new coding blames such a commit only on > master. Uhm, could you stop massively changing the behavior of this script with no discussion at all? I happen to think that this is a distinctly bad idea. It defeats one of the major use cases of the original script, which is being able to easily figure out which branches a certain commit is in. If you want to have an option for this behavior, fine, but please do not presume that everyone wants the same thing as you (since that is evidently not the case) or that you are the only person who is using it (if that were so, it should be stored in your personal workspace, rather than our community repository). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] C function to return tuple
I have these types:
CREATE TYPE p_type AS
(
x double precision,
y double precision
);
CREATE TYPE d_type AS
(
i p_type,
e p_type,
id integer
);
CREATE OR REPLACE FUNCTION d_swap(d_type)
RETURNS d_type
AS '/home/user/PostgreSQL/9.0/lib/mylib','d_swap'
LANGUAGE C STRICT;
My problem is that I don't know how to construct the d_type tuple in the c
function. I read the documentation but it only explains how i could do that
for a more simple type like p_type.
The difficulty is that d_type has attributes of p_type.
Thank you in advance.
This is the c code I wrote until now:
Datum d_swap(PG_FUNCTION_ARGS) {
HeapTupleHeader t = PG_GETARG_HEAPTUPLEHEADER(0);
HeapTupleHeader i;
HeapTupleHeader e;
bool isnull;
TupleDesc tupdesc;
Datum values[3];
HeapTuple tuple;
int tuplen;
bool *nulls;
i = DatumGetHeapTupleHeader(GetAttributeByName(t, "i", &isnull));
e = DatumGetHeapTupleHeader(GetAttributeByName(t, "e", &isnull));
if (get_call_result_type(fcinfo, NULL, &tupdesc) != TYPEFUNC_COMPOSITE)
{
ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("function returning record called in context that cannot accept type
record")));
}
BlessTupleDesc(tupdesc);
values[0] = e;
values[1] = i;
values[2] = GetAttributeByName(t, "id", &isnull);
tuplen = tupdesc->natts;
nulls = palloc(tuplen * sizeof (bool));
tuple = heap_form_tuple(tupdesc, values, nulls);
pfree(nulls);
PG_RETURN_DATUM(HeapTupleGetDatum(tuple));
}
Re: [HACKERS] Stalled post to pgsql-committers
On Sun, Sep 26, 2010 at 15:39, Heikki Linnakangas wrote: > On 25/09/10 19:43, Peter Eisentraut wrote: >> >> I'm not subscribed to pgsql-committers, but apparently under the new >> git-enabled setup, I'm getting a "Stalled post to pgsql-committers" >> message for every commit. Fix that please. > > Just subscribe with 'nomail'. That's what I did. Yeah, that's what you need to do. I would guess you were previously subscribed as pe...@postgresql.org, but the git commit scrpit sends the email from pete...@gmx.net, so you need to subscribe from that one (with or without nomail). -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Stalled post to pgsql-committers
On 25/09/10 19:43, Peter Eisentraut wrote: I'm not subscribed to pgsql-committers, but apparently under the new git-enabled setup, I'm getting a "Stalled post to pgsql-committers" message for every commit. Fix that please. Just subscribe with 'nomail'. That's what I did. -- 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] Per-column collation, work in progress
On 09/26/2010 09:37 AM, Greg Stark wrote: We could have a encoded_text data type which includes both the encoding and the string and which any comparison function automatically handles conversion based on the encoding of the collation requested -- but I wouldn't want that to be the default text datatype. It would impose a lot of overhead on the basic text operations and magnify the effects of choosing the wrong collation. Yeah, but it would be a nice gadget to have. 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] Per-column collation, work in progress
On Sun, Sep 26, 2010 at 1:15 PM, Pavel Stehule wrote: > Is there any reason why you prohibit a different encodings per one > database? Actually people expect from collate per column a possibility > to store a two or more different encodings per one database. These are two completely separate problems that only look related. The main difference is that while collation is a property of the comparison or sort you're performing encoding is actually a property of the string itself. It doesn't make sense to specify a different encoding than what the string actually contains. You could actually do what you want now by using bytea columns and convert_to/convert_from and it wouldn't be much easier if the support were built into text since you would still have to keep track of the encoding it's in and the encoding you want. We could have a encoded_text data type which includes both the encoding and the string and which any comparison function automatically handles conversion based on the encoding of the collation requested -- but I wouldn't want that to be the default text datatype. It would impose a lot of overhead on the basic text operations and magnify the effects of choosing the wrong collation. -- 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] Per-column collation, work in progress
Hello Peter Is there any reason why you prohibit a different encodings per one database? Actually people expect from collate per column a possibility to store a two or more different encodings per one database. Without this possibility - only UTF8 is possible for practical work - and for other encodings only pairs (national locale + C). Yes - it is from my perspective (as Czech programmer) - very typical situation and request is mix latin2 and latin1. I can live with limit, but it is very hard limit and should be documented. Regards Pavel 2010/9/15 Peter Eisentraut : > Following up on my previous patch [0], here is a fairly complete > implementation of this feature. The general description and > implementation outline of the previous message still apply. This patch > contains documentation and regression tests, which can serve as further > explanations. > > As this patch touches pretty much everything in the system, there are > probably countless bugs and bogosities, some of which I have marked with > FIXME, TODO, etc. But all the functionality is basically there, so it's > time someone else gives this a serious examination. > > Note: As previously, regression tests only work with "make check > MULTIBYTE=UTF8" and the feature overall only works on Linux/glibc. > > [0] > http://archives.postgresql.org/message-id/1279045531.32647.14.ca...@vanquo.pezone.net > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] wip: functions median and percentile
Hello, there is updated version - with support of window clause. The limits are work_mem for using inside window aggregate or unlimited when it is used as standard query. This patch needs a few work - can share a compare functionality with tuplesort.c, but I would to verify a concept now. Comments? Regards Pavel median.diff Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] documentation udpates to pgupgrade.html
Hello, just doing an upgrade form PostgreSQL 8.4.4 on Windows 2007 64bit to PostgreSQL 9.0 64bit on the same system. I am working along http://developer.postgresql.org/pgdocs/postgres/pgupgrade.html There is written: NET STOP postgresql-8.4 NET STOP postgresql-9.0 or NET STOP pgsql-8.3 (PostgreSQL 8.3 and older used a different service name) which should be extended by net stop postgresql-x64-9.0 for Windows 64 bit. - It would also be helpfull, if there was a reamrk that pg_upgrade will try to write to the current directory - as "runas /user:postgres cmd.exe" usually starts within c:\windows\system; so a cd %TEMP% after runas would be valuable - -- GHUM GmbH Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 Amtsgericht Stuttgart, HRB 734971 - persuadere. et programmare -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
