Re: [HACKERS] Configuring synchronous replication
On Mon, 2010-09-20 at 18:24 -0400, Robert Haas wrote: > I feel like that's really nice and simple. There are already 5 separate places to configure to make streaming rep work in a 2 node cluster (master.pg_hba.conf, master.postgresql.conf, standby.postgresql.conf, standby.recovery.conf, password file/ssh key). I haven't heard anyone say we would be removing controls from those existing areas, so it isn't clear to me how adding a 6th place will make things "nice and simple". Put simply, Standby registration is not required for most use cases. If some people want it, I'm happy that it can be optional. Personally, I want to make very sure that any behaviour that involves waiting around indefinitely can be turned off and should be off by default. ISTM very simple to arrange things so you can set parameters on the master OR on the standby, whichever is most convenient or desirable. Passing parameters around at handshake is pretty trivial. I do also understand that some parameters *must* be set in certain locations to gain certain advantages. Those can be documented. I would be happier if we could separate the *list* of control parameters we need from the issue of *where* we set those parameters. I would be even happier if we could agree on the top 3-5 parameters so we can implement those first. -- 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] top-level DML under CTEs
2010/9/23 Marko Tiikkaja : > On 2010-09-17 4:48 AM, Hitoshi Harada wrote: >> >> 2010/9/15 Hitoshi Harada: >>> >>> Well, I didn't know it is allowed. That would look like the way to go. >> >> I made changes to the previous version, so that it avoids to resolve >> CTE name duplication. > > This patch still doesn't address the issue Tom raised here: > http://archives.postgresql.org/pgsql-hackers/2010-09/msg00753.php > > For WITH .. INSERT .. WITH .. SELECT ..; this patch works OK, but not so > much for VALUES: > > =# CREATE RULE barrule AS ON UPDATE TO bar DO INSTEAD > -# WITH RECURSIVE t AS (SELECT -1) > -# INSERT INTO bar > -# WITH t AS (SELECT 1) > -# VALUES((SELECT * FROM t)); > CREATE RULE > > =# \d bar > Table "public.bar" > Column | Type | Modifiers > +-+--- > a | integer | > Rules: > barrule AS > ON UPDATE TO bar DO INSTEAD WITH RECURSIVE t AS ( > SELECT 1 > ), t AS ( > SELECT (-1) > ) > INSERT INTO bar (a) WITH RECURSIVE t AS ( > SELECT 1 > ), t AS ( > SELECT (-1) > ) > > VALUES (( SELECT t."?column?" > FROM t)) I ran the sql and recognized what is wrong. In VALUES case, the WITH table "t" is copied in one list and shown up in the both of INSERT-level WITH and SELECT-level WITH. Since the transformation of WITH clause to cheat postgres is in the parser stage currently, I wonder if this should be done in the rewriter or the planner stage. Thanks for the report. Next time, please point the clear problem in English aside the sample. 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] Git cvsserver serious issue
On Thu, Sep 23, 2010 at 04:59, Andrew Dunstan wrote: >>> Also, couldn't we just set up the cvsserver on its own VM with a limited >>> amount of disk space, and not worry too much about any "DOS threat"? >>> If somebody does do this, block them and reinitialize that server. >> >> We could do that, but that could end up fighting a losing battle in >> case some bot hits it. >> >> I don't like deploying something with a known issue on it, sandboxed or >> not. >> > > Thinking about this some more, how about we do non-anonymous CVS over SSH > access to the git-cvsserver for the few buildfarm members that can't > currently handle using git (e.g. spoonbill)? Well, if we do that centrally, we are back to a dedicated VM (hint: we're most certainly not adding non-personal no-password accounts to one of the VMs used for critical services - it's bad enough we have Bruce's account there :P). I assume most buildfarm clients are off static IPs (at least as seen from the servers - they may be behind a NAT device, but that one having static out)? If so, it seems simply easier to use pserver... > I'm not sure if that would handle other requirements, such as Peter's, but I > hope the residual requirements for CVS support will be pretty rare. Just to be sure - do we have any other requirements for CVS *beyond* buildfarm and NLS that we're not thinking of here? -- 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] Serializable Snapshot Isolation
On 23/09/10 02:14, Kevin Grittner wrote: There is a rub on the other point, though. Without transaction information you have no way of telling whether TN committed before T0, so you would need to assume that it did. So on this count, there is bound to be some increase in false positives leading to transaction rollback. Without more study, and maybe some tests, I'm not sure how significant it is. (Actually, we might want to track commit sequence somehow, so we can determine this with greater accuracy.) I'm confused. AFAICS there is no way to tell if TN committed before T0 in the current patch either. But wait, the bigger problems are yet to come. The other way we can detect conflicts is a read by a serializable transaction noticing that a different and overlapping serializable transaction wrote the tuple we're trying to read. How do you propose to know that the other transaction was serializable without keeping the SERIALIZABLEXACT information? Hmm, I see. We could record which transactions were serializable in a new clog-like structure that wouldn't exhaust shared memory. And how do you propose to record the conflict without it? I thought you just abort the transaction that would cause the conflict right there. The other transaction is committed already, so you can't do anything about it anymore. Finally, this would preclude some optimizations which I *think* will pay off, which trade a few hundred kB more of shared memory, and some additional CPU to maintain more detailed conflict data, for a lower false positive rate -- meaning fewer transactions rolled back for hard-to-explain reasons. This more detailed information is also what seems to be desired by Dan S (on another thread) to be able to log the information needed to be able to reduce rollbacks. Ok, I think I'm ready to hear about those optimizations now :-). -- 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] Git cvsserver serious issue
On 09/22/2010 10:26 AM, Magnus Hagander wrote: On Wed, Sep 22, 2010 at 16:23, Tom Lane wrote: Magnus Hagander writes: Any user can point their cvs client at the repository. And check out an arbitrary branch, tag *or individual commit*. Doing so will create a 50Mb sqlite database on the server with cache information about that head. That basically means that git-cvsserver is completely useless in a public scenario as it stands. An easier way to DOS our server is hard to find, really. Ugh. Indeed. Now, if we can limit this by IP address, that would be ok. I assume we can do this for the NLS stuff - peter? As for buildfarm members needing CVS - is it workable to require that the maintainers of these set up their own git clone with git cvsserver (over ssh or pserver) and restrict it locally to the IP(s) of their machines? If we're going to let people in by IP address, maybe we could let legacy buildfarm members in by IP address. It doesn't seem particularly helpful to expect each buildfarm owner to solve this problem for themselves. I'd also note that if they could run git locally, they wouldn't be needing cvsserver in the first place. We could. It's currently on a freebsd vm though and I don't think we can set per-server IP filters on those. (I was thinking iptables). We could move it though - it doesn't *have* to be on the anonymous git VM. It's just some extra resources. Well, the use-case I was thinking of was Stefan. While he can't run git on each and every animal, he certainly has *some* machine(s) on the correct side of whatever firewall there may be that can run git. Also, couldn't we just set up the cvsserver on its own VM with a limited amount of disk space, and not worry too much about any "DOS threat"? If somebody does do this, block them and reinitialize that server. We could do that, but that could end up fighting a losing battle in case some bot hits it. I don't like deploying something with a known issue on it, sandboxed or not. Thinking about this some more, how about we do non-anonymous CVS over SSH access to the git-cvsserver for the few buildfarm members that can't currently handle using git (e.g. spoonbill)? I'm not sure if that would handle other requirements, such as Peter's, but I hope the residual requirements for CVS support will be pretty rare. 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] Easy way to verify gitignore files?
At 2010-09-22 22:19:45 -0400, t...@sss.pgh.pa.us wrote: > > I can demonstrate that this is not so. Try a "git add" on such a file. Works fine for me with v1.7.3 (no warnings, no need for add -f). What version do you use? If I try to add an untracked file which is already ignored, then I get the warning. -- ams $ git init a; cd a Initialized empty Git repository in /home/ams/a/.git/ $ echo foo > a; git add a; git commit -m 1 [master (root-commit) 0031fcb] 1 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 a $ echo a > .gitignore; git add .gitignore; git commit -m 2 [master ed019e5] 2 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 .gitignore $ echo bar > a; git add a; git commit -m 3 [master 19e5d2a] 3 1 files changed, 1 insertions(+), 1 deletions(-) $ echo baz > a; git commit -a -m 4 [master 73da20a] 4 1 files changed, 1 insertions(+), 1 deletions(-) -- 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] Easy way to verify gitignore files?
Abhijit Menon-Sen writes: > At 2010-09-22 20:54:19 -0400, t...@sss.pgh.pa.us wrote: >> However, it seems that git isn't so willing to tell you about gitignore >> patterns that cover too much, i.e. match files that are already in the >> repository. > If .gitignore specifies a pattern that matches something that's already > in the repository, that specification is itself ignored, and the file is > treated like any other file. I can demonstrate that this is not so. Try a "git add" on such a file. It fails --- at least it does with the version of git currently in Fedora 13. You get some nasty warning about how there's a conflicting .gitignore pattern and you have to use -f if you want to add. 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] Easy way to verify gitignore files?
On 23 September 2010 11:28, Abhijit Menon-Sen wrote: >> This seems pretty dangerous, especially for people who are willing to >> rely on "git commit -a" :-( > > There is no danger. "git commit -a" will commit changes to files that > match .gitignore but are already in the repository. (I vaguely remember > that there were bugs in this regard in old versions of git, but it's not > a problem with any recent version AFAIK.) > Right; .gitignore patterns are only applied to untracked files. Once a file is tracked by git, you can try to gitignore it all you like, it won't have any effect. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Easy way to verify gitignore files?
At 2010-09-22 20:54:19 -0400, t...@sss.pgh.pa.us wrote: > > However, it seems that git isn't so willing to tell you about gitignore > patterns that cover too much, i.e. match files that are already in the > repository. If .gitignore specifies a pattern that matches something that's already in the repository, that specification is itself ignored, and the file is treated like any other file. > This seems pretty dangerous, especially for people who are willing to > rely on "git commit -a" :-( There is no danger. "git commit -a" will commit changes to files that match .gitignore but are already in the repository. (I vaguely remember that there were bugs in this regard in old versions of git, but it's not a problem with any recent version AFAIK.) -- ams -- 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] Easy way to verify gitignore files?
Robert Haas writes: > On Wed, Sep 22, 2010 at 8:54 PM, Tom Lane wrote: >> Is there any automated sanity check that we can run to find this sort >> of problem? I suspect that we probably have got some errors in the >> .gitignore files, particularly in the back branches, and it would be >> nice to find them now before they get in the way of normal development. > I assume one could write a perl script to check this pretty simply... No doubt, but I was hoping somebody already had. In particular, it'd be best if one could use git's own logic for matching .gitignores, rather than reimplementing it in a way that might or might not behave quite the same. 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] Easy way to verify gitignore files?
On Wed, Sep 22, 2010 at 8:54 PM, Tom Lane wrote: > It's not hard to tell if we're missing a file that ought to be listed > in .gitignore --- git status will find that problem soon enough. > However, it seems that git isn't so willing to tell you about gitignore > patterns that cover too much, i.e. match files that are already in the > repository. I found out by accident that you will only hear about this > when you try to "git add" such a file after changing it. This seems > pretty dangerous, especially for people who are willing to rely on > "git commit -a" :-( > > Is there any automated sanity check that we can run to find this sort > of problem? I suspect that we probably have got some errors in the > .gitignore files, particularly in the back branches, and it would be > nice to find them now before they get in the way of normal development. I assume one could write a perl script to check this pretty simply... -- 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] Why is time with timezone 12 bytes?
On Wed, Sep 22, 2010 at 9:00 PM, Tom Lane wrote: > Robert Haas writes: >> Technically, there's no reason why we can't do this for 9.1. What we >> can do is change the name of the "time with timezone" type to >> something like "oldtimetz", keeping the current OID. And then we can >> add a new type called "time with timezone". [ with large amounts of >> consequent work ] > > I think you missed the point of my response, which is that there are > easily 10^6 more-pressing things to work on than the size of timetz. > Do you know of any actual use cases for it? Well, I wasn't responding to you - I was responding to Josh. Regardless of the merits of redesigning this particular data type, I think it's important for us to cultivate a mindset of figuring out how we can make gradual improvements to the on-disk format without earth-shattering consequences for pg_upgrade. Mind you, I don't currently have the time to hack on this for, uh, more or less the reason you state. But if my boss told me he double my pay if I got it done, I wouldn't tell him it's technically impossible. -- 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] Why is time with timezone 12 bytes?
Robert Haas writes: > Technically, there's no reason why we can't do this for 9.1. What we > can do is change the name of the "time with timezone" type to > something like "oldtimetz", keeping the current OID. And then we can > add a new type called "time with timezone". [ with large amounts of > consequent work ] I think you missed the point of my response, which is that there are easily 10^6 more-pressing things to work on than the size of timetz. Do you know of any actual use cases 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
[HACKERS] Easy way to verify gitignore files?
It's not hard to tell if we're missing a file that ought to be listed in .gitignore --- git status will find that problem soon enough. However, it seems that git isn't so willing to tell you about gitignore patterns that cover too much, i.e. match files that are already in the repository. I found out by accident that you will only hear about this when you try to "git add" such a file after changing it. This seems pretty dangerous, especially for people who are willing to rely on "git commit -a" :-( Is there any automated sanity check that we can run to find this sort of problem? I suspect that we probably have got some errors in the .gitignore files, particularly in the back branches, and it would be nice to find them now before they get in the way of normal development. 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] Why is time with timezone 12 bytes?
On Wed, Sep 22, 2010 at 7:20 PM, Josh Berkus wrote: > >> timestamptz stores GMT; it doesn't store timezone separately. >> (If it did, we'd need more than 8 bytes...) > > Oh, yeah. Duh. > >> Because we haven't lifted a finger to optimize it. > > Well, that's a direct answer. Ok, will put it in the list of "TODO next > time we change the on-disk format". Technically, there's no reason why we can't do this for 9.1. What we can do is change the name of the "time with timezone" type to something like "oldtimetz", keeping the current OID. And then we can add a new type called "time with timezone". Then, with some suitable hacking of pg_dump --binary-upgrade, I think it should be possible to make timetz columns from pre-9.1 databases turn into oldtimetz columns when pg_upgrade is used. New applications will of course get the new data type. Then, in a future release (let's call it 10.0), we could remove the oldtimetz types. pg_upgrade would then forbid upgrades to the release that used the old type, by complaining about (1) upgrades from 8.4/9.0 with timetz columns, or (2) upgrades from 9.1+ with oldtimetz columns. Users would instead be instructed to upgrade to a 9.1+ release, use ALTER TABLE ... TYPE timetz, and then upgrade again. Obviously this could still be inconvenient for some users, but it's a lot better than breaking everything all at once: you have 5 or 10 years to find time to rewrite the table. If someone decides to attack this, it would also be good to see about reducing the typalign to something less than "d". I am concerned that all of that alignment is wasting a great deal of space on disk, which is becoming ever more of a problem as people start to use PostgreSQL with larger and larger databases. It seems like the performance benefit is likely pretty limited, too. Copying a 64-bit value that is only 4-byte aligned rather than 8-byte aligned should only be very slightly slower if you do it as two 4-byte fetches rather than a single 8-byte fetch, I would think, and it seems like a small price to pay to avoid inserting as many as 7 padding bytes. -- 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] Standby registration
Heikki Linnakangas wrote: > (starting yet another thread to stay focused) > > Having mulled through all the recent discussions on synchronous > replication, ISTM there is pretty wide consensus that having a registry > of all standbys in the master is a good idea. Even those who don't think > it's *necessary* for synchronous replication seem to agree that it's > nevertheless a pretty intuitive way to configure it. And it has some > benefits even if we never get synchronous replication. > > So let's put synchronous replication aside for now, and focus on standby > registration first. Once we have that, the synchronous replication patch > will be much smaller and easier to review. > > The consensus seems to be use a configuration file called standby.conf. > Let's use the "ini file format" for now [1]. > > Aside from synchronous replication, there are three nice things we can > do with a standby registry: > > A) Make monitoring easier. Let's have a system view to show the status > of all standbys [2]. It would be interesting if we could fire triggers on changes to that status view. I can see that solving many user management needs. -- 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] top-level DML under CTEs
On 2010-09-17 4:48 AM, Hitoshi Harada wrote: 2010/9/15 Hitoshi Harada: Well, I didn't know it is allowed. That would look like the way to go. I made changes to the previous version, so that it avoids to resolve CTE name duplication. This patch still doesn't address the issue Tom raised here: http://archives.postgresql.org/pgsql-hackers/2010-09/msg00753.php For WITH .. INSERT .. WITH .. SELECT ..; this patch works OK, but not so much for VALUES: =# CREATE RULE barrule AS ON UPDATE TO bar DO INSTEAD -# WITH RECURSIVE t AS (SELECT -1) -# INSERT INTO bar -# WITH t AS (SELECT 1) -# VALUES((SELECT * FROM t)); CREATE RULE =# \d bar Table "public.bar" Column | Type | Modifiers +-+--- a | integer | Rules: barrule AS ON UPDATE TO bar DO INSTEAD WITH RECURSIVE t AS ( SELECT 1 ), t AS ( SELECT (-1) ) INSERT INTO bar (a) WITH RECURSIVE t AS ( SELECT 1 ), t AS ( SELECT (-1) ) VALUES (( SELECT t."?column?" FROM t)) Regards, Marko Tiikkaja -- 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] Git conversion status
Tom Lane wrote: > Robert Haas writes: > > On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera > > wrote: > >> As far as I can see, I need to go to the master clone, run a checkout > >> and pull on each branch, and *then* a pull on the local clone updates to > >> the latest head on that branch. ?It is not enough to pull when the > >> master branch is checked out. > > > Ah, crap. You're right. Sucktastic. > > As far as I can tell so far, the multiple-workdir setup dominates all > the others in terms of minimizing the amount of "git pull" monkeywork. Yes, that is what I am using too. -- 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] Shutting down server from a backend process, e.g. walrceiver
Thanks for the tips. In our case, SIGINT makes more sense. I'll use that. Regards On Tue, Sep 21, 2010 at 7:50 PM, Fujii Masao wrote: > On Wed, Sep 22, 2010 at 2:50 AM, fazool mein wrote: > > Yes, I'll be modifying the code. In the walreceiver, I used the following > to > > send a shutdown to the postmaster: > > > > kill(getppid(), SIGTERM); > > You can use the global variable "PostmasterPid" instead of getppid. > There are three types of shutdown. SIGTERM triggers smart shutdown. > Smart shutdown is suitable for your case? If not, you might need to > send SIGINT or SIGQUIT instead. > > Regards, > > -- > Fujii Masao > NIPPON TELEGRAPH AND TELEPHONE CORPORATION > NTT Open Source Software Center >
Re: [HACKERS] WIP: Triggers on VIEWs
On 2010-09-23 1:16 AM, Bernd Helmle wrote:
INSERT INTO vfoo VALUES('helmle', 2) RETURNING *;
text | id
+
helmle | 2
(1 row)
SELECT * FROM vfoo;
text | id
---+
bernd | 2
(1 row)
This is solvable by a properly designed trigger function, but maybe we need
to do something about this?
I really don't think we should limit what people are allowed to do in
the trigger function.
Besides, even if the RETURNING clause returned 'bernd' in the above
case, I think it would be even *more* surprising. The trigger function
explicitly returns NEW which has 'helmle' as the first field.
Regards,
Marko Tiikkaja
--
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] Why is time with timezone 12 bytes?
> timestamptz stores GMT; it doesn't store timezone separately. > (If it did, we'd need more than 8 bytes...) Oh, yeah. Duh. > Because we haven't lifted a finger to optimize it. Well, that's a direct answer. Ok, will put it in the list of "TODO next time we change the on-disk format". -- -- 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] Why is time with timezone 12 bytes?
Josh Berkus writes: >> It's the same, because the limits are calendar based (particularly, >> the Julian-date functions) and not dependent on the representation. > Hmmm? Just storing dates for the range described (until the year > 294,000) takes 8bytes by my calculations. And that's without the 3 > bytes for the time zone. Is my math off? timestamptz stores GMT; it doesn't store timezone separately. (If it did, we'd need more than 8 bytes...) > And, of course, this doesn't answer at all why time with time zone is so > huge. Because we haven't lifted a finger to optimize 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] Serializable Snapshot Isolation
Heikki Linnakangas wrote: > When a transaction is commits, its predicate locks must be held, > but it's not important anymore *who* holds them, as long as > they're hold for long enough. > > Let's move the finishedBefore field from SERIALIZABLEXACT to > PREDICATELOCK. When a transaction commits, set the finishedBefore > field in all the PREDICATELOCKs it holds, and then release the > SERIALIZABLEXACT struct. The predicate locks stay without an > associated SERIALIZABLEXACT entry until finishedBefore expires. > > Whenever there are two predicate locks on the same target that > both belonged to an already-committed transaction, the one with a > smaller finishedBefore can be dropped, because the one with higher > finishedBefore value covers it already. I don't think this works. Gory details follow. The predicate locks only matter when a tuple is being written which might conflict with one. In the notation often used for the dangerous structures, the conflict only occurs if TN writes something which T1 can't read or T1 writes something which T0 can't read. When you combine this with the fact that you don't have a problem unless TN commits *first*, then you can't have a problem with TN looking up a predicate lock of a committed transaction; if it's still writing tuples after T1's commit, the conflict can't matter and really should be ignored. If T1 is looking up a predicate lock for T0 and finds it committed, there are two things which must be true for this to generate a real conflict: TN must have committed before T0, and T0 must have overlapped T1 -- T0 must not have been able to see T1's write. If we have a way to establish these two facts without keeping transaction level data for committed transactions, predicate lock *lookup* wouldn't stand in the way of your proposal. Since the writing transaction is active, if the xmin of its starting transaction comes before the finishedBefore value, they must have overlapped; so I think we have that part covered, and I can't see a problem with your proposed use of the earliest finishedBefore value. There is a rub on the other point, though. Without transaction information you have no way of telling whether TN committed before T0, so you would need to assume that it did. So on this count, there is bound to be some increase in false positives leading to transaction rollback. Without more study, and maybe some tests, I'm not sure how significant it is. (Actually, we might want to track commit sequence somehow, so we can determine this with greater accuracy.) But wait, the bigger problems are yet to come. The other way we can detect conflicts is a read by a serializable transaction noticing that a different and overlapping serializable transaction wrote the tuple we're trying to read. How do you propose to know that the other transaction was serializable without keeping the SERIALIZABLEXACT information? And how do you propose to record the conflict without it? The wheels pretty much fall off the idea entirely here, as far as I can see. Finally, this would preclude some optimizations which I *think* will pay off, which trade a few hundred kB more of shared memory, and some additional CPU to maintain more detailed conflict data, for a lower false positive rate -- meaning fewer transactions rolled back for hard-to-explain reasons. This more detailed information is also what seems to be desired by Dan S (on another thread) to be able to log the information needed to be able to reduce rollbacks. -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] Another Modest Proposal: Platforms
On Wed, Sep 22, 2010 at 6:56 PM, David Fetter wrote: > On Wed, Sep 22, 2010 at 06:03:16PM -0400, Tom Lane wrote: >> "Joshua D. Drake" writes: >> > I mean, it took us forever to require Perl 5.8. >> >> ... and we still make a point of not having a hard requirement for >> that. If you don't want plperl, you can build from a tarball with >> no perl at all. >> >> Given the project history, I can't see us turning a dependency we >> just added this week into a hard requirement anytime soon. >> >> Now having said that, if you define "supported platform" to mean >> "gets tested on the buildfarm", we do require Perl. And CVS, which >> will soon get replaced by a requirement for Git. But I'm not going >> to tell someone to get lost if they file a portability bug report >> without having set up a buildfarm animal first. > > I agree that "get lost" is not a reasonable first reaction, but as > with platforms like AIX, "It would help us enormously for you to put > up a buildfarm animal with your development environment on it" isn't. I feel like we do that already, as the occasion demands... so this isn't really a change in policy from that point of view. -- 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] Why is time with timezone 12 bytes?
> It's the same, because the limits are calendar based (particularly, > the Julian-date functions) and not dependent on the representation. Hmmm? Just storing dates for the range described (until the year 294,000) takes 8bytes by my calculations. And that's without the 3 bytes for the time zone. Is my math off? And, of course, this doesn't answer at all why time with time zone is so huge. -- -- 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] Another Modest Proposal: Platforms
On Wed, Sep 22, 2010 at 06:03:16PM -0400, Tom Lane wrote: > "Joshua D. Drake" writes: > > I mean, it took us forever to require Perl 5.8. > > ... and we still make a point of not having a hard requirement for > that. If you don't want plperl, you can build from a tarball with > no perl at all. > > Given the project history, I can't see us turning a dependency we > just added this week into a hard requirement anytime soon. > > Now having said that, if you define "supported platform" to mean > "gets tested on the buildfarm", we do require Perl. And CVS, which > will soon get replaced by a requirement for Git. But I'm not going > to tell someone to get lost if they file a portability bug report > without having set up a buildfarm animal first. I agree that "get lost" is not a reasonable first reaction, but as with platforms like AIX, "It would help us enormously for you to put up a buildfarm animal with your development environment on it" isn't. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] Why is time with timezone 12 bytes?
Josh Berkus writes: > Also, what is the real range of our 8-byte *integer* timestamp? >> >> See the fine manual. I believe the limits have more to do with >> calendar arithmetic than with the nominal range of 2^64 microseconds. > I'm asking based on that. The docs only give the limits for a *float* > timestamp. I'd like to fix the docs, but I can only do it if I have the > data ... It's the same, because the limits are calendar based (particularly, the Julian-date functions) and not dependent on the representation. 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] WIP: Triggers on VIEWs
--On 5. September 2010 09:09:55 +0100 Dean Rasheed
wrote:
I had a first look on your patch, great work!
Attached is an updated patch with more tests and docs, and a few minor
code tidy ups. I think that the INSTEAD OF triggers part of the patch
is compliant with Feature T213 of the SQL 2008 standard. As discussed,
Reading the past discussions, there was some mention about the RETURNING
clause.
I see Oracle doesn't allow its RETURNING INTO clause with INSTEAD OF
triggers (at least my 10g XE instance here doesn't allow it, not sure about
newer versions). I assume the following example might have some surprising
effects on users:
CREATE TABLE foo(id integer);
CREATE VIEW vfoo AS SELECT 'bernd', * FROM foo;
CREATE OR REPLACE FUNCTION insert_foo() RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN INSERT INTO foo VALUES(NEW.id);
RETURN NEW;
END; $$;
CREATE TRIGGER insert_vfoo INSTEAD OF INSERT ON vfoo
FOR EACH ROW EXECUTE PROCEDURE insert_foo();
INSERT INTO vfoo VALUES('helmle', 2) RETURNING *;
text | id
+
helmle | 2
(1 row)
SELECT * FROM vfoo;
text | id
---+
bernd | 2
(1 row)
This is solvable by a properly designed trigger function, but maybe we need
to do something about this?
I don't plan to add the syntax to allow triggers on views to be
disabled at this time, but that should be easy to implement, if there
is a use case for it.
I really don't see a need for this at the moment. We don't have DISABLE
RULE either. I'm going to post some additional comments once i've
understand all things.
--
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
Re: [HACKERS] Configuring synchronous replication
> The above case is one where I can see your point and it does sound > easier in that case. But I then think: "What happens after failover?". > We would then need to have 12 different standby.conf files, one on each > standby that describes what the setup would look like if that standby > became the master. And guess what, every time we made a change on the > master, you'd need to re-edit all 12 standby.conf files to reflect the > new configuration. So we're still back to having to edit in multiple > places, ISTM. Unless we can make the standby.conf files identical on all servers in the group. If we can do that, then conf file management utilities, fileshares, or a simple automated rsync could easily take care of things. But ... any setup which involves each standby being *required* to have a different configuration on each standby server, which has to be edited separately, is going to be fatally difficult to manage for anyone who has more than a couple of standbys. So I'd like to look at what it takes to get away from that. -- -- 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] Git conversion status
Excerpts from Alvaro Herrera's message of mié sep 22 16:57:24 -0400 2010: > Apparently the only difference is that the initial clone needs to be > done with --bare: > git clone --bare ssh://g...@gitmaster.postgresql.org/postgresql.git Okay, it works with --bare --mirror. I'm going to update the wiki with this. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Another Modest Proposal: Platforms
"Joshua D. Drake" writes: > I mean, it took us forever to require Perl 5.8. ... and we still make a point of not having a hard requirement for that. If you don't want plperl, you can build from a tarball with no perl at all. Given the project history, I can't see us turning a dependency we just added this week into a hard requirement anytime soon. Now having said that, if you define "supported platform" to mean "gets tested on the buildfarm", we do require Perl. And CVS, which will soon get replaced by a requirement for Git. But I'm not going to tell someone to get lost if they file a portability bug report without having set up a buildfarm animal first. 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] Why is time with timezone 12 bytes?
On 22 September 2010 22:58, Kenneth Marshall wrote: > On Wed, Sep 22, 2010 at 10:54:53PM +0100, Thom Brown wrote: >> On 22 September 2010 22:01, Josh Berkus wrote: >> > All, >> > >> > I was just checking on our year-2027 compliance, and happened to notice >> > that time with time zone takes up 12 bytes. ?This seems peculiar, given >> > that timestamp with time zone is only 8 bytes, and at my count we only >> > need 5 for the time with microsecond precision. ?What's up with that? >> > >> > Also, what is the real range of our 8-byte *integer* timestamp? >> >> The time is 8 bytes, (1,000,000 microseconds * 60 minutes, * 24 hours >> = 1,440,000,000 microseconds = 31 bits = 8 bytes). >> > > 31 bits = approx. 4 bytes at 8 bits/byte, not 8 bytes. > >> The timezone displacement takes up to 12 bits, meaning 3 bytes. >> (1460+1459 = 2919 = 12 bits = 3 bytes). So that's 11 bytes. Not sure >> where the extra 1 byte comes from. >> > This would yield 7 bytes. I think it's clear I should get some sleep. :S -- 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] Another Modest Proposal: Platforms
On Sep 22, 2010, at 2:08 PM, David Fetter wrote: > It's not about naming platforms for exclusion. It's about requiring > functionalities for *in*clusion. Passes all tests. David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why is time with timezone 12 bytes?
>> Also, what is the real range of our 8-byte *integer* timestamp? > > See the fine manual. I believe the limits have more to do with > calendar arithmetic than with the nominal range of 2^64 microseconds. I'm asking based on that. The docs only give the limits for a *float* timestamp. I'd like to fix the docs, but I can only do it if I have the data ... -- -- 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] Why is time with timezone 12 bytes?
On Wed, Sep 22, 2010 at 10:54:53PM +0100, Thom Brown wrote: > On 22 September 2010 22:01, Josh Berkus wrote: > > All, > > > > I was just checking on our year-2027 compliance, and happened to notice > > that time with time zone takes up 12 bytes. ?This seems peculiar, given > > that timestamp with time zone is only 8 bytes, and at my count we only > > need 5 for the time with microsecond precision. ?What's up with that? > > > > Also, what is the real range of our 8-byte *integer* timestamp? > > The time is 8 bytes, (1,000,000 microseconds * 60 minutes, * 24 hours > = 1,440,000,000 microseconds = 31 bits = 8 bytes). > 31 bits = approx. 4 bytes at 8 bits/byte, not 8 bytes. > The timezone displacement takes up to 12 bits, meaning 3 bytes. > (1460+1459 = 2919 = 12 bits = 3 bytes). So that's 11 bytes. Not sure > where the extra 1 byte comes from. > This would yield 7 bytes. Ken -- 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] Why is time with timezone 12 bytes?
Josh Berkus writes: > I was just checking on our year-2027 compliance, and happened to notice > that time with time zone takes up 12 bytes. This seems peculiar, given > that timestamp with time zone is only 8 bytes, and at my count we only > need 5 for the time with microsecond precision. What's up with that? I think it's an 8-byte seconds count plus 4 bytes to indicate the timezone. If this datatype had any actual real-world use then it might be worth worrying about how big it is, but AFAICS its only excuse for existence is to satisfy the SQL standard. > Also, what is the real range of our 8-byte *integer* timestamp? See the fine manual. I believe the limits have more to do with calendar arithmetic than with the nominal range of 2^64 microseconds. 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] Why is time with timezone 12 bytes?
On 22 September 2010 22:01, Josh Berkus wrote: > All, > > I was just checking on our year-2027 compliance, and happened to notice > that time with time zone takes up 12 bytes. This seems peculiar, given > that timestamp with time zone is only 8 bytes, and at my count we only > need 5 for the time with microsecond precision. What's up with that? > > Also, what is the real range of our 8-byte *integer* timestamp? The time is 8 bytes, (1,000,000 microseconds * 60 minutes, * 24 hours = 1,440,000,000 microseconds = 31 bits = 8 bytes). The timezone displacement takes up to 12 bits, meaning 3 bytes. (1460+1459 = 2919 = 12 bits = 3 bytes). So that's 11 bytes. Not sure where the extra 1 byte comes from. -- 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] Git conversion status
On 09/22/2010 04:55 PM, Tom Lane wrote: (In particular, I'm avoiding Andrew's preferred alternative with the extra local repository; I don't want an asynchronous buffer between me and the real repository. I guess if you had a really bad network connection it could be useful, but considering how much better this is than CVS already, I won't miss whatever savings that might offer.) Oh, yes, the network saving is enormous. What I suggested is much more economical of disk space, though (it's the recommended way to set up the buildfarm for that reason). But maybe that doesn't matter too much to you. 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] Another Modest Proposal: Platforms
On Wed, 2010-09-22 at 14:08 -0700, David Fetter wrote: > It's not about naming platforms for exclusion. It's about requiring > functionalities for *in*clusion. I repeat: > Perhaps you could suggest some more specific ideas of your proposal? I mean, it took us forever to require Perl 5.8. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Another Modest Proposal: Platforms
On Wed, Sep 22, 2010 at 02:02:18PM -0700, Joshua D. Drake wrote: > On Wed, 2010-09-22 at 13:58 -0700, David Fetter wrote: > > On Wed, Sep 22, 2010 at 04:28:04PM -0400, Tom Lane wrote: > > > David Fetter writes: > > > > We can start by supporting only platforms git runs on, this being > > > > the first in what I'd picture as a set of base requirements. > > > > > > Sounds like allowing the tail to wag the dog. > > > > "Runs git" is actually not a bad proxy for "has modern developer > > tools." > > > > This would be the first, as I mentioned, of a list of base functional > > requirements. > > David, > > Perhaps you could suggest some more specific ideas of your proposal? I > mean I am with you on the idea of reducing our supported platforms. I > see no reason to support > > <> SCO > > Note: I am not actually advocating this as much as stating my own > personal opinion. > > Joshua D. Drake It's not about naming platforms for exclusion. It's about requiring functionalities for *in*clusion. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] Another Modest Proposal: Platforms
On Wed, 2010-09-22 at 13:58 -0700, David Fetter wrote: > On Wed, Sep 22, 2010 at 04:28:04PM -0400, Tom Lane wrote: > > David Fetter writes: > > > We can start by supporting only platforms git runs on, this being > > > the first in what I'd picture as a set of base requirements. > > > > Sounds like allowing the tail to wag the dog. > > "Runs git" is actually not a bad proxy for "has modern developer > tools." > > This would be the first, as I mentioned, of a list of base functional > requirements. David, Perhaps you could suggest some more specific ideas of your proposal? I mean I am with you on the idea of reducing our supported platforms. I see no reason to support SCO Note: I am not actually advocating this as much as stating my own personal opinion. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Why is time with timezone 12 bytes?
All, I was just checking on our year-2027 compliance, and happened to notice that time with time zone takes up 12 bytes. This seems peculiar, given that timestamp with time zone is only 8 bytes, and at my count we only need 5 for the time with microsecond precision. What's up with that? Also, what is the real range of our 8-byte *integer* timestamp? -- -- 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] Another Modest Proposal: Platforms
On Wed, Sep 22, 2010 at 04:28:04PM -0400, Tom Lane wrote: > David Fetter writes: > > We can start by supporting only platforms git runs on, this being > > the first in what I'd picture as a set of base requirements. > > Sounds like allowing the tail to wag the dog. "Runs git" is actually not a bad proxy for "has modern developer tools." This would be the first, as I mentioned, of a list of base functional requirements. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] Git conversion status
Excerpts from Alvaro Herrera's message of mié sep 22 16:48:28 -0400 2010: > Excerpts from Aidan Van Dyk's message of mié sep 22 16:20:15 -0400 2010: > > I think what you want in this case (where you have a local "master" > > repositroy, and clone your work of them) is to make your master > > repository just be a bare mirror repo, not a > > full-fledged-with-working-directory repository. If it's just a mirror > > of the remote, it doesn't have the distinction between "remote" > > branches and "local" branches, and your local working clones of it > > will see exactly what it's fetched from the remote. > > Yeah, I think this is what I want. I'll try to see how to make that work. Apparently the only difference is that the initial clone needs to be done with --bare: git clone --bare ssh://g...@gitmaster.postgresql.org/postgresql.git and then the second line (which Robert added yesterday) is not necessary. Now I only need to wait for another commit to come in to test that fetch/pull work ... -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Git conversion status
Robert Haas writes: > On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera > wrote: >> As far as I can see, I need to go to the master clone, run a checkout >> and pull on each branch, and *then* a pull on the local clone updates to >> the latest head on that branch. It is not enough to pull when the >> master branch is checked out. > Ah, crap. You're right. Sucktastic. As far as I can tell so far, the multiple-workdir setup dominates all the others in terms of minimizing the amount of "git pull" monkeywork. You still have to remember to do that (or some equivalent) in each workdir to update that workdir, but that's no worse than with multiple CVS checkout directories. And the amount of network overhead is a LOT less than with multiple CVS checkouts. (In particular, I'm avoiding Andrew's preferred alternative with the extra local repository; I don't want an asynchronous buffer between me and the real repository. I guess if you had a really bad network connection it could be useful, but considering how much better this is than CVS already, I won't miss whatever savings that might offer.) 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] Git conversion status
Excerpts from Aidan Van Dyk's message of mié sep 22 16:20:15 -0400 2010: > On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera > wrote: > > > As far as I can see, I need to go to the master clone, run a checkout > > and pull on each branch, and *then* a pull on the local clone updates to > > the latest head on that branch. It is not enough to pull when the > > master branch is checked out. > > What I think has happened is that you have a master clone, and you've > cloned *that* to your "working" repositories, right? Yep. This is in accord with the instructions written in this section: http://wiki.postgresql.org/wiki/Committing_with_Git#Dependent_Clone_per_Branch.2C_Pushing_and_Pulling_From_a_Local_Repository > And you "pull" in your master repository, and that updates the > *remote* tracking branches. But it doesn't automatically "merge" (or > what you want, replace) the *local* branches of the master repository. > Until you do so. Right. > I think what you want in this case (where you have a local "master" > repositroy, and clone your work of them) is to make your master > repository just be a bare mirror repo, not a > full-fledged-with-working-directory repository. If it's just a mirror > of the remote, it doesn't have the distinction between "remote" > branches and "local" branches, and your local working clones of it > will see exactly what it's fetched from the remote. Yeah, I think this is what I want. I'll try to see how to make that work. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Another Modest Proposal: Platforms
On 09/22/2010 04:38 PM, Robert Haas wrote: On Wed, Sep 22, 2010 at 4:17 PM, David Fetter wrote: What say? "No." :-) I'd be fine with dropping support for ancient platforms if it lets us do something cool that we can't otherwise do, but there's no value in doing it just because we can. Couldn't have said it better. 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] Another Modest Proposal: Platforms
On Wed, Sep 22, 2010 at 4:17 PM, David Fetter wrote: > What say? "No." :-) I'd be fine with dropping support for ancient platforms if it lets us do something cool that we can't otherwise do, but there's no value in doing it just because we can. -- 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] Git conversion status
On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of mar sep 21 13:43:28 -0400 2010: > >> Oops. I left out a step. Fixed. > > Hmm, it still doesn't work. I can pull into the normal clone and it > works, but when I run a "git pull" in one of the local clones, it says > it's up to date even when there are commits that I know should be pulled > in. > > For example: > > $ cd postgresql/ > $ git fetch > remote: Counting objects: 219, done. > remote: Compressing objects: 100% (88/88), done. > remote: Total 89 (delta 77), reused 0 (delta 0) > Unpacking objects: 100% (89/89), done. > From ssh://gitmaster.postgresql.org/postgresql > 6b4453f..da907fd REL7_4_STABLE -> origin/REL7_4_STABLE > 92458c2..da49d16 REL8_0_STABLE -> origin/REL8_0_STABLE > 3fb50a7..706a580 REL8_1_STABLE -> origin/REL8_1_STABLE > adbe80f..c206794 REL8_2_STABLE -> origin/REL8_2_STABLE > c39a381..60591cd REL8_3_STABLE -> origin/REL8_3_STABLE > 35b2f93..2792c82 REL8_4_STABLE -> origin/REL8_4_STABLE > bbf84ac..f23bc1e REL9_0_STABLE -> origin/REL9_0_STABLE > 726f9dd..6c137da master -> origin/master > > $ cd ../REL9_0_STABLE > $ git pull > Current branch REL9_0_STABLE is up to date. > > But I know this is wrong: > > $ git log -1 > commit a6923594114601b4aaaf0cfd82eb5088af837664 > Author: Magnus Hagander > Date: Wed Sep 22 12:57:06 2010 +0200 > > Convert cvsignore to gitignore, and add .gitignore for build targets. > > $ cd ../postgresql > $ git checkout REL9_0_STABLE > Checking out files: 100% (2415/2415), done. > Switched to branch 'REL9_0_STABLE' > Your branch is behind 'origin/REL9_0_STABLE' by 2 commits, and can be > fast-forwarded. > $ git pull > [ lotsa output ] > > $ git log -1 > commit f23bc1e8a42cab50c204bbab837f95cbc2353311 > Author: Magnus Hagander > Date: Wed Sep 22 21:49:07 2010 +0200 > > Add gitignore files for ecpg regression tests. > > Backpatch to 8.2 as that's how far the structure looks the same. > > > > As far as I can see, I need to go to the master clone, run a checkout > and pull on each branch, and *then* a pull on the local clone updates to > the latest head on that branch. It is not enough to pull when the > master branch is checked out. Ah, crap. You're right. Sucktastic. -- 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] Another Modest Proposal: Platforms
David Fetter writes: > We can start by supporting only platforms git runs on, this being the > first in what I'd picture as a set of base requirements. Sounds like allowing the tail to wag the dog. 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] Another Modest Proposal: Platforms
On Wed, 2010-09-22 at 13:17 -0700, David Fetter wrote: > Folks, > > While it's interesting to note, in an historical sense, that a > platform most recently updated when 1999 was still in the future, I > think it's time we did a little pruning. > > We can start by supporting only platforms git runs on, this being the > first in what I'd picture as a set of base requirements. > > What say? > I say that Bruce got Git to run on BSD/OS 4 or something like that. I suggest that it won't matter what we say :P JD > Cheers, > David. > -- > David Fetter http://fetter.org/ > Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter > Skype: davidfetter XMPP: david.fet...@gmail.com > iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics > > Remember to vote! > Consider donating to Postgres: http://www.postgresql.org/about/donate > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Another Modest Proposal: Platforms
On Wed, Sep 22, 2010 at 01:17:54PM -0700, David Fetter wrote: > Folks, > > While it's interesting to note, in an historical sense, that a > platform most recently updated when 1999 was still in the future, I > think it's time we did a little pruning. > > We can start by supporting only platforms git runs on, this being the > first in what I'd picture as a set of base requirements. > > What say? > > Cheers, > David. Given the amount of trouble I had to get a git for a Solaris 8 system, I am not too keen on this definition for platform. PostgreSQL runs very well on the same system, along with SVN and CVS. Cheers, Ken -- 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] Another Modest Proposal: Platforms
On 9/22/10 1:17 PM, David Fetter wrote: > While it's interesting to note, in an historical sense, that a > platform most recently updated when 1999 was still in the future, I > think it's time we did a little pruning. It is unclear to me what problem you're trying to solve. -- -- 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] Git conversion status
On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera wrote: > As far as I can see, I need to go to the master clone, run a checkout > and pull on each branch, and *then* a pull on the local clone updates to > the latest head on that branch. It is not enough to pull when the > master branch is checked out. What I think has happened is that you have a master clone, and you've cloned *that* to your "working" repositories, right? And you "pull" in your master repository, and that updates the *remote* tracking branches. But it doesn't automatically "merge" (or what you want, replace) the *local* branches of the master repository. Until you do so. I think what you want in this case (where you have a local "master" repositroy, and clone your work of them) is to make your master repository just be a bare mirror repo, not a full-fledged-with-working-directory repository. If it's just a mirror of the remote, it doesn't have the distinction between "remote" branches and "local" branches, and your local working clones of it will see exactly what it's fetched from the remote. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Another Modest Proposal: Platforms
Folks, While it's interesting to note, in an historical sense, that a platform most recently updated when 1999 was still in the future, I think it's time we did a little pruning. We can start by supporting only platforms git runs on, this being the first in what I'd picture as a set of base requirements. What say? Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] Opening a plpgsql cursor parameter by name
Tom Lane wrote:
Yeb Havinga writes:
We intend to implement $subject, so instead of mycursor CURSOR (myparm text) IS
SELECT myparm; OPEN mycursor('A'); it would be possible to do OPEN
mycursor(myparm := 'A');
Is this really worth the trouble? Is it supported by any other DBMS?
Are cursors used so much, or with so many parameters, that there's a
real benefit to be gained? (I tend to think that FOR loops are better
than cursors 99% of the time.)
Thanks for your reply.
For us it is worth the trouble. We must either implement this, or
manually rewrite cursor use in 140K lines of PL code to be migrated from
another DBMS, where cursors are used more with named parameters calling
than positional. The code contains both the OPEN mycursor(myparm => 'A')
syntax as well as FOR rec IN mycursor(myparm => 'A') LOOP ... (but not
FOR rec IN SELECT .. LOOP)).
I wouldn't be so obstructionist if this syntax weren't in flux.
But seeing that we have hopes of migrating from := to => before
very long, adding another dependency on that choice where it's
not buying a lot of functionality doesn't seem like a good idea.
So maybe it's a good idea that we use the => syntax and do not submit
the patch before the := to => migration is done.
regards,
Yeb Havinga
--
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 bikeshedding
On Wed, 2010-09-22 at 21:05 +0100, Thom Brown wrote: > On 22 September 2010 19:50, Josh Berkus wrote: > > All: > > > > I feel compelled to point out that, to date, there have been three times > > as many comments on what format the configuration file should be as > > there have been on what options it should support and how large numbers > > of replicas should be managed. > > I know, it's terrible!... I think it should be green. Remove the shadow please. > > -- > Thom Brown > Twitter: @darkixion > IRC (freenode): dark_ixion > Registered Linux user: #516935 > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Configuring synchronous bikeshedding
On 22 September 2010 19:50, Josh Berkus wrote: > All: > > I feel compelled to point out that, to date, there have been three times > as many comments on what format the configuration file should be as > there have been on what options it should support and how large numbers > of replicas should be managed. I know, it's terrible!... I think it should be green. -- 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] Git conversion status
Excerpts from Robert Haas's message of mar sep 21 13:43:28 -0400 2010: > Oops. I left out a step. Fixed. Hmm, it still doesn't work. I can pull into the normal clone and it works, but when I run a "git pull" in one of the local clones, it says it's up to date even when there are commits that I know should be pulled in. For example: $ cd postgresql/ $ git fetch remote: Counting objects: 219, done. remote: Compressing objects: 100% (88/88), done. remote: Total 89 (delta 77), reused 0 (delta 0) Unpacking objects: 100% (89/89), done. >From ssh://gitmaster.postgresql.org/postgresql 6b4453f..da907fd REL7_4_STABLE -> origin/REL7_4_STABLE 92458c2..da49d16 REL8_0_STABLE -> origin/REL8_0_STABLE 3fb50a7..706a580 REL8_1_STABLE -> origin/REL8_1_STABLE adbe80f..c206794 REL8_2_STABLE -> origin/REL8_2_STABLE c39a381..60591cd REL8_3_STABLE -> origin/REL8_3_STABLE 35b2f93..2792c82 REL8_4_STABLE -> origin/REL8_4_STABLE bbf84ac..f23bc1e REL9_0_STABLE -> origin/REL9_0_STABLE 726f9dd..6c137da master -> origin/master $ cd ../REL9_0_STABLE $ git pull Current branch REL9_0_STABLE is up to date. But I know this is wrong: $ git log -1 commit a6923594114601b4aaaf0cfd82eb5088af837664 Author: Magnus Hagander Date: Wed Sep 22 12:57:06 2010 +0200 Convert cvsignore to gitignore, and add .gitignore for build targets. $ cd ../postgresql $ git checkout REL9_0_STABLE Checking out files: 100% (2415/2415), done. Switched to branch 'REL9_0_STABLE' Your branch is behind 'origin/REL9_0_STABLE' by 2 commits, and can be fast-forwarded. $ git pull [ lotsa output ] $ git log -1 commit f23bc1e8a42cab50c204bbab837f95cbc2353311 Author: Magnus Hagander Date: Wed Sep 22 21:49:07 2010 +0200 Add gitignore files for ecpg regression tests. Backpatch to 8.2 as that's how far the structure looks the same. As far as I can see, I need to go to the master clone, run a checkout and pull on each branch, and *then* a pull on the local clone updates to the latest head on that branch. It is not enough to pull when the master branch is checked out. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] .gitignore files, take two
On Wed, Sep 22, 2010 at 20:38, Tom Lane wrote: > Magnus Hagander writes: >> On Wed, Sep 22, 2010 at 20:28, Kevin Grittner >> wrote: >>> Magnus Hagander wrote: >>> >> Done and applied. >>> >>> I just did `make world`, `make check`, `sudo make install-world`, and >>> `make installcheck-world`. I was left with these showing in my `git >>> status`: > >> Ahh. Clearly I didn't run the regression tests for contrib and ecpg. > >> I'll take a look at that. > > I'm on it already for contrib and the PLs. But if you wanna do ecpg, > that'd be helpful, because I forgot about that ... Done. -- 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] Configuring synchronous replication
Tom Lane wrote: Robert Haas writes: On Wed, Sep 22, 2010 at 1:09 PM, Joshua D. Drake wrote: On Wed, 2010-09-22 at 13:00 -0400, Robert Haas wrote: But it CAN'T be a system catalog, because, among other problems, that rules out cascading slaves, which are a feature a lot of people probably want to eventually have. I guarantee you there is a way around the cascade slave problem. And that would be...? Indeed. If it's a catalog then it has to be exactly the same on the master and every slave; which is probably a constraint we don't want for numerous reasons, not only cascade arrangements. It might be an idea to store the replication information outside of all clusters involved in the replication, to not depend on any failure of the master or any of the slaves. We've been using Apache's zookeeper http://hadoop.apache.org/zookeeper/ to keep track of configuration-like knowledge that must be distributed over a number of servers. While Zookeeper itself is probably not fit (java) to use in core Postgres to keep track of configuration information, what it provides seems like the perfect solution, especially group membership and a replicated directory-like database (with per directory node a value). regards, Yeb Havinga -- 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 21:57, I wrote: 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? Ok, I think I've come up with a scheme that puts an upper bound on the amount of shared memory used, wrt. number of transactions. You can still run out of shared memory if you lock a lot of objects, but that doesn't worry me as much. When a transaction is commits, its predicate locks must be held, but it's not important anymore *who* holds them, as long as they're hold for long enough. Let's move the finishedBefore field from SERIALIZABLEXACT to PREDICATELOCK. When a transaction commits, set the finishedBefore field in all the PREDICATELOCKs it holds, and then release the SERIALIZABLEXACT struct. The predicate locks stay without an associated SERIALIZABLEXACT entry until finishedBefore expires. Whenever there are two predicate locks on the same target that both belonged to an already-committed transaction, the one with a smaller finishedBefore can be dropped, because the one with higher finishedBefore value covers it already. There. That was surprisingly simple, I must be missing something. -- 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 bikeshedding
All: I feel compelled to point out that, to date, there have been three times as many comments on what format the configuration file should be as there have been on what options it should support and how large numbers of replicas should be managed. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com P.S. You folks aren't imaginative enough. Tab-delimited files. Random dot images. Ogham! -- 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
"Joshua D. Drake" writes: > Unless I am missing something the catalog only needs information for its > specific cluster. E.g; My Master is, I am master for. I think the "cluster" here is composed of all and any server partaking into the replication network, whatever its role and cascading level, because we only support one master. As soon as the setup is replicated too, you can edit the setup from the one true master and from nowhere else, so the single authority must contain the whole setup. Now that doesn't mean all lines in the setup couldn't refer to a provider which could be different from the master in the case of cascading. What I don't understand is why the replication network topology can't get serialized into a catalog? Then again, assuming that a catalog ain't possible, I guess any file based setup will mean manual syncing of the whole setup at all the servers participating in the replication? If that's the case, I'll say it again, it looks like a nightmare to admin and I'd much prefer having a distributed setup, where any standby's setup is simple and directed to a single remote node, its provider. Please note also that such an arrangement doesn't preclude from having a way to register the standbys (automatically please) and requiring some action to enable the replication from their provider, and possibly from the master. But as there's already the hba to setup, I'd think paranoid sites are covered already. Regards, -- dim -- 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] .gitignore files, take two
Magnus Hagander writes: > On Wed, Sep 22, 2010 at 20:28, Kevin Grittner > wrote: >> Magnus Hagander wrote: >> > Done and applied. >> >> I just did `make world`, `make check`, `sudo make install-world`, and >> `make installcheck-world`. I was left with these showing in my `git >> status`: > Ahh. Clearly I didn't run the regression tests for contrib and ecpg. > I'll take a look at that. I'm on it already for contrib and the PLs. But if you wanna do ecpg, that'd be helpful, because I forgot about 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] .gitignore files, take two
On Wed, Sep 22, 2010 at 20:28, Kevin Grittner wrote: > Magnus Hagander wrote: > >> Done and applied. > > I just did `make world`, `make check`, `sudo make install-world`, and > `make installcheck-world`. I was left with these showing in my `git > status`: Ahh. Clearly I didn't run the regression tests for contrib and ecpg. I'll take a look at that. -- 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] .gitignore files, take two
Magnus Hagander wrote: > Done and applied. I just did `make world`, `make check`, `sudo make install-world`, and `make installcheck-world`. I was left with these showing in my `git status`: # Untracked files: # (use "git add ..." to include in what will be committed) # # contrib/btree_gin/results/ # contrib/btree_gist/results/ # contrib/citext/results/ # contrib/cube/results/ # contrib/dblink/results/ # contrib/dict_int/results/ # contrib/dict_xsyn/results/ # contrib/earthdistance/results/ # contrib/hstore/results/ # contrib/intarray/results/ # contrib/ltree/results/ # contrib/pg_trgm/results/ # contrib/pgcrypto/results/ # contrib/seg/results/ # contrib/tablefunc/results/ # contrib/test_parser/results/ # contrib/tsearch2/results/ # contrib/unaccent/results/ # contrib/xml2/pgxml.sql # contrib/xml2/results/ # doc/src/sgml/HTML.index # doc/src/sgml/bookindex.sgml # doc/src/sgml/postgres.xml # src/interfaces/ecpg/test/compat_informix/charfuncs # src/interfaces/ecpg/test/compat_informix/charfuncs.c # src/interfaces/ecpg/test/compat_informix/dec_test # src/interfaces/ecpg/test/compat_informix/dec_test.c # src/interfaces/ecpg/test/compat_informix/describe # src/interfaces/ecpg/test/compat_informix/describe.c # src/interfaces/ecpg/test/compat_informix/rfmtdate # src/interfaces/ecpg/test/compat_informix/rfmtdate.c # src/interfaces/ecpg/test/compat_informix/rfmtlong # src/interfaces/ecpg/test/compat_informix/rfmtlong.c # src/interfaces/ecpg/test/compat_informix/rnull # src/interfaces/ecpg/test/compat_informix/rnull.c # src/interfaces/ecpg/test/compat_informix/sqlda # src/interfaces/ecpg/test/compat_informix/sqlda.c # src/interfaces/ecpg/test/compat_informix/test_informix # src/interfaces/ecpg/test/compat_informix/test_informix.c # src/interfaces/ecpg/test/compat_informix/test_informix2 # src/interfaces/ecpg/test/compat_informix/test_informix2.c # src/interfaces/ecpg/test/connect/test1 # src/interfaces/ecpg/test/connect/test1.c # src/interfaces/ecpg/test/connect/test2 # src/interfaces/ecpg/test/connect/test2.c # src/interfaces/ecpg/test/connect/test3 # src/interfaces/ecpg/test/connect/test3.c # src/interfaces/ecpg/test/connect/test4 # src/interfaces/ecpg/test/connect/test4.c # src/interfaces/ecpg/test/connect/test5 # src/interfaces/ecpg/test/connect/test5.c # src/interfaces/ecpg/test/pg_regress # src/interfaces/ecpg/test/pgtypeslib/dt_test # src/interfaces/ecpg/test/pgtypeslib/dt_test.c # src/interfaces/ecpg/test/pgtypeslib/dt_test2 # src/interfaces/ecpg/test/pgtypeslib/dt_test2.c # src/interfaces/ecpg/test/pgtypeslib/nan_test # src/interfaces/ecpg/test/pgtypeslib/nan_test.c # src/interfaces/ecpg/test/pgtypeslib/num_test # src/interfaces/ecpg/test/pgtypeslib/num_test.c # src/interfaces/ecpg/test/pgtypeslib/num_test2 #
Re: [HACKERS] Configuring synchronous replication
On Wed, 2010-09-22 at 13:26 -0400, Tom Lane wrote: > Robert Haas writes: > > On Wed, Sep 22, 2010 at 1:09 PM, Joshua D. Drake > > wrote: > >> On Wed, 2010-09-22 at 13:00 -0400, Robert Haas wrote: > >>> But it CAN'T be a system catalog, because, among other problems, that > >>> rules out cascading slaves, which are a feature a lot of people > >>> probably want to eventually have. > >> > >> I guarantee you there is a way around the cascade slave problem. > > > And that would be...? > > Indeed. If it's a catalog then it has to be exactly the same on the > master and every slave; which is probably a constraint we don't want > for numerous reasons, not only cascade arrangements. Unless I am missing something the catalog only needs information for its specific cluster. E.g; My Master is, I am master for. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Configuring synchronous replication
Robert Haas writes: > On Wed, Sep 22, 2010 at 1:09 PM, Joshua D. Drake > wrote: >> On Wed, 2010-09-22 at 13:00 -0400, Robert Haas wrote: >>> But it CAN'T be a system catalog, because, among other problems, that >>> rules out cascading slaves, which are a feature a lot of people >>> probably want to eventually have. >> >> I guarantee you there is a way around the cascade slave problem. > And that would be...? Indeed. If it's a catalog then it has to be exactly the same on the master and every slave; which is probably a constraint we don't want for numerous reasons, not only cascade arrangements. 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] snapshot generation broken
On Wed, Sep 22, 2010 at 19:23, Tom Lane wrote: > Magnus Hagander writes: >> On Wed, Sep 22, 2010 at 17:08, Tom Lane wrote: >>> Sure, I can look. Where are these tarballs anyway? > >> They're up on the ftp site - ftp://ftp.postgresql.org/pub/snapshot/. >> dev and stable/8.4 are updated. > > Both of those look pretty sane from here. Ok, I've re-enabled the cron job. -- 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] snapshot generation broken
Magnus Hagander writes: > On Wed, Sep 22, 2010 at 17:08, Tom Lane wrote: >> Sure, I can look. Where are these tarballs anyway? > They're up on the ftp site - ftp://ftp.postgresql.org/pub/snapshot/. > dev and stable/8.4 are updated. Both of those look pretty sane from here. 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] moving development branch activity to new git repo
"Kevin Grittner" wrote: > Well, that didn't work much better. I decided I'd reached my limit on this. I fell back to a suggestion made a while back, and just created a patch from the old repository and applied it to the new one. I've pushed it to the public repo, but haven't yet had a chance to confirm that all is well. I will keep the old repo in case there is any need to prove the development history. (Unlikely, but it seems prudent to cover the bases.) So, no further advice on this topic needed here. -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] Configuring synchronous replication
On Wed, Sep 22, 2010 at 1:09 PM, Joshua D. Drake wrote: > On Wed, 2010-09-22 at 13:00 -0400, Robert Haas wrote: > >> > I mean really? >> > >> > ALTER CLUSTER ENABLE [SYNC] REPLICATION ON db.foobar.com PORT 5432 ALIAS >> > CRITICAL; >> > ALTER CLUSTER SET REPLICATION CRITICAL RECEIVE FOR 2; >> > ALTER CLUSTER SET REPLICATION CRITICAL FSYNC FOR 2; >> > ALTER CLUSTER SET REPLICATION CRITICAL REPLAY FOR 2; >> > >> > Or some such thing. I saw Heiiki's reply but really the idea that we are >> > shoving this all into the postgresql.conf is cumbersome. >> >> I think it should be a separate config file, and I think it should be >> a config file that can be edited using DDL commands as you propose. >> But it CAN'T be a system catalog, because, among other problems, that >> rules out cascading slaves, which are a feature a lot of people >> probably want to eventually have. > > I guarantee you there is a way around the cascade slave problem. And that would be...? -- 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] Configuring synchronous replication
On 22/09/10 20:02, Heikki Linnakangas wrote: On 22/09/10 20:00, Robert Haas wrote: But it CAN'T be a system catalog, because, among other problems, that rules out cascading slaves, which are a feature a lot of people probably want to eventually have. FWIW it could be a system catalog backed by a flat file. But I'm not in favor of that for the other reasons I stated earlier. Huh, I just realized that my reply didn't make any sense. For some reason I thought you were saying that it can't be a catalog because backends need to access it without attaching to a database. -- 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
Heikki Linnakangas wrote: > On 22/09/10 20:00, Robert Haas wrote: > > But it CAN'T be a system catalog, because, among other problems, that > > rules out cascading slaves, which are a feature a lot of people > > probably want to eventually have. > > FWIW it could be a system catalog backed by a flat file. But I'm not in > favor of that for the other reasons I stated earlier. I thought we just eliminated flat file backing store for tables to improve replication behavior --- I don't see returning to that as a win. -- 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] Documentation, window functions
Excerpts from Hitoshi Harada's message of mié sep 22 12:54:45 -0400 2010: > > Maybe we can find some better wording of the above? > > Your point is true, but I believe it's still ok because the section is > a tutorial for novices. If you start to explain everything here, > readers don't want to read it to the end. We had this exact question in the spanish list two weeks ago. I also suggest that we need to explain this a bit more explicitely. Actually the spanish question involved a PARTITION BY / ORDER BY clause, and the difference showed up not because of the existance of ORDER BY alone, but by whether the ORDER BY had the same columns than PARTITION BY or more. Here it is: http://archives.postgresql.org/message-id/of7db68f53.5da80480-on8625779f.0058b555-8625779f.00591...@correogs.com.mx (The archive is a bit confusing because the results appear as images at the bottom of the email, instead of being interspersed with the text.) -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Configuring synchronous replication
On Wed, 2010-09-22 at 13:00 -0400, Robert Haas wrote: > > I mean really? > > > > ALTER CLUSTER ENABLE [SYNC] REPLICATION ON db.foobar.com PORT 5432 ALIAS > > CRITICAL; > > ALTER CLUSTER SET REPLICATION CRITICAL RECEIVE FOR 2; > > ALTER CLUSTER SET REPLICATION CRITICAL FSYNC FOR 2; > > ALTER CLUSTER SET REPLICATION CRITICAL REPLAY FOR 2; > > > > Or some such thing. I saw Heiiki's reply but really the idea that we are > > shoving this all into the postgresql.conf is cumbersome. > > I think it should be a separate config file, and I think it should be > a config file that can be edited using DDL commands as you propose. > But it CAN'T be a system catalog, because, among other problems, that > rules out cascading slaves, which are a feature a lot of people > probably want to eventually have. I guarantee you there is a way around the cascade slave problem. I believe there will be "some" postgresql.conf pollution. I don't see any other way around that but the conf should be limited to things that literally have to be expressed in a conf for specific static purposes. I was talking with Bruce on Jabber and one of his concerns with my approach is "polluting the SQL space for non-admins". I certainly appreciate that my solution puts code in more places and that it may be more of a burden for the hackers. However, we aren't building this for hackers. Most hackers don't even use the product. We are building it for our community, which are by far user space developers and dbas. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Configuring synchronous replication
On Wed, Sep 22, 2010 at 8:12 AM, Simon Riggs wrote: Not speaking to the necessity of standby registration, but... >> Thinking of this as a sysadmin, what I want is to have *one place* I can >> go an troubleshoot my standby setup. If I have 12 synch standbys and >> they're creating too much load on the master, and I want to change half >> of them to async, I don't want to have to ssh into 6 different machines >> to do so. If one standby needs to be taken out of the network because >> it's too slow, I want to be able to log in to the master and instantly >> identify which standby is lagging and remove it there. > > The above case is one where I can see your point and it does sound > easier in that case. But I then think: "What happens after failover?". > We would then need to have 12 different standby.conf files, one on each > standby that describes what the setup would look like if that standby > became the master. And guess what, every time we made a change on the > master, you'd need to re-edit all 12 standby.conf files to reflect the > new configuration. So we're still back to having to edit in multiple > places, ISTM. An interesting option here might be to have "replication.conf" (instead of standby.conf) which would list all servers, and a postgresql.conf setting which would set the "local name" the master would then ignore. Then all PG servers (master+slave) would be able to have identical replication.conf files, only having to know their own "name". Their own name could be GUC, from postgresql.conf, or from command line options, or default to hostname, whatever. -- 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 22/09/10 20:00, Robert Haas wrote: But it CAN'T be a system catalog, because, among other problems, that rules out cascading slaves, which are a feature a lot of people probably want to eventually have. FWIW it could be a system catalog backed by a flat file. But I'm not in favor of that for the other reasons I stated earlier. -- 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 Wed, Sep 22, 2010 at 12:51 PM, Joshua D. Drake
wrote:
> On Wed, 2010-09-22 at 17:43 +0100, Thom Brown wrote:
>
>> So...
>>
>> sync_rep_services = {critical: recv=2, fsync=2, replay=1;
>> important: fsync=3;
>> reporting: recv=2, apply=1}
>>
>> becomes ...
>>
>> sync_rep_services.critical.recv = 2
>> sync_rep_services.critical.fsync = 2
>> sync_rep_services.critical.replay = 2
>> sync_rep_services.important.fsync = 3
>> sync_rep_services.reporting.recv = 2
>> sync_rep_services.reporting.apply = 1
>>
>> I actually started to give this example to demonstrate how cumbersome
>> it would look... but now that I've just typed it out, I've changed my
>> mind. I actually like it!
>
> With respect, this is ugly. Very ugly. Why do we insist on cryptic
> parameters within a config file which should be set within the database
> by a super user.
>
> I mean really?
>
> ALTER CLUSTER ENABLE [SYNC] REPLICATION ON db.foobar.com PORT 5432 ALIAS
> CRITICAL;
> ALTER CLUSTER SET REPLICATION CRITICAL RECEIVE FOR 2;
> ALTER CLUSTER SET REPLICATION CRITICAL FSYNC FOR 2;
> ALTER CLUSTER SET REPLICATION CRITICAL REPLAY FOR 2;
>
> Or some such thing. I saw Heiiki's reply but really the idea that we are
> shoving this all into the postgresql.conf is cumbersome.
I think it should be a separate config file, and I think it should be
a config file that can be edited using DDL commands as you propose.
But it CAN'T be a system catalog, because, among other problems, that
rules out cascading slaves, which are a feature a lot of people
probably want to eventually have.
--
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] Standby registration
On Wed, Sep 22, 2010 at 10:19 AM, Heikki Linnakangas wrote: >>> Should we allow multiple standbys with the same name to connect to >>> the master? >> >> No. The point of naming them is to uniquely identify them. > > Hmm, that situation can arise if there's a network glitch which leads the > standby to disconnect, but the master still considers the connection as > alive. When the standby reconnects, the master will see two simultaneous > connections from the same standby. In that scenario, you clearly want to > disconnect the old connetion in favor of the new one. Is there a scenario > where you'd want to keep the old connection instead and refuse the new one? $Bob turns restores a backup image of the slave to test some new stuff in a dev environment, and it automatically connects. Thanks to IPv4 and the NAT often necessary, they both *appear* to the real master as the same IP address, even though, in the remote campus, they are on to seperate "networks", all NATed through the 1 IP address... Now, that's not (likely) to happen in a "sync rep" situation, but for an async setup, and standby registration automatically being able to keep WAL, etc, satellite offices with occasional network hickups (and developper above mentioned developer VMs) make registration (and centralized monitoring of the slaves) very interesting... a. -- 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
2010/9/22 Dennis Björklund : > In > > http://www.postgresql.org/docs/9.0/static/tutorial-window.html > > it say > > "Although avg will produce the same result no matter what order it > processes the partition's rows in, this is not true of all window > functions. When needed, you can control that order using ORDER BY within > OVER." > > While it's true that avg() produce the same result no matter what order. A > ORDER BY clause will affect what rows are included in the computation and > thus change the result (the default window frame is > RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW). So one can not in > general add an ORDER BY to the example in the tutorial and get the same > result as without an ORDER BY. > > Maybe we can find some better wording of the above? Your point is true, but I believe it's still ok because the section is a tutorial for novices. If you start to explain everything here, readers don't want to read it to the end. 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] Multi-branch committing in git, revisited
Robert Haas wrote: > > What is it about add/deletes that it doesn't do? ?Is the problem 'git > > add' creates a stage already? ?How is that a problem? > > Tom is slightly incorrect. Deletions work fine with git commit -a. > git already knows about the files, so everything just works. However, > it won't pick up on added files, because it can't distinguish between > a file that you want added to the repository and a stray file you left > lying around and assumes the latter. But I don't see that this takes > anything away from your point. You can certainly just work on the OK, so I just somehow made a valid git suggestion. I think I need to lay down. :-O > patch in each repository separately and then commit everything all at > once at the end, if you're so inclined. Of course, as Tom points out, > it's a lot nicer to apply patches in a way that allows git to try to > auto-merge for you. Sometimes it works, and when it doesn't work > having the merge conflict stuff in the file is still better than > having a .rej hunk leftover that you have to figure out what to do > with. So personally I don't intend to do it that way, but as Larry > Wall said about Perl, There's More Than One Way To Do It. My back-patches are usually super-simple (everyone laughs) so my patch files are trival to apply. -- 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] Configuring synchronous replication
On Wed, 2010-09-22 at 17:43 +0100, Thom Brown wrote:
> So...
>
> sync_rep_services = {critical: recv=2, fsync=2, replay=1;
> important: fsync=3;
> reporting: recv=2, apply=1}
>
> becomes ...
>
> sync_rep_services.critical.recv = 2
> sync_rep_services.critical.fsync = 2
> sync_rep_services.critical.replay = 2
> sync_rep_services.important.fsync = 3
> sync_rep_services.reporting.recv = 2
> sync_rep_services.reporting.apply = 1
>
> I actually started to give this example to demonstrate how cumbersome
> it would look... but now that I've just typed it out, I've changed my
> mind. I actually like it!
With respect, this is ugly. Very ugly. Why do we insist on cryptic
parameters within a config file which should be set within the database
by a super user.
I mean really?
ALTER CLUSTER ENABLE [SYNC] REPLICATION ON db.foobar.com PORT 5432 ALIAS
CRITICAL;
ALTER CLUSTER SET REPLICATION CRITICAL RECEIVE FOR 2;
ALTER CLUSTER SET REPLICATION CRITICAL FSYNC FOR 2;
ALTER CLUSTER SET REPLICATION CRITICAL REPLAY FOR 2;
Or some such thing. I saw Heiiki's reply but really the idea that we are
shoving this all into the postgresql.conf is cumbersome.
Sincerely,
Joshua D. Drake
--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] snapshot generation broken
On Wed, Sep 22, 2010 at 17:08, Tom Lane wrote: > Magnus Hagander writes: >> On Wed, Sep 22, 2010 at 16:50, Tom Lane wrote: >>> Do you still need someone to do that, and what do you want done exactly? > >> Just a second set of eyes that the output looks reasonable for being a >> snapshot generated now. > > Sure, I can look. Where are these tarballs anyway? They're up on the ftp site - ftp://ftp.postgresql.org/pub/snapshot/. dev and stable/8.4 are updated. -- 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] Multi-branch committing in git, revisited
On Wed, Sep 22, 2010 at 12:40 PM, Bruce Momjian wrote: > Tom Lane wrote: >> Bruce Momjian writes: >> > There is no need for 'git add' because once you are done you can use git >> > commmit -a in each branch to add all modifications and commit them. >> >> git commit -a is not a universal solution. In particular, the patch >> I was dealing with yesterday involved additions and removals of files, >> neither of which will be implemented by git commit -a. > > Uh, why is that? I see -a saying: > > -a, --all > Tell the command to automatically stage files that > have been modified and deleted, but new files you have > not told git about are not affected. > > What is it about add/deletes that it doesn't do? Is the problem 'git > add' creates a stage already? How is that a problem? Tom is slightly incorrect. Deletions work fine with git commit -a. git already knows about the files, so everything just works. However, it won't pick up on added files, because it can't distinguish between a file that you want added to the repository and a stray file you left lying around and assumes the latter. But I don't see that this takes anything away from your point. You can certainly just work on the patch in each repository separately and then commit everything all at once at the end, if you're so inclined. Of course, as Tom points out, it's a lot nicer to apply patches in a way that allows git to try to auto-merge for you. Sometimes it works, and when it doesn't work having the merge conflict stuff in the file is still better than having a .rej hunk leftover that you have to figure out what to do with. So personally I don't intend to do it that way, but as Larry Wall said about Perl, There's More Than One Way To Do 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] Configuring synchronous replication
Thom Brown wrote:
> On 22 September 2010 17:23, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> [server]
> >> guc=value
> >>
> >> or
> >>
> >> server.guc=value
> > ?
> >
> > Yes, this was my idea too. ?It uses our existing config file format.
> >
>
> So...
>
> sync_rep_services = {critical: recv=2, fsync=2, replay=1;
> important: fsync=3;
> reporting: recv=2, apply=1}
>
> becomes ...
>
> sync_rep_services.critical.recv = 2
> sync_rep_services.critical.fsync = 2
> sync_rep_services.critical.replay = 2
> sync_rep_services.important.fsync = 3
> sync_rep_services.reporting.recv = 2
> sync_rep_services.reporting.apply = 1
>
> I actually started to give this example to demonstrate how cumbersome
> it would look... but now that I've just typed it out, I've changed my
> mind. I actually like it!
It can be prone to mistyping, but it seems simple enough. We already
through a nice error for mistypes in the sever logs. :-)
I don't think we support 3rd level specifications, but we could. Looks
very Java-ish.
--
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] Git cvsserver serious issue
At 2010-09-22 19:21:45 +0300, pete...@gmx.net wrote: > > Well, let's see. If someone can figure out the git equivalent of > > if cvs -q update | egrep -q '^(U|P) '; then > # ... something changed, so run the update ... > fi I think you want: git pull if [ $(git rev-parse HEAD) != $(git rev-parse ORIG_HEAD) ]; then # ... the pull changed something ... fi -- ams -- 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] Git cvsserver serious issue
Excerpts from Peter Eisentraut's message of mié sep 22 12:21:45 -0400 2010: > Well, let's see. If someone can figure out the git equivalent of > > if cvs -q update | egrep -q '^(U|P) '; then > # ... something changed, so run the update ... > fi > > (assuming, for simplicity, that the current directory has the > appropriate branch checked out already) > > then I might be able to get this fixed. Would it work to save the previous commit hash in a file and compare to the current one? -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Configuring synchronous replication
On 22 September 2010 17:23, Bruce Momjian wrote:
> Robert Haas wrote:
>> [server]
>> guc=value
>>
>> or
>>
>> server.guc=value
>
>
> Yes, this was my idea too. It uses our existing config file format.
>
So...
sync_rep_services = {critical: recv=2, fsync=2, replay=1;
important: fsync=3;
reporting: recv=2, apply=1}
becomes ...
sync_rep_services.critical.recv = 2
sync_rep_services.critical.fsync = 2
sync_rep_services.critical.replay = 2
sync_rep_services.important.fsync = 3
sync_rep_services.reporting.recv = 2
sync_rep_services.reporting.apply = 1
I actually started to give this example to demonstrate how cumbersome
it would look... but now that I've just typed it out, I've changed my
mind. I actually like it!
--
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] Git cvsserver serious issue
On Wed, Sep 22, 2010 at 12:21 PM, Peter Eisentraut wrote: > On ons, 2010-09-22 at 16:03 +0200, Magnus Hagander wrote: >> That basically means that git-cvsserver is completely useless in a >> public scenario as it stands. An easier way to DOS our server is hard >> to find, really. >> >> Now, if we can limit this by IP address, that would be ok. I assume we >> can do this for the NLS stuff - peter? > > Well, let's see. If someone can figure out the git equivalent of > > if cvs -q update | egrep -q '^(U|P) '; then > # ... something changed, so run the update ... > fi > > (assuming, for simplicity, that the current directory has the > appropriate branch checked out already) > > then I might be able to get this fixed. Can you just check whether the commit SHA of HEAD has changed? e.g. git show-ref --heads -s master git log --format=format:%H -n 1 master ...and compare with previous results of same? -- 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] Multi-branch committing in git, revisited
Tom Lane wrote: > Bruce Momjian writes: > > There is no need for 'git add' because once you are done you can use git > > commmit -a in each branch to add all modifications and commit them. > > git commit -a is not a universal solution. In particular, the patch > I was dealing with yesterday involved additions and removals of files, > neither of which will be implemented by git commit -a. Uh, why is that? I see -a saying: -a, --all Tell the command to automatically stage files that have been modified and deleted, but new files you have not told git about are not affected. What is it about add/deletes that it doesn't do? Is the problem 'git add' creates a stage already? How is that a problem? -- 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] Configuring synchronous replication
Robert Haas wrote: > [server] > guc=value > > or > > server.guc=value Yes, this was my idea too. It uses our existing config file format. -- 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] Git cvsserver serious issue
On ons, 2010-09-22 at 16:03 +0200, Magnus Hagander wrote: > That basically means that git-cvsserver is completely useless in a > public scenario as it stands. An easier way to DOS our server is hard > to find, really. > > Now, if we can limit this by IP address, that would be ok. I assume we > can do this for the NLS stuff - peter? Well, let's see. If someone can figure out the git equivalent of if cvs -q update | egrep -q '^(U|P) '; then # ... something changed, so run the update ... fi (assuming, for simplicity, that the current directory has the appropriate branch checked out already) then I might be able to get this fixed. -- 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] Any reason why the default_with_oids GUC is still there?
Peter Eisentraut wrote: > On tis, 2010-09-21 at 18:31 -0400, Bruce Momjian wrote: > > Also, doesn't some SQL standard require oids, so we should have a way > > to enable them by default for all tables? > > >From some DB2 example: > > CREATE TYPE BusinessUnit_t AS > (Name VARCHAR(20), > Headcount INT); > > CREATE TABLE BusinessUnit OF BusinessUnit_t > (REF IS oid USER GENERATED); > > The DB2 documentation consistently refers to this column as "oid", but > there is no requirement to name it that way. > > The SQL standard also contains this sentence: > > Let OID be the name of the self-referencing column of S. > > which refers to the thing defined in the example above, but "OID" is > just a placeholder here. > > I think there was a mention of OIDs in the "SQL3" draft that eventually > became SQL99, but that's long past now. Current standards don't have > it, except in the, perhaps more generalized, form above. Thanks for those details. I did remember it appearing at one point, which I guess was SQL3. -- 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] Documentation, window functions
On Wed, Sep 22, 2010 at 6:03 AM, Dennis Björklund wrote: > In > > http://www.postgresql.org/docs/9.0/static/tutorial-window.html > > it say > > "Although avg will produce the same result no matter what order it > processes the partition's rows in, this is not true of all window > functions. When needed, you can control that order using ORDER BY within > OVER." > > While it's true that avg() produce the same result no matter what order. A > ORDER BY clause will affect what rows are included in the computation and > thus change the result (the default window frame is > RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW). So one can not in > general add an ORDER BY to the example in the tutorial and get the same > result as without an ORDER BY. > > Maybe we can find some better wording of the above? Yeah, that doesn't seem right. rhaas=# create table foo (a integer); CREATE TABLE rhaas=# insert into foo values (1); INSERT 0 1 rhaas=# insert into foo values (2); INSERT 0 1 rhaas=# insert into foo values (3); INSERT 0 1 rhaas=# select a, avg(a) over () from foo; a |avg ---+ 1 | 2. 2 | 2. 3 | 2. (3 rows) rhaas=# select a, avg(a) over (order by a) from foo; a | avg ---+ 1 | 1. 2 | 1.5000 3 | 2. (3 rows) But I confess that I'm sort of murky on how ORDER affects the window frame, or how to rephrase this more sensibly. -- 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] Standby registration
On Wed, Sep 22, 2010 at 10:19 AM, Heikki Linnakangas wrote: >> No. The point of naming them is to uniquely identify them. > > Hmm, that situation can arise if there's a network glitch which leads the > standby to disconnect, but the master still considers the connection as > alive. When the standby reconnects, the master will see two simultaneous > connections from the same standby. In that scenario, you clearly want to > disconnect the old connetion in favor of the new one. +1 for making that the behavior. > Is there a scenario > where you'd want to keep the old connection instead and refuse the new one? I doubt it. > Perhaps that should be made configurable, so that you wouldn't need to list > all standbys in the config file if you don't want to. Then you don't get any > of the benefits of standby registration, though. I think it's fine to have async slaves that don't want any special features (like sync rep, or tracking how far behind they are in the xlog stream) not mentioned in the config file. But allowing multiple slaves with the same name seems like complexity without any attendant benefit. -- 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] Opening a plpgsql cursor parameter by name
Yeb Havinga writes:
> We intend to implement $subject, so instead of
> mycursor CURSOR (myparm text) IS SELECT myparm;
> OPEN mycursor('A');
> it would be possible to do
> OPEN mycursor(myparm := 'A');
Is this really worth the trouble? Is it supported by any other DBMS?
Are cursors used so much, or with so many parameters, that there's a
real benefit to be gained? (I tend to think that FOR loops are better
than cursors 99% of the time.)
I wouldn't be so obstructionist if this syntax weren't in flux.
But seeing that we have hopes of migrating from := to => before
very long, adding another dependency on that choice where it's
not buying a lot of functionality doesn't seem like a good idea.
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] moving development branch activity to new git repo
Elvis Pranskevichus wrote: > Instead of filtering non-merge commits I would suggest doing git > rebase on the latest revision of the old git repo. That way you > will get a set of commits that should apply cleanly. The reason > it is failing now is that it is impossible for git am to do a > 3-way merge without the original git objects, which are obviously > not available in the new repo. Well, that didn't work much better. It applied, but it started in June, and the "big" file, which has been in constant flux since January suddenly springs into existence in July. :-( The last few commits look right, but it gets pretty trashy pretty quickly before that. What *did* work is to take a fresh of the new repo, branch it as of the point in time that I created my original branch, and take the first mbox entry of the 167, which starts like this: >From 07ea78aaafe22cbbb0ffdedbfcf78404abbdbc70 Mon Sep 17 00:00:00 2001 From: Kevin Grittner Date: Fri, 8 Jan 2010 15:39:12 -0600 and change the first line to point to the point at which this was applied: >From 369494e41fe408f103884032f477555ba134a0a8 Fri Jan 8 09:06:05 2010 That applies fine. It's an encouraging start, but I'm not clear on exactly what I have to do to get the rest of these commits merged in with commits from the master branch cleanly. Some fix-up work is OK with me. Do I need to look at the old log and manually interleave merges to the branch and manual commits in the original pattern to make such a scheme work? -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] Git cvsserver serious issue
Andrew Dunstan writes: > On 09/22/2010 10:23 AM, Tom Lane wrote: >> If we're going to let people in by IP address, maybe we could let legacy >> buildfarm members in by IP address. It doesn't seem particularly >> helpful to expect each buildfarm owner to solve this problem for >> themselves. I'd also note that if they could run git locally, they >> wouldn't be needing cvsserver in the first place. > I'm not convinced we need any such thing yet. 13 of the 38 animals that > have reported in the last 5 days are using git already (OK, factoring > out my animals that's 8 out of 33). I'm going to send out email in a few > days prodding people to migrate. Let's see how far we get. Even if we get 100% compliance on the buildfarm side, Peter's already stated that moving the NLS support over to git is going to take more time than we have available right now. We need a cvsserver for awhile yet. We can't just suddenly announce "CVS service is terminated as of yesterday" and expect that that's not going to have any serious consequences. Is there anything we could do to patch the problem out of git-cvsserver? Maybe hack it to only accept requests for the active branch tips? 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
