Re: [HACKERS] Postgres 9.0.0 release scheduled
Andrew Dunstan writes: > On 09/18/2010 08:25 PM, Darren Duncan wrote: >> Is this still the timetable, or is it being affected at all by the >> delay in migrating repositories while the CVS is cleaned up? > They aren't really connected. If you've been watching -committers you > would have seen that the tag was applied on 16th. If there's some catastrophic reason to delay the release, we'll slip the git migration too. The current schedule is that the git migration happens after the release cycle completes. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch: Add JSON datatype to PostgreSQL (GSoC, WIP)
On Sat, Sep 18, 2010 at 11:48 PM, Joseph Adams wrote: > As for whitespace preservation, I don't think we should go out of our > way to keep it intact. Sure, preserving formatting for input and > output makes some sense because we'd have to go out of our way to > normalize it, but preserving whitespace in JSONPath tree selections > (json_get) and updates (json_set) is a lot of work (that I shouldn't > have done), and it doesn't really help anybody. Consider json_get on > a node under 5 levels of indentation. That seems reasonable to me. I don't mind messing up the whitespace when someone pulls a value out using a jsonpath, but I don't think we should mess with it when they just ask us to store a value. Users will tend to format their JSON in a way that they find readable, and while you'd need artificial intelligence to preserve their preferred formatting in all cases, changing it to what we think is best when there's no intrinsic necessity doesn't seem helpful. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch: Add JSON datatype to PostgreSQL (GSoC, WIP)
On Sat, Sep 18, 2010 at 4:03 PM, Robert Haas wrote: > Hmm, yeah. I'd be tempted to try to keep the user's original > whitespace as far as possible, but disregard it as far as equality > comparison goes. However, I'm not quite sure what the right thing to > do about 0 vs 0.0 is. Does the JSON spec say anything about that? I didn't find anything in the JSON spec about comparison, but in JavaScript, 0 == 0.0 and 0 === 0.0 are both true. Also, JavaScript considers two arrays or objects equal if and only if they are references to the same object, meaning [1,2,3] == [1,2,3] is false, but if you let var a = [1,2,3]; var b = a; , then a == b and a === b are both true. Hence, JavaScript can help us when deciding how to compare scalars, but as for arrays and objects, "we're on our own" (actually, JSON arrays could be compared lexically like PostgreSQL arrays already are; I don't think anyone would disagree with that). I cast my vote for 0 == 0.0 being true. As for whitespace preservation, I don't think we should go out of our way to keep it intact. Sure, preserving formatting for input and output makes some sense because we'd have to go out of our way to normalize it, but preserving whitespace in JSONPath tree selections (json_get) and updates (json_set) is a lot of work (that I shouldn't have done), and it doesn't really help anybody. Consider json_get on a node under 5 levels of indentation. Another thing to think about is the possibility of using a non-text format in the future (such as a binary format or even a format that is internally indexed). A binary format would likely be faster to compare (and hence faster to index). If the JSON data type preserves whitespace today, it might break assumptions of future code when it stops preserving whitespace. This should at least be documented. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql's \dn versus temp schemas
On Sat, Sep 18, 2010 at 6:35 PM, Robert Haas wrote: > On Sat, Sep 18, 2010 at 3:11 PM, Tom Lane wrote: >> This is at least inconsistent and at worst wildly misleading. ISTM >> we ought to adopt some combination of the following ideas: > > I vote for this combination: > >> 3. Don't show either pg_temp_nn or pg_toast_temp_nn schemas, not even >> for the current backend. > > and > >> With any of 1-3 we could also consider adding a rule that \dn+ >> doesn't hide them. Or perhaps another option would be to make \dnS display these. Not sure whether I like that or not. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Postgres 9.0.0 release scheduled
On 09/18/2010 08:25 PM, Darren Duncan wrote: Tom Lane wrote on 2010.09.08: The core committee has decided that it's time to press forward with releasing 9.0. Barring catastrophic bug reports in the next week, 9.0.0 will be wrapped Thursday 9/16 for public announcement Monday 9/20. Is this still the timetable, or is it being affected at all by the delay in migrating repositories while the CVS is cleaned up? They aren't really connected. If you've been watching -committers you would have seen that the tag was applied on 16th. 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] Postgres 9.0.0 release scheduled
Tom Lane wrote on 2010.09.08: The core committee has decided that it's time to press forward with releasing 9.0. Barring catastrophic bug reports in the next week, 9.0.0 will be wrapped Thursday 9/16 for public announcement Monday 9/20. Is this still the timetable, or is it being affected at all by the delay in migrating repositories while the CVS is cleaned up? -- Darren Duncan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Configuring synchronous replication
> I think that using a system catalog for this is going to be a > non-starter, Technically improbable? Darn. > but we could use a flat file that is designed to be > machine-editable (and thus avoid repeating the mistake we've made with > postgresql.conf). Well, even if we can't update it through the command line, at least the existing configuration (and node status) ought to be queryable. -- -- 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] psql's \dn versus temp schemas
On Sat, Sep 18, 2010 at 3:11 PM, Tom Lane wrote: > This is at least inconsistent and at worst wildly misleading. ISTM > we ought to adopt some combination of the following ideas: I vote for this combination: > 3. Don't show either pg_temp_nn or pg_toast_temp_nn schemas, not even > for the current backend. and > With any of 1-3 we could also consider adding a rule that \dn+ > doesn't hide them. -- 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 Sat, Sep 18, 2010 at 5:42 PM, Josh Berkus wrote: > There are considerable benefits to having a standby registry with a > table-like interface. Particularly, one where we could change > replication via UPDATE (or ALTER STANDBY) statements. I think that using a system catalog for this is going to be a non-starter, but we could use a flat file that is designed to be machine-editable (and thus avoid repeating the mistake we've made with postgresql.conf). -- 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
All, I'm answering this strictly from the perspective of my company's customers and what they've asked for. It does not reflect on what features are reflected in whatever patch. > * Support multiple standbys with various synchronization levels. Essential. We already have two customers who want to have one synch and several async standbys. > * What happens if a synchronous standby isn't connected at the moment? > Return immediately vs. wait forever. Essential. Actually, we need a replication_return_timeout. That is, wait X seconds on the standby and then give up. Again, in the systems I'm working with, we'd want to wait 5 seconds and then abort replication. > * Per-transaction control. Some transactions are important, others are not. Low priority. I see this as a 9.2 feature. Nobody I know is asking for it yet, and I think we need to get the other stuff right first. > * Quorum commit. Wait until n standbys acknowledge. n=1 and n=all > servers can be seen as important special cases of this. Medium priority. This would go together with having a registry of standbies. The only reason I don't call this low priority is that it would catapult PostgreSQL into the realm of CAP databases, assuming that we could deal with the re-mastering issue as well. > * async, recv, fsync and replay levels of synchronization. Fsync vs. Replay is low priority (as in, we could live with just one or the other), but the others are all high priority. Again, this should be settable *per standby*. > So what should the user interface be like? Given the 1st and 2nd > requirement, we need standby registration. If some standbys are > important and others are not, the master needs to distinguish between > them to be able to determine that a transaction is safely delivered to > the important standbys. There are considerable benefits to having a standby registry with a table-like interface. Particularly, one where we could change replication via UPDATE (or ALTER STANDBY) statements. a) we could eliminate a bunch of GUCs and control standby behavior instead via the table interface. b) DBAs and monitoring tools could see at a glance what the status of their replication network was. c) we could easily add new features (like quorum groups) without breaking prior setups. d) it would become easy rather than a PITA to construct GUI replication management tools. e) as previously mentioned, we could use it to have far more intelligent control over what WAL segments to keep, both on the master and in some distributed archive. Note, however, that the data from this pseudo-table would need to be replicated to the standby servers somehow in order to support re-mastering. Take all the above with a grain of salt, though. The important thing is to get *some kind* of synch rep into 9.1, and get 9.1 out on time. -- -- 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] [JDBC] Trouble with COPY IN
Kris Jurka writes: >> On Fri, 6 Aug 2010, James William Pye wrote: >>> I think there's a snag in the patch: > Oh, duh. It's a server side copy not going through the client at all. > Here's a hopefully final patch. Applied with a correction: this would've totally broken binary copy in old-style protocol, because there is no other EOF marker except the -1 in that case. BTW, it strikes me that we could reduce the backwards-compatibility impact of this patch if we made it ignore, rather than throw error for, any extra data after the EOF marker. I left it as-is since ISTM the more error checking you can have in a binary data format, the better. But a case could be made for doing the other thing, especially if somebody wanted to argue for back-patching this. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch: Add JSON datatype to PostgreSQL (GSoC, WIP)
On Fri, Sep 17, 2010 at 11:12 PM, Itagaki Takahiro wrote: > On Sat, Sep 18, 2010 at 11:46 AM, Robert Haas wrote: >> wrote: >>> One of my proposal is we don't have to keep the original input text. >>> We store JSON data in effective internal formats. If users want to get >>> human-readable output, they can use stringify() with indentation option. >> >> There's a trade-off here: this will make some things faster, but other >> things slower. Probably some discussion of the pros and cons is in >> order. > > I didn't intended to introduce non-text internal formats. The original > patch spent some codes to keep all of whitespaces as-is in the input. > But I'd say we can simplify it. > > Except whitespaces, normalization of strings and numbers might be > problem when we support JSON comparison operators -- comparison of > Unicode escaped characters in strings or 0 vs. 0.0 in numbers. Hmm, yeah. I'd be tempted to try to keep the user's original whitespace as far as possible, but disregard it as far as equality comparison goes. However, I'm not quite sure what the right thing to do about 0 vs 0.0 is. Does the JSON spec say anything about that? -- 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] compile/install of git
On Sat, Sep 18, 2010 at 2:30 PM, Andrew Dunstan wrote: > On 09/18/2010 02:20 PM, David Blewett wrote: >> >> I was under the impression that git over http was just as efficient since >> 1.6.6 [1]. >> >> David Blewett >> 1. http://github.com/blog/642-smart-http-support >> > > It's hard to keep up, the landscape is still changing quite fast. Every time I've tried to use it, it's been dog slow. But what do I know? -- 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 Sat, Sep 18, 2010 at 4:50 AM, Simon Riggs wrote: > Waiting might sound attractive. In practice, waiting will make all of > your connections lock up and it will look to users as if their master > has stopped working as well. (It has!). I can't imagine why anyone would > ever want an option to select that; its the opposite of high > availability. Just sounds like a serious footgun. Nevertheless, it seems that some people do want exactly that behavior, no matter how crazy it may seem to you. I'm not exactly sure what we're in disagreement about, TBH. You've previously said that you don't think standby registration is necessary, but that you don't object to it if others want it. So it seems like this might be mostly academic. -- 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] Serializable Snapshot Isolation
On 18/09/10 21:52, Kevin Grittner wrote: [Apologies for not reply-linking this; work email is down so I'm sending from gmail.] Based on feedback from Heikki and Tom I've reworked how I find the top-level transaction. This is in the git repo, and the changes can be viewed at: http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=e29927c7966adba2443fdc4f64da9d282f95a05b Thanks, much simpler. Now let's simplify it some more ;-) ISTM you never search the SerializableXactHash table using a hash key, except the one call in CheckForSerializableConflictOut, but there you already have a pointer to the SERIALIZABLEXACT struct. You only re-find it to make sure it hasn't gone away while you trade the shared lock for an exclusive one. If we find another way to ensure that, ISTM we don't need SerializableXactHash at all. My first thought was to forget about VirtualTransactionId and use TransactionId directly as the hash key for SERIALIZABLEXACT. The problem is that a transaction doesn't have a transaction ID when RegisterSerializableTransaction is called. We could leave the TransactionId blank and only add the SERIALIZABLEXACT struct to the hash table when an XID is assigned, but there's no provision to insert an existing struct to a hash table in the current hash table API. So, I'm not sure of the details yet, but it seems like it could be made simpler somehow.. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] psql's \dn versus temp schemas
psql's \dn command hides pg_temp_nn schemas, except for the current backend's own temp schema (if any). However, when we added separate pg_toast_temp_nn schemas for TOAST tables, \dn wasn't taught about that, leading to such odd-looking output as this: regression=# \dn List of schemas Name| Owner +-- information_schema | postgres pg_catalog | postgres pg_temp_2 | postgres pg_toast | postgres pg_toast_temp_1| postgres pg_toast_temp_2| postgres pg_toast_temp_3| postgres pg_toast_temp_4| postgres public | postgres testxmlschema | postgres (10 rows) regression=# This is at least inconsistent and at worst wildly misleading. ISTM we ought to adopt some combination of the following ideas: 1. Don't show pg_toast_temp_nn schemas ever. Maybe hide pg_toast too for consistency. 2. Show only the current backend's pg_toast_temp_nn schema. (Note: I don't see any very easy way to implement that :-(; psql doesn't have easy access to the backend's slot number. The way that it identifies the pg_temp_nn schema is a hack that won't scale.) 3. Don't show either pg_temp_nn or pg_toast_temp_nn schemas, not even for the current backend. 4. Forget about hiding these schemas at all. With any of 1-3 we could also consider adding a rule that \dn+ doesn't hide them. Thoughts? 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
[Apologies for not reply-linking this; work email is down so I'm sending from gmail.] Based on feedback from Heikki and Tom I've reworked how I find the top-level transaction. This is in the git repo, and the changes can be viewed at: http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=e29927c7966adba2443fdc4f64da9d282f95a05b -Kevin
Re: [HACKERS] INSERT and parentheses
Marko Tiikkaja writes:
> [ patch for a misleading error message ]
I've committed the attached revised version of this patch. The main
change is to only emit the hint if the insertion source can be shown
to be a RowExpr with exactly the number of columns expected by the
INSERT. This should avoid emitting the hint in cases where it's not
relevant, and allows a specific wording for the hint, as was recommended
by Stephen Frost.
regards, tom lane
Index: analyze.c
===
RCS file: /cvsroot/pgsql/src/backend/parser/analyze.c,v
retrieving revision 1.403
diff -c -r1.403 analyze.c
*** analyze.c 27 Aug 2010 20:30:08 - 1.403
--- analyze.c 18 Sep 2010 18:27:33 -
***
*** 47,52
--- 47,53
static Query *transformInsertStmt(ParseState *pstate, InsertStmt *stmt);
static List *transformInsertRow(ParseState *pstate, List *exprlist,
List *stmtcols, List *icolumns, List
*attrnos);
+ static intcount_rowexpr_columns(ParseState *pstate, Node *expr);
static Query *transformSelectStmt(ParseState *pstate, SelectStmt *stmt);
static Query *transformValuesClause(ParseState *pstate, SelectStmt *stmt);
static Query *transformSetOperationStmt(ParseState *pstate, SelectStmt *stmt);
***
*** 726,737
--- 727,753
list_length(icolumns));
if (stmtcols != NIL &&
list_length(exprlist) < list_length(icolumns))
+ {
+ /*
+* We can get here for cases like INSERT ... SELECT (a,b,c)
FROM ...
+* where the user accidentally created a RowExpr instead of
separate
+* columns. Add a suitable hint if that seems to be the
problem,
+* because the main error message is quite misleading for this
case.
+* (If there's no stmtcols, you'll get something about data type
+* mismatch, which is less misleading so we don't worry about
giving
+* a hint in that case.)
+*/
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("INSERT has more target columns than
expressions"),
+((list_length(exprlist) == 1 &&
+ count_rowexpr_columns(pstate,
linitial(exprlist)) ==
+ list_length(icolumns)) ?
+ errhint("The insertion source is a row
expression containing the same number of columns expected by the INSERT. Did
you accidentally use extra parentheses?") : 0),
parser_errposition(pstate,
exprLocation(list_nth(icolumns,
list_length(exprlist));
+ }
/*
* Prepare columns for assignment to target table.
***
*** 762,767
--- 778,826
return result;
}
+ /*
+ * count_rowexpr_columns -
+ * get number of columns contained in a ROW() expression;
+ * return -1 if expression isn't a RowExpr or a Var referencing one.
+ *
+ * This is currently used only for hint purposes, so we aren't terribly
+ * tense about recognizing all possible cases. The Var case is interesting
+ * because that's what we'll get in the INSERT ... SELECT (...) case.
+ */
+ static int
+ count_rowexpr_columns(ParseState *pstate, Node *expr)
+ {
+ if (expr == NULL)
+ return -1;
+ if (IsA(expr, RowExpr))
+ return list_length(((RowExpr *) expr)->args);
+ if (IsA(expr, Var))
+ {
+ Var*var = (Var *) expr;
+ AttrNumber attnum = var->varattno;
+
+ if (attnum > 0 && var->vartype == RECORDOID)
+ {
+ RangeTblEntry *rte;
+
+ rte = GetRTEByRangeTablePosn(pstate, var->varno,
var->varlevelsup);
+ if (rte->rtekind == RTE_SUBQUERY)
+ {
+ /* Subselect-in-FROM: examine sub-select's
output expr */
+ TargetEntry *ste =
get_tle_by_resno(rte->subquery->targetList,
+
attnum);
+
+ if (ste == NULL || ste->resjunk)
+ return -1;
+ expr = (Node *) ste->expr;
+ if (IsA(expr, RowExpr))
+ return list_length(((RowExpr *)
expr)->args);
+
Re: [HACKERS] compile/install of git
On 09/18/2010 02:20 PM, David Blewett wrote: I was under the impression that git over http was just as efficient since 1.6.6 [1]. David Blewett 1. http://github.com/blog/642-smart-http-support It's hard to keep up, the landscape is still changing quite fast. 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] compile/install of git
Sorry for top-posting... I was under the impression that git over http was just as efficient since 1.6.6 [1]. David Blewett 1. http://github.com/blog/642-smart-http-support On Sep 18, 2010 12:26 PM, "Andrew Dunstan" wrote: On 09/18/2010 11:37 AM, Tom Lane wrote: > > Andrew Dunstan wrote: >>> >>> Test machines belong in ... Right. I was just reacting to Bruce's observation about what people said about his moving off BSD/OS. > Bruce Momjian writes: >> >> My big point in posting was to say that compiling... Yeah. Git over HTTP is horribly inefficient anyway - it's really a last resort. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your sub...
Re: [HACKERS] compile/install of git
On 09/18/2010 11:37 AM, Tom Lane wrote: Andrew Dunstan wrote: Test machines belong in the buildfarm. So? People are still going to want to git-ify their buildfarm critters. Right. I was just reacting to Bruce's observation about what people said about his moving off BSD/OS. Bruce Momjian writes: My big point in posting was to say that compiling git was not the nightmare I expected it to be. FWIW, I've also successfully installed git on my old HPUX box. I avoided most of the library dependencies by giving up support for http: URLs for repositories. I figure git: and ssh: should cover what I need to do with it. Yeah. Git over HTTP is horribly inefficient anyway - it's really a last resort. 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] psycopg and two phase commit
On Sat, 2010-09-18 at 18:01 +0200, Pavel Stehule wrote: > who is psycopg maintainer, please? Why don't you ask it to psycopg2 mailing list? http://www.initd.org/ (I know, mailing lists are down nowadays. See website) -- Devrim GÜNDÜZ PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer PostgreSQL RPM Repository: http://yum.pgrpms.org Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Report: removing the inconsistencies in our CVS->git conversion
I wrote: > This commit occurred during that interval between where we'd initially > branched 7.3 and where we moved it up to head. I think what happened > was that I tried to back-patch a fix into what was then the 7.3 branch, > and when Marc moved the branch point, these commits all ended up > orphans. So indeed there's no harm discarding them. (I always > suspected that what Marc had done wasn't entirely kosher, and yup, > now the chickens are coming home to roost.) BTW, if you're wondering why there was only one such commit, it's because we decided to not maintain the branch only a day after Marc had sprouted it. See discussion here: http://archives.postgresql.org/pgsql-hackers/2002-09/msg01733.php regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Progress indication prototype
Dimitri Fontaine writes: > Robert Haas writes: >> What you just said is about what I had in mind. I admit I can't >> articulate a more detailed design right off the top of my head, but >> the architecture you're proposing seems dead certain to never cover >> more than 0.1% of what people actually do. > Well, considering what we have now, the proposal is solid enough for > me. As far as supporting VACUUM or REINDEX operations, my feeling is > that offering a way to report current block being worked on and being > able to see that move is enough a progress indication. I don't really think that that would satisfy anybody. If you want to be reassured that VACUUM is doing something, you can look at iostat numbers, or strace the process, or something like that. What people expect from a progress indicator is to get some idea of how much longer the operation is likely to take, and current block doesn't do it (mainly because it doesn't account for index cleanup scans). REINDEX is even worse: how do you estimate progress when there's a table scan, then a sort, then the actual index build? I'm with Robert on this. A facility that's limited to information we can get "for free" (and btw, it isn't even for free, only for relatively cheap) isn't going to get the job done. We should be looking for something that expends extra cycles when the information is demanded, and otherwise not. 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] psycopg and two phase commit
Hello who is psycopg maintainer, please? Can somebody explains to me, why psycopg doesn't support twophase commit still, although some implementation was done in summer 2008? Now two phase commit is part of DB-API, so can be implemented. There are some bariers? Regards Pavel Stehule -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] compile/install of git
Andrew Dunstan wrote: >> Test machines belong in the buildfarm. So? People are still going to want to git-ify their buildfarm critters. Bruce Momjian writes: > My big point in posting was to say that compiling git was not the > nightmare I expected it to be. FWIW, I've also successfully installed git on my old HPUX box. I avoided most of the library dependencies by giving up support for http: URLs for repositories. I figure git: and ssh: should cover what I need to do with it. For anyone else trying to get it installed on an odd platform: their configure script improved quite a lot in the last six months, so get a recent version. I had to do a lot of hacking to get 1.7.1 to build, but 1.7.2.3 fixes most of those problems. It still misses a few things, but you can probably fix any problems by adjusting the config.mak.autogen file afterwards. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] compile/install of git
Andrew Dunstan wrote: > > > On 09/18/2010 10:22 AM, Bruce Momjian wrote: > > Dave Page wrote: > >> On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian wrote: > >>> FYI, I have compiled/installed git 1.7.3.rc2 on my BSD/OS 4.3.1 machine > >>> with the attached minor changes. > >> I thought you were replacing that old thing with pile of hardware that > >> Matthew was putting together? > > Matthew was busy this summer so I am going to try to get some of his > > time by January to switch to Ubuntu. And some people are complaining we > > will lose a BSD test machine once I switch. > > > > Test machines belong in the buildfarm. And why would they complain about > losing a machine running a totally out of date and unsupported OS? Maybe > you should run BeOS instead. Well, I can run tests for folks before they apply a patch and "red" the build farm. I can also research fixes easier because I am using the OS, rather than running blind tests. I am just telling you what people told me. My big point in posting was to say that compiling git was not the nightmare I expected it to be. I figured it would want tons of newer or odd libraries I didn't have, but that was not the case at all. I am sure others will need to compile git themselves for odd operating systems, and I wanted to encourage them to try. -- 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] compile/install of git
On 09/18/2010 10:22 AM, Bruce Momjian wrote: Dave Page wrote: On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian wrote: FYI, I have compiled/installed git 1.7.3.rc2 on my BSD/OS 4.3.1 machine with the attached minor changes. I thought you were replacing that old thing with pile of hardware that Matthew was putting together? Matthew was busy this summer so I am going to try to get some of his time by January to switch to Ubuntu. And some people are complaining we will lose a BSD test machine once I switch. Test machines belong in the buildfarm. And why would they complain about losing a machine running a totally out of date and unsupported OS? Maybe you should run BeOS instead. 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] compile/install of git
Dave Page wrote: > On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian wrote: > > FYI, I have compiled/installed git 1.7.3.rc2 on my BSD/OS 4.3.1 machine > > with the attached minor changes. > > I thought you were replacing that old thing with pile of hardware that > Matthew was putting together? Matthew was busy this summer so I am going to try to get some of his time by January to switch to Ubuntu. And some people are complaining we will lose a BSD test machine once I switch. -- 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] Progress indication prototype
Robert Haas writes: > What you just said is about what I had in mind. I admit I can't > articulate a more detailed design right off the top of my head, but > the architecture you're proposing seems dead certain to never cover > more than 0.1% of what people actually do. Well, considering what we have now, the proposal is solid enough for me. As far as supporting VACUUM or REINDEX operations, my feeling is that offering a way to report current block being worked on and being able to see that move is enough a progress indication. We know for sure we won't be able to provide a reliable progress bar, and I don't think adopting the famous windows time units (the longest remaining second known) would do any good for the project. 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] Configuring synchronous replication
Simon Riggs writes: > I've said COMMIT with no option because I believe that we have only two > choices: commit or wait (perhaps forever), and IMHO waiting is not good. > > We can't ABORT, because we sent a commit to the standby. Ah yes, I keep forgetting Sync Rep is not about 2PC. Sorry about that. > Waiting might sound attractive. In practice, waiting will make all of > your connections lock up and it will look to users as if their master > has stopped working as well. (It has!). I can't imagine why anyone would > ever want an option to select that; its the opposite of high > availability. Just sounds like a serious footgun. I guess that if there's a timeout GUC it can still be set to infinite somehow. Unclear as the use case might be. 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] Configuring synchronous replication
On Fri, 2010-09-17 at 21:32 +0200, Dimitri Fontaine wrote: > Simon Riggs writes: > > On Fri, 2010-09-17 at 21:20 +0900, Fujii Masao wrote: > >> According to what I heard, some people want to guarantee that all the > >> transactions are *always* written in *all* the synchronous standbys. > > > > You don't need standby registration at all. You can do that with a > > single parameter, already proposed: > > > > quorum_commit = N. > > I think you also need another parameter to control the behavior upon > timeout. You received less than N votes, now what? You're current idea > seems to be COMMIT, Aidan says ROLLBACK, and I say that's to be a GUC > set at the transaction level. I've said COMMIT with no option because I believe that we have only two choices: commit or wait (perhaps forever), and IMHO waiting is not good. We can't ABORT, because we sent a commit to the standby. If we abort, then we're saying the standby can't ever come back because it will have received and potentially replayed a different transaction history. I had some further thoughts around that but you end up with the byzantine generals problem always. Waiting might sound attractive. In practice, waiting will make all of your connections lock up and it will look to users as if their master has stopped working as well. (It has!). I can't imagine why anyone would ever want an option to select that; its the opposite of high availability. Just sounds like a serious footgun. Having said that Oracle offers Maximum Protection mode, which literally shuts down the master when you lose a standby. I can't say anything apart from "LOL". > As far as registration goes, I see no harm to have the master maintain a > list of known standby systems, of course, it's just maintaining that > list from the master that I don't understand the use case for. Yes, the master needs to know about all currently connected standbys. The only debate is what happens about ones that "ought" to be there. Given my comments above, I don't see the need. -- 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] compile/install of git
On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian wrote: > FYI, I have compiled/installed git 1.7.3.rc2 on my BSD/OS 4.3.1 machine > with the attached minor changes. I thought you were replacing that old thing with pile of hardware that Matthew was putting together? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: 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
