Re: [HACKERS] Postgres Licensing
On 20/09/10 09:48, Vaibhav Kaushal wrote: 1. PostgreSQL can be distributed freely according to the license terms. Can it be sold (for a price) without changing anything in the source? Yes. You will have a hard time finding anyone to buy it, though, because you can download it for free from the PostgreSQL website. 2. Does the license restrict me from adding my closed source additions to the project and then sell the product? I want to add in a few files here and there which would be closed source in nature, while all the changes made to the original files will be open, and then sell the modified database with a dual license. Is this possible? In general, yes. I don't know what exactly you mean by the dual license, but you are free to mix proprietary code with the PostgreSQL sources, and sell or distribute for free the combined product with or without sources. The only requirement of the PostgreSQL license is that all copies must include the copyright notices and the license text. (Disclaimer: I am not a lawyer) -- 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] Postgres Licensing
May be this is the wrong place to ask the question. Still, answer me if someone can or please redirect me to some place where it can be answered. My questions are: 1. PostgreSQL can be distributed freely according to the license terms. Can it be sold (for a price) without changing anything in the source? 2. Does the license restrict me from adding my closed source additions to the project and then sell the product? I want to add in a few files here and there which would be closed source in nature, while all the changes made to the original files will be open, and then sell the modified database with a dual license. Is this possible? May be you guys are hard core OSS enthusiasts and may flame me. I request not to and please consider my question. Thanks a lot.
Re: [HACKERS] Configuring synchronous replication
On 19/09/10 01:20, Robert Haas wrote: On Sat, Sep 18, 2010 at 5:42 PM, Josh Berkus wrote: There are considerable benefits to having a standby registry with a table-like interface. Particularly, one where we could change replication via UPDATE (or ALTER STANDBY) statements. I think that using a system catalog for this is going to be a non-starter, but we could use a flat file that is designed to be machine-editable (and thus avoid repeating the mistake we've made with postgresql.conf). Yeah, that needs some careful design. We also need to record transient information about each slave, like how far it has received WAL already. Ideally that information would survive database restart too, but maybe we can live without that. -- 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] Configuring synchronous replication
On 18/09/10 22:59, Robert Haas wrote: On Sat, Sep 18, 2010 at 4:50 AM, Simon Riggs wrote: Waiting might sound attractive. In practice, waiting will make all of your connections lock up and it will look to users as if their master has stopped working as well. (It has!). I can't imagine why anyone would ever want an option to select that; its the opposite of high availability. Just sounds like a serious footgun. Nevertheless, it seems that some people do want exactly that behavior, no matter how crazy it may seem to you. Yeah, I agree with both of you. I have a hard time imaging a situation where you would actually want that. It's not high availability, it's high durability. When a transaction is acknowledged as committed, you know it's never ever going to disappear even if a meteor strikes the current master server within the next 10 milliseconds. In practice, people want high availability instead. That said, the timeout option also feels a bit wishy-washy to me. With a timeout, acknowledgment of a commit means "your transaction is safely committed in the master and slave. Or not, if there was some glitch with the slave". That doesn't seem like a very useful guarantee; if you're happy with that why not just use async replication? However, the "wait forever" behavior becomes useful if you have a monitoring application outside the DB that decides when enough is enough and tells the DB that the slave can be considered dead. So "wait forever" actually means "wait until I tell you that you can give up". The monitoring application can STONITH to ensure that the slave stays down, before letting the master proceed with the commit. With that in mind, we have to make sure that a transaction that's waiting for acknowledgment of the commit from a slave is woken up if the configuration changes. -- 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] Progress indication prototype
I had a small play with this. Pretty cool to be able to track progress for COPY and VACUUM jobs. For some reason I could never elicit any numbers (other than the default Nan) for a query (tried 'SELECT count(*) FROM pgbench_accounts' but figured aggregates probably don't qualify as simple, and also 'SELECT * FROM pgbench_accounts'). I'm thinking that complex queries is precisely where people would want to see this sort of indicator - but maybe have a read of: http://research.microsoft.com/pubs/76171/progress.pdf This paper seems to suggest that there are real classes of query where a useful progress indicator is going to be extremely hard to construct. However it may still be a useful feature to have for all those other queries! Also I'm inclined to agree with Robert and think that a more accurate, more performance obtrusive but settable on demand implementation is the way to go. Cheers Mark On 17/08/10 17:19, Peter Eisentraut wrote: Here is a small prototype for a query progress indicator. Past discussions seemed to indicate that the best place to report this would be in pg_stat_activity. So that's what this does. You can try it out with any of the following (on a sufficiently large table): VACUUM (lazy) (also autovacuum), COPY out from table, COPY in from file, table-rewriting ALTER TABLE (e.g., add column with default), or a very simple query. Run the command, and stare at pg_stat_activity (perhaps via "watch") in a separate session. More can be added, and the exact placement of the counters is debatable, but those might be details to be worked out later. Note, my emphasis here is on maintenance commands; I don't plan to do a progress estimation of complex queries at this time. Some thoughts: - Are the interfaces OK? - Is this going to be too slow to be useful? - Should there be a separate switch to turn it on (currently track_activities)? - How to handle commands that process multiple tables? For example, lazy VACUUM on a single table is pretty easy to track (count the block numbers), but what about a database-wide lazy VACUUM? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_comments
Robert Haas writes: > In view of the foregoing problems, I'd like to propose adding a new > system view, tentatively called pg_comments, which lists all of the > comments for everything in the system in such a way that it's > reasonably possible to do further filtering out the output in ways > that you might care about; and which also gives objects the names and > types in a format that matches what the COMMENT command will accept as > input. Patch attached. Unless you propose to break psql's hard-won backwards compatibility, this isn't going to accomplish anything towards making describe.c simpler or shorter. Also, it seems to me that what you've mostly done is to move complexity from describe.c (where the query can be fixed easily if it's found to be broken) to system_views.sql (where it cannot be changed without an initdb). How about improving the query in-place in describe.c 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] compile/install of git
On Sat, Sep 18, 2010 at 02:20:53PM -0400 I heard the voice of David Blewett, and lo! it spake thus: > > Sorry for top-posting... I was under the impression that git over http was > just as efficient since 1.6.6 [1]. That's about talking over HTTP to a git server running as CGI; it doesn't help if you're talking HTTP to just a plain HTTP host. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. -- 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] So where did that $Id$ come from?
Tom Lane wrote: > Hey Bruce, how is it that this recent commit > http://archives.postgresql.org/pgsql-committers/2010-02/msg00202.php > replaced a $PostgreSQL$ CVS keyword with a $Id$ one? > > The commit message mentions an "existing *.pl conversion script", > so I'm suspicious that somewhere there is a script that wants to > put these things in, but I can't find it in CVS. I assume he used one of the exiting PLs as a basis: $ pwd /pg/backend/utils/mb/Unicode $ ls *.pl UCS_to_BIG5.pl UCS_to_EUC_JP.pl UCS_to_GB18030.pl UCS_to_most.pl UCS_to_EUC_CN.plUCS_to_EUC_KR.pl UCS_to_SHIFT_JIS_2004.plucs2utf.pl UCS_to_EUC_JIS_2004.pl UCS_to_EUC_TW.pl UCS_to_SJIS.pl but looking at those files, they all use $PostgreSQL$. No idea why an $Id$ got in there. Is it possible I used on $PostgreSQL$ and $Id$ was added by default? -- 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] wip: functions median and percentile
2010/8/19 Pavel Stehule : > Hello > > I am sending a prototype implementation of functions median and > percentile. This implementation is very simple and I moved it to > contrib for this moment - it is more easy maintainable. Later I'll > move it to core. I've reviewed this patch. * The patch can apply cleanly and make doesn't print any errors nor warnings. But it doesn't touch contrib/Makefile so I had to make by changing dir to contrib/median. * Cosmetic coding style should be more appropriate, including trailing white spaces and indentation positions. * Since these two aggregates use tuplesort inside it, there're possible risk to cause out of memory in normal use case. I don't think this fact is critical, but at least some notation should be referred in docs. * It doesn't contain any document nor regression tests. * They should be callable in window function context; for example contrib_regression=# select median(a) over (order by a) from t1; ERROR: invalid tuplesort state or at least user-friend message should be printed. * The returned type is controversy. median(int) returns float8 as the patch intended, but avg(int) returns numeric. AFAIK only avg(float8) returns float8. * percentile() is more problematic; first, the second argument for the aggregate takes N of "N%ile" as int, like 50 if you want 50%ile, but it doesn't care about negative values or more than 100. In addition, the second argument is taken at the first non-NULL value of the first argument, but the second argument is semantically constant. For example, for (1.. 10) value of a in table t1, contrib_regression=# select percentile(a, a * 10 order by a) from t1; percentile 1 (1 row) contrib_regression=# select percentile(a, a * 10 order by a desc) from t1; percentile 10 (1 row) and if the argument comes from the subquery which doesn't contain ORDER BY clause, you cannot predict the result. That's all of my quick review up to now. Regards, -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Configuring synchronous replication
> I've designed a way to tune sync rep so it is usable and useful. And > putting that feature into 9.1 costs very little, if anything. My patch > to do this is actually smaller than any other attempt to implement this > and I claim faster too. You don't need to use the per-transaction > controls, but they'll be there if you need them. Well, if you already have the code, that's a different story ... -- -- 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] psycopg and two phase commit
On Sun, Sep 19, 2010 at 6:38 PM, Daniele Varrazzo wrote: > On Sat, Sep 18, 2010 at 5:01 PM, Pavel Stehule > wrote: >> There are some bariers? > > I see none at a first glance. I just don't get the intricacies of the > .xid() method suggested in the dbapi > (http://www.python.org/dev/peps/pep-0249/) while a regular string > would do - and the xid has to be converted in a string anyway to be > passed to the Postgres TPC statements. So I'm tempted to allow the > tpc_*() methods to accept a simple string too as parameter; also > because otherwise psycopg wouldn't be able to manipulate a transaction > prepared by other tools (e.g. retrieving a xid using tpc_recover() and > passing it to tpc_commit()/tpc_rollback(), a limitation that can be > avoided. I've read the XA specification, which have inspired the DBAPI extension for TPC, and the discussion in the Python DB-SIG leading to such extensions (http://mail.python.org/pipermail/db-sig/2008-January/thread.html). The methods proposed in the DBAPI don't map 1-1 with the PG TPC statements so it will be necessary some work in the driver to implement the proposed interface. But being TPC all about interoperability I think it is a necessary complication. -- Daniele -- 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] pgxs docdir question
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes: > Where does PGXS makefile get /usr/share/doc/pgsql/contrib directory > from? > While building 3rd party RPMs using PGXS, even if I specify docdir in > Makefile, README.* files are installed to this directory, which breaks > parallel installation path as of 9.0+ Maybe you need to fool with MODULEDIR. See http://archives.postgresql.org/pgsql-committers/2010-01/msg00025.php 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] english parser in text search: support for multiple words in the same position
Sushant Sinha writes: > For the headline generation to work properly, email/file/url/host need > to become skip tokens. Updating the patch with that change. I looked at this patch a bit. I'm fairly unhappy that it seems to be inventing a brand new mechanism to do something the ts parser can already do. Why didn't you code the url-part mechanism using the existing support for compound words? The changes made to parsetext() seem particularly scary: it's not clear at all that that's not breaking unrelated behaviors. In fact, the changes in the regression test results suggest strongly to me that it *is* breaking things. Why are there so many diffs in examples that include no URLs at all? An issue that's nearly as bad is the 100% lack of documentation, which makes the patch difficult to review because it's hard to tell what it intends to accomplish or whether it's met the intent. The patch is not committable without documentation anyway, but right now I'm not sure it's even usefully reviewable. In line with the lack of documentation, I would say that the choice of the name "parttoken" for the new token type is not helpful. Part of what? And none of the other token type names include the word "token", so that's not a good decision either. Possibly "url_part" would be a suitable name. 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] pgxs docdir question
Where does PGXS makefile get /usr/share/doc/pgsql/contrib directory from? While building 3rd party RPMs using PGXS, even if I specify docdir in Makefile, README.* files are installed to this directory, which breaks parallel installation path as of 9.0+ Speficially, I want to install READMEs under /usr/pgsql-9.0/share/contrib for 9.0. How do I do that? Regards, -- Devrim GÜNDÜZ PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer PostgreSQL RPM Repository: http://yum.pgrpms.org Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Configuring synchronous replication
On Sat, 2010-09-18 at 14:42 -0700, Josh Berkus wrote: > > * Per-transaction control. Some transactions are important, others are not. > > Low priority. > I see this as a 9.2 feature. Nobody I know is asking for it yet, and I > think we need to get the other stuff right first. I understand completely why anybody that has never used sync replication would think per-transaction control is a small deal. I fully expect your clients to try sync rep and then 5 minutes later say "Oh Crap, this sync rep is so slow it's unusable. Isn't there a way to tune it?". I've designed a way to tune sync rep so it is usable and useful. And putting that feature into 9.1 costs very little, if anything. My patch to do this is actually smaller than any other attempt to implement this and I claim faster too. You don't need to use the per-transaction controls, but they'll be there if you need them. -- Simon Riggs www.2ndQuadrant.com 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] Serializable Snapshot Isolation
On 19/09/10 16:48, Kevin Grittner wrote: After tossing it around in my head for a bit, the only thing that I see (so far) which might work is to maintain a *list* of SERIALIZABLEXACT objects in memory rather than a using a hash table. The recheck after releasing the shared lock and acquiring an exclusive lock would then go through SerializableXidHash. I think that can work, although I'm not 100% sure that it's an improvement. Yeah, also keep in mind that a linked list with only a few items is faster to scan through than sequentially scanning an almost empty hash table. Putting that aside for now, we have one very serious problem with this algorithm: While they [SIREAD locks] are associated with a transaction, they must survive a successful COMMIT of that transaction, and remain until all overlapping > transactions complete. Long-running transactions are already nasty because they prevent VACUUM from cleaning up old tuple versions, but this escalates the problem to a whole new level. If you have one old transaction sitting idle, every transaction that follows consumes a little bit of shared memory, until that old transaction commits. Eventually you will run out of shared memory, and will not be able to start new transactions anymore. Is there anything we can do about that? Just a thought, but could you somehow coalesce the information about multiple already-committed transactions to keep down the shared memory usage? For example, if you have this: 1. Transaction begins 2. 100 other transactions begin and commit Could you somehow group together the 100 committed transactions and represent them with just one SERIALIZABLEXACT struct? -- 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] Update comment for README.HOT
Applied. --- Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian writes: > > > + This means that UPDATE, DELETE, and SELECT can trigger space > > > + reclamation, while INSERT ... VALUES cannot because it does not retrieve > > > + a row. > > > > I don't believe that's correct. It might have happened to work that way > > for you in a particular test. It's certainly not something I'd document > > as being intended long-term behavior. > > Well, I would like to document something about this because I was > surprised that when INSERT did not trigger a cleanup. I realize we > might change the behavior but then we would update the file too, > hopefully. > > How is the attached version using "often"? I also clarified it is < 10% > free. > > I found this while doing tests for a new MVCC talk I will be delivering > at PG West. > > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + > Index: src/backend/access/heap/README.HOT > === > RCS file: /cvsroot/pgsql/src/backend/access/heap/README.HOT,v > retrieving revision 1.6 > diff -c -c -r1.6 README.HOT > *** src/backend/access/heap/README.HOT23 Apr 2010 23:21:44 - > 1.6 > --- src/backend/access/heap/README.HOT17 Sep 2010 21:21:56 - > *** > *** 246,251 > --- 246,257 > is arbitrarily capped at MaxHeapTuplesPerPage (the most tuples that > could fit without HOT pruning). > > + Effectively, space reclamation happens during tuple retrieval when the > + page is nearly full (<10% free) and a buffer cleanup lock can be > + acquired. This means that UPDATE, DELETE, and SELECT can trigger space > + reclamation, but often not during INSERT ... VALUES because it does > + not retrieve a row. > + > > VACUUM > -- > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- 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] psql's \dn versus temp schemas
Robert Haas writes: > On Sat, Sep 18, 2010 at 6:35 PM, Robert Haas wrote: >> On Sat, Sep 18, 2010 at 3:11 PM, Tom Lane wrote: >>> This is at least inconsistent and at worst wildly misleading. ISTM >>> we ought to adopt some combination of the following ideas: >> I vote for this combination: >> >>> 3. Don't show either pg_temp_nn or pg_toast_temp_nn schemas, not even >>> for the current backend. >> >> and >> >>> With any of 1-3 we could also consider adding a rule that \dn+ >>> doesn't hide them. This approach makes sense to me too; I'd be inclined to hide pg_toast as well under the same rules. In all of these cases, the schemas are not meant to be referred to explicitly. I think that the original motivation for letting \dn show the backend's own pg_temp_nn schema was that there were cases where you needed to refer to it by name. Since then, we invented the "pg_temp" alias mechanism, which seems to remove most of the need for that. > Or perhaps another option would be to make \dnS display these. Not > sure whether I like that or not. Hmm. If we had a \dnS option, what I would sorta expect it to do is show the "system" schemas pg_catalog and information_schema. The toast and temp schemas seem like a different category somehow. On the other hand, if we did it like this, then the S and + modifiers would be orthogonal which is a nice property. Anyone else have an opinion? 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] psycopg and two phase commit
Hello 2010/9/19 Daniele Varrazzo : > On Sat, Sep 18, 2010 at 5:01 PM, Pavel Stehule > wrote: >> Hello >> >> who is psycopg maintainer, please? > > Here is one. The others can be usually mailed on the psycopg mailing > list, which is currently down and being recovered. > >> Can somebody explains to me, why >> psycopg doesn't support twophase commit still, although some >> implementation was done in summer 2008? > > Probably because nobody has asked before and it has been nobody's itch > to scratch. > > The work you probably refer to seems Jason Henstridge's. I didn't know > anything about it, but I've bcc'd him so he can provide details. > > https://code.launchpad.net/~jamesh/psycopg/two-phase-commit > >> Now two phase commit is part of DB-API, so can be implemented. >> >> There are some bariers? > > I see none at a first glance. I just don't get the intricacies of the > .xid() method suggested in the dbapi > (http://www.python.org/dev/peps/pep-0249/) while a regular string > would do - and the xid has to be converted in a string anyway to be > passed to the Postgres TPC statements. So I'm tempted to allow the > tpc_*() methods to accept a simple string too as parameter; also > because otherwise psycopg wouldn't be able to manipulate a transaction > prepared by other tools (e.g. retrieving a xid using tpc_recover() and > passing it to tpc_commit()/tpc_rollback(), a limitation that can be > avoided. > These are a good news. I hope so I'll a some time on begin of October, when I can to play with this topic. But this must not be a too much hard work. Thank you Pavel Stehule > I can work on the feature, first I'd like to review James's code and > possibly hear from him his impressions. > > -- Daniele > -- 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] psycopg and two phase commit
On Sat, Sep 18, 2010 at 5:01 PM, Pavel Stehule wrote: > Hello > > who is psycopg maintainer, please? Here is one. The others can be usually mailed on the psycopg mailing list, which is currently down and being recovered. > Can somebody explains to me, why > psycopg doesn't support twophase commit still, although some > implementation was done in summer 2008? Probably because nobody has asked before and it has been nobody's itch to scratch. The work you probably refer to seems Jason Henstridge's. I didn't know anything about it, but I've bcc'd him so he can provide details. https://code.launchpad.net/~jamesh/psycopg/two-phase-commit > Now two phase commit is part of DB-API, so can be implemented. > > There are some bariers? I see none at a first glance. I just don't get the intricacies of the .xid() method suggested in the dbapi (http://www.python.org/dev/peps/pep-0249/) while a regular string would do - and the xid has to be converted in a string anyway to be passed to the Postgres TPC statements. So I'm tempted to allow the tpc_*() methods to accept a simple string too as parameter; also because otherwise psycopg wouldn't be able to manipulate a transaction prepared by other tools (e.g. retrieving a xid using tpc_recover() and passing it to tpc_commit()/tpc_rollback(), a limitation that can be avoided. I can work on the feature, first I'd like to review James's code and possibly hear from him his impressions. -- Daniele -- 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] Report: removing the inconsistencies in our CVS->git conversion
Andrew Dunstan writes: > On 09/19/2010 12:25 PM, Tom Lane wrote: >> # We don't want to change line numbers, so we simply reduce the keyword >> # string to the file pathname part. For example, >> # $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12 2010/09/07 14:10:30 momjian >> Exp $ >> # becomes >> # $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12 2010/09/07 14:10:30 momjian >> Exp $ > These before and after lines look identical to me. Sigh ... obviously didn't finish editing the comment :-( Of course the last line should read # src/port/unsetenv.c 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] Report: removing the inconsistencies in our CVS->git conversion
On 09/19/2010 12:25 PM, Tom Lane wrote: Pursuant to that, attached are proposed modified versions of the two scripts involved. # # We don't want to change line numbers, so we simply reduce the keyword # string to the file pathname part. For example, # $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12 2010/09/07 14:10:30 momjian Exp $ # becomes # $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12 2010/09/07 14:10:30 momjian Exp $ # These before and after lines look identical to me. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] So where did that $Id$ come from?
Hey Bruce, how is it that this recent commit http://archives.postgresql.org/pgsql-committers/2010-02/msg00202.php replaced a $PostgreSQL$ CVS keyword with a $Id$ one? The commit message mentions an "existing *.pl conversion script", so I'm suspicious that somewhere there is a script that wants to put these things in, but I can't find it in CVS. 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] Report: removing the inconsistencies in our CVS->git conversion
I wrote:
> I looked a bit more at your pggit_migrate stuff. I'm not terribly happy
> with the proposed clean_keywords.pl script. I'd like it to reduce the
> $PostgreSQL$ thingies to the full pathname of the file, rather than
> try to remove all trace of them, eg
> * $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12 2010/09/07 14:10:30
> momjian Exp $
> becomes
> * src/port/unsetenv.c
> This would then be followed up by moving those pathname comments to
> somewhere more sensible. I don't think that part can be managed with
> a script like this, but leaving the data in place will make it easier
> to do the moving. Some places, like the .sgml files, won't need any
> additional changing to get to where I would like to be.
> Also, I'd be inclined to make these changes only in master, not in the
> back branches. We don't for example run pg_indent against back branches.
Pursuant to that, attached are proposed modified versions of the two
scripts involved.
regards, tom lane
#!/usr/bin/perl -w
#
# Attempt to remove all cvs keywords in the given directory tree
# (with "all keywords" meaning $PostgreSQL$ keyword)
#
# We don't want to change line numbers, so we simply reduce the keyword
# string to the file pathname part. For example,
# $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12 2010/09/07 14:10:30 momjian Exp $
# becomes
# $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12 2010/09/07 14:10:30 momjian Exp $
#
$REPODIR=$ARGV[0] || die "No repository specified\n";
chdir($REPODIR) || die "Could not chdir to $REPODIR\n";
open(L,"git grep -l \\\$PostgreSQL |") || die "Could not git-grep\n";
while () {
chomp;
my $fn = $_;
my $txt;
open(F,"<$fn") || die "Could not read $_\n";
while () {
s|\$PostgreSQL: pgsql/(\S+),v [^\$]+\$|$1|;
$txt .= $_;
}
close(F);
open(F,">$fn") || die "Could not write $_\n";
print F $txt;
close(F);
$txt = '';
}
#!/bin/bash
set -e
REPO=/opt/gitrepo_cvs2git
HERE=$(pwd)
# clean master only
BRANCHES="master"
cd $REPO
for B in $BRANCHES ; do
if [ "$B" != "master" ]; then
echo Creating branch $B
git branch -f $B --track origin/$B
fi
echo Switching to $B
git checkout $B
echo Cleaning $B
perl $HERE/clean_keywords.pl $REPO
echo Committing cleanup
git commit -a -F - <
--
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] Serializable Snapshot Isolation
Heikki Linnakangas wrote: > ISTM you never search the SerializableXactHash table using a hash > key, except the one call in CheckForSerializableConflictOut, but > there you already have a pointer to the SERIALIZABLEXACT struct. > You only re-find it to make sure it hasn't gone away while you > trade the shared lock for an exclusive one. If we find another way > to ensure that, ISTM we don't need SerializableXactHash at all. My > first thought was to forget about VirtualTransactionId and use > TransactionId directly as the hash key for SERIALIZABLEXACT. The > problem is that a transaction doesn't have a transaction ID when > RegisterSerializableTransaction is called. We could leave the > TransactionId blank and only add the SERIALIZABLEXACT struct to the > hash table when an XID is assigned, but there's no provision to > insert an existing struct to a hash table in the current hash table > API. > > So, I'm not sure of the details yet, but it seems like it could be > made simpler somehow.. After tossing it around in my head for a bit, the only thing that I see (so far) which might work is to maintain a *list* of SERIALIZABLEXACT objects in memory rather than a using a hash table. The recheck after releasing the shared lock and acquiring an exclusive lock would then go through SerializableXidHash. I think that can work, although I'm not 100% sure that it's an improvement. I'll look it over in more detail. I'd be happy to hear your thoughts on this or any other suggestions. -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] patch: Add JSON datatype to PostgreSQL (GSoC, WIP)
On 08/12/2010 06:27 AM, David Fetter wrote: +1 for putting it in core in 9.1 :) There are times I really wish I could get object graphs, or at least hierarchically nested object trees, of objects matching various criteria. JSON might be a reasonable representation, and one that's increasingly well supported by many different clients. Having it core would be really handy for that sort of use, especially as managing contrib modules is rather far from ideal in Pg as things stand. Using the usual generic business app example, it'd be good to be able to retrieve "customer 1234, as well as all dependent records in Invoices and Addresses" with one query, one round trip ... and no horrid ORM-like use of left outer joins plus post-processing. I've been able to do that with nested XML representations, but it's a remarkably verbose, bulky way to move chunks of data around. This patch already looks like it has lots of promise for that sort of use. It'd need aggregates, but that's already come up. A composite-or-row-type to json converter seems to be much of the point of this patch, and that's the only other part that's really required. So I'm excited, and I suspect I won't be the only one. I'm grabbing it to start playing with it now. I just wanted to chime in with interest + enthusiasm for JSON as an increasingly useful representation. -- Craig Ringer -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
