Re: [HACKERS] Replication server timeout patch
On Sun, Mar 6, 2011 at 3:23 AM, Robert Haas robertmh...@gmail.com wrote: On Mon, Feb 28, 2011 at 8:08 AM, Fujii Masao masao.fu...@gmail.com wrote: On Sun, Feb 27, 2011 at 11:52 AM, Fujii Masao masao.fu...@gmail.com wrote: There are two things that I think are pretty clear. If the receiver has wal_receiver_status_interval=0, then we should ignore replication_timeout for that connection. The patch still doesn't check that wal_receiver_status_interval is set up properly. I'll implement that later. Done. I attached the updated patch. Why does internal_flush_if_writable compute bufptr differently from internal_flush? And shouldn't it be static? It seems to me that this ought to be refactored so that you don't duplicate so much code. Maybe static int internal_flush(bool nonblocking). I don't think that the while (bufptr bufend) loop needs to contain the code to set and clear the nonblocking state. You could do the whole loop with nonblocking mode turned on and then reenable it just once at the end. Besides possibly being clearer, that would be more efficient and leave less room for unexpected failures. All these comments seem to make sense. Will fix. Thanks! Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sync Rep v19
On Sun, 2011-03-06 at 14:27 +0900, Fujii Masao wrote: On Sun, Mar 6, 2011 at 2:59 AM, Robert Haas robertmh...@gmail.com wrote: On Sat, Mar 5, 2011 at 11:56 AM, Simon Riggs si...@2ndquadrant.com wrote: Even though postmaster dies, the waiting backend keeps waiting until the timeout expires. Instead, the backends should periodically check whether postmaster is alive, and then they should exit immediately if it's not alive, as well as other process does? If the timeout is disabled, such backends would get stuck infinitely. Will wake them every 60 seconds I don't really see why sync rep should be responsible for solving this problem, which is an issue in many other situations as well, only for itself. In fact I think I'd prefer that it didn't, and that we wait for a more general solution that will actually fix this problem for real. I agree if such a general solution will be committed together with sync rep. Otherwise, because of sync rep, the backend can easily get stuck *infinitely*. When postmaster is not alive, all the existing walsenders exit immediately and no new walsender can appear. So there is no way to release the waiting backend. I think that some solutions for this issue which is likely to happen are required. Completely agree. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sync Rep v19
On Sun, 2011-03-06 at 16:58 +0900, Fujii Masao wrote: On Sun, Mar 6, 2011 at 4:51 PM, Fujii Masao masao.fu...@gmail.com wrote: One comment; what about introducing built-in function to wake up all the waiting backends? When replication connection is closed, if we STONITH the standby, we can safely (for not physical data loss but logical one) switch the primary to standalone mode. But there is no way to wake up the waiting backends for now. Setting synchronous_replication to OFF and reloading the configuration file doesn't affect the existing waiting backends. The attached patch introduces the pg_wakeup_all_waiters (better name?) function which wakes up all the backends on the queue. If unfortunately all connection slots are used by backends waiting for replication, we cannot execute such a function. So it makes more sense to introduce something like pg_ctl standalone command? Well, there is one way to end the wait: shutdown, or use pg_terminate_backend(). If you simply end the wait you will get COMMIT messages. What I would like to do is commit the safe patch now. We can then discuss whether it is safe and desirable to relax some aspects of that during beta. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sync Rep v19
On Sun, 2011-03-06 at 01:58 +0900, Fujii Masao wrote:
On Sun, Mar 6, 2011 at 12:42 AM, Fujii Masao masao.fu...@gmail.com wrote:
New comments;
Another one;
+ longtimeout = SyncRepGetWaitTimeout();
snip
+ else if (timeout 0
+ TimestampDifferenceExceeds(wait_start, now,
timeout))
+ {
The third argument of TimestampDifferenceExceeds is
expressed in milliseconds. But you wrongly give that the
microseconds.
Just for the record: that code section is now removed in v21
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Improve check for TOAST checks in pre-8.4 pg_upgrade servers
I have improved the check and comments for pg_upgrade when testing for pre-8.4 toast files in the attached applied patch. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + diff --git a/contrib/pg_upgrade/info.c b/contrib/pg_upgrade/info.c index fe060ff..9cd3441 100644 *** a/contrib/pg_upgrade/info.c --- b/contrib/pg_upgrade/info.c *** gen_db_file_maps(DbInfo *old_db, DbInfo *** 56,66 /* * In pre-8.4, TOAST table names change during CLUSTER; in = 8.4 ! * TOAST relation names always use the heap tables oid, hence we * cannot check relation names when upgrading from pre-8.4. */ ! if (GET_MAJOR_VERSION(old_cluster.major_version) = 804 ! (strcmp(old_rel-nspname, new_rel-nspname) != 0 || strcmp(old_rel-relname, new_rel-relname) != 0)) pg_log(PG_FATAL, Mismatch of relation names: database \%s\, old rel %s.%s, new rel %s.%s\n, --- 56,66 /* * In pre-8.4, TOAST table names change during CLUSTER; in = 8.4 ! * TOAST relation names always use heap table oids, hence we * cannot check relation names when upgrading from pre-8.4. */ ! if (strcmp(old_rel-nspname, new_rel-nspname) != 0 || ! (GET_MAJOR_VERSION(old_cluster.major_version) = 804 strcmp(old_rel-relname, new_rel-relname) != 0)) pg_log(PG_FATAL, Mismatch of relation names: database \%s\, old rel %s.%s, new rel %s.%s\n, -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] storage format version number for external modules
Right now the backend server has a catalog version number which reports the version of the system tables and storage format. It would be helpful if pg_upgrade could access a storage format version number for plugins like /contrib so it could check to see if the cluster can be upgraded with the installed plugins. (A catalog version number is not necessary for plugins.) -- Bruce Momjian br...@momjian.ushttp://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] Perl 5.12 complains about ecpg parser-hacking scripts
On 3 March 2011 06:33, Andy Colson a...@squeakycode.net wrote: On 1/23/2011 5:11 AM, Michael Meskes wrote: As I already said when the script was introduced, I would love to have a real perl solution, but I'm not a perl programmer by any means. Michael I thought Kris was going to work on this, but saw no progress, and I was bored the other day, so I started working on it. Yeah, sorry about that. I got as far as check_rules.pl with perl5.8 and running it against all the commits which changed the files it depends on and comparing the results with the old script; and then a major meltdown at work - primary SAN crashed :( - got in the way and I totally forgot about it... Thanks for picking up the ball and running with it. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pl/python tracebacks
On 02/03/11 22:28, Jan Urbański wrote: On 01/03/11 22:12, Peter Eisentraut wrote: On tis, 2011-03-01 at 21:10 +0100, Jan Urbański wrote: So you end up with a context message saying PL/Python function %s and a detail message with the saved detail (if it's present) *and* the traceback. The problem is that the name of the function is already in the traceback, so there's no need for the context *if* there's a traceback present. I wouldn't actually worry about that bit of redundancy so much. Getting proper context for nested calls is much more important. Here's another version that puts tracebacks in the context field. I did some tests with the attached test script, calling various of the functions defined there and the error messages more or less made sense (or at least were not worse than before). I realized I did not update the patch state in the CF app when I added this version, so I flipped it back to Ready for Committer now. Tracebacks are a nice-to-have, so if we decide to drop this one due to time constraints, I'd understand that. But fixing raise plpy.Fatal() to actually cause a FATAL is something that should be extracted from this patch and committed, even if the full patch does not make it. Cheers, Jan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] default pg_hba vs replication
Should we perhaps add a replication line to the default hba file, the same way we have for regular connections? IIRC we discussed that as a sub-sub-sub-point in some previous thread, but never mad a decision... -- 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] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Sat, Mar 5, 2011 at 7:22 AM, Robert Haas robertmh...@gmail.com wrote: Here's a rough attempt at filtering the post-alpha3 commit log down to approximately the set of things worth adding to the alpha4 release notes. Seems that support LIKE and ILIKE index searches via contrib/pg_trgm indexes is not mentioned here. With best regards, Alexander Korotkov.
Re: [HACKERS] Sync Rep v19
On Sun, Mar 6, 2011 at 5:26 PM, Simon Riggs si...@2ndquadrant.com wrote: On Sun, 2011-03-06 at 16:58 +0900, Fujii Masao wrote: On Sun, Mar 6, 2011 at 4:51 PM, Fujii Masao masao.fu...@gmail.com wrote: One comment; what about introducing built-in function to wake up all the waiting backends? When replication connection is closed, if we STONITH the standby, we can safely (for not physical data loss but logical one) switch the primary to standalone mode. But there is no way to wake up the waiting backends for now. Setting synchronous_replication to OFF and reloading the configuration file doesn't affect the existing waiting backends. The attached patch introduces the pg_wakeup_all_waiters (better name?) function which wakes up all the backends on the queue. If unfortunately all connection slots are used by backends waiting for replication, we cannot execute such a function. So it makes more sense to introduce something like pg_ctl standalone command? Well, there is one way to end the wait: shutdown, or use pg_terminate_backend(). Immediate shutdown can release the wait. But smart and fast shutdown cannot. Also pg_terminate_backend() cannot. Since a backend is waiting on the latch and InterruptHoldoffCount is not zero, only SetLatch() or SIGQUIT can cause it to end. If you simply end the wait you will get COMMIT messages. What I would like to do is commit the safe patch now. We can then discuss whether it is safe and desirable to relax some aspects of that during beta. OK if changing some aspects is acceptable during beta. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sync Rep v19
On Sun, Mar 6, 2011 at 5:02 PM, Yeb Havinga yebhavi...@gmail.com wrote: On Sun, Mar 6, 2011 at 8:58 AM, Fujii Masao masao.fu...@gmail.com wrote: If unfortunately all connection slots are used by backends waiting for replication, we cannot execute such a function. So it makes more sense to introduce something like pg_ctl standalone command? If it is only for shutdown, maybe pg_ctl stop -m standalone? It's for not only shutdown but also running the primary in standalone mode. So something like pg_ctl standalone is better. For now I think that pg_ctl command is better than built-in function because sometimes we might want to wake waiters up even during shutdown in order to cause shutdown to end. During shutdown, the server doesn't accept any new connection (even from the standby). So, without something like pg_ctl standalone, there is no way to cause shutdown to end. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sync Rep v19
El 06/03/2011 03:26, Simon Riggs si...@2ndquadrant.com escribió: On Sun, 2011-03-06 at 16:58 +0900, Fujii Masao wrote: If unfortunately all connection slots are used by backends waiting for replication, we cannot execute such a function. So it makes more sense to introduce something like pg_ctl standalone command? Well, there is one way to end the wait: shutdown, or use pg_terminate_backend(). I disconnected all standbys so the master keeps waiting on commit. Then i shutdown the master with immediate and got a crash. i wasn't able to trace that though -- Jaime Casanovawww.2ndQuadrant.com
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Andres Freund and...@anarazel.de writes: Ah. Finally after trying to stare down the code for some more time the issue is pretty simple. - fmgr_info_collation(irel-rd_index-indcollation.values[attnum-1], + fmgr_info_collation(irel-rd_indcollation[attnum-1], Good catch ... but while I was poking around to make sure that there were no other similar errors, I started to get pretty desperately unhappy with the state of this code altogether. What exactly is indcollation supposed to mean? Does it have any meaning for unordered indexes? If it means something about the index's sort order, why is it that it's not consulted while building the pathkeys that represent the sort order? (It isn't.) 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] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Andres Freund and...@anarazel.de writes: - fmgr_info_collation(irel-rd_index-indcollation.values[attnum-1], + fmgr_info_collation(irel-rd_indcollation[attnum-1], locinfo); BTW, I went ahead and committed this part, since the bug and the fix are clear. I'm still not thrilled with the plan of sprinkling the code with random fmgr_info_collation() calls to make up for the lack of a sane default. IMO, that *is* a default, just a badly implemented one. 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] Downtime for commitfest.postgresql.org
Hi! If all things go according to plans, we will be moving the VM that runs commitfest.postgresql.org to new hw+platform tomorrow, in the AM European time. Expected downtime is just a couple of minutes, and I will leave the old server still responding but in read-only mode. Thus, if you get a read-only error and it doesn't go away in 5 minutes, you may want to give your DNS resolver a kick.. We'll post more information here as the work progresses. -- 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] Sync Rep v19
On Mar 6, 2011, at 9:44 AM, Fujii Masao masao.fu...@gmail.com wrote: On Sun, Mar 6, 2011 at 5:02 PM, Yeb Havinga yebhavi...@gmail.com wrote: On Sun, Mar 6, 2011 at 8:58 AM, Fujii Masao masao.fu...@gmail.com wrote: If unfortunately all connection slots are used by backends waiting for replication, we cannot execute such a function. So it makes more sense to introduce something like pg_ctl standalone command? If it is only for shutdown, maybe pg_ctl stop -m standalone? It's for not only shutdown but also running the primary in standalone mode. So something like pg_ctl standalone is better. For now I think that pg_ctl command is better than built-in function because sometimes we might want to wake waiters up even during shutdown in order to cause shutdown to end. During shutdown, the server doesn't accept any new connection (even from the standby). So, without something like pg_ctl standalone, there is no way to cause shutdown to end. This sounds like an awful hack to work around a bad design. Surely once shutdown reaches a point where new replication connections can no longer be accepted, any standbys hung on commit need to close the connection without responding to the COMMIT, per previous discussion. It's completely unreasonable for sync rep to break the shutdown sequence. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] default pg_hba vs replication
On Mar 5, 2011, at 10:14 AM, Magnus Hagander mag...@hagander.net wrote: Should we perhaps add a replication line to the default hba file, the same way we have for regular connections? IIRC we discussed that as a sub-sub-sub-point in some previous thread, but never mad a decision... Not sure what the point is. Anything open enough to be useful would be a security hole, I would think. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ALTER TYPE COLLATABLE?
On ons, 2011-03-02 at 16:00 -0500, Tom Lane wrote: That seems like a 100% arbitrary distinction between base types and domains, to the detriment of base types, which is odd since in most other ways base types are much more flexible than domains. Well, base types don't support check constraints either. So conceptually, there is a useful distinction, namely that domains are sort of a macro for a column definition. Well, I think a use case will pop up PDQ --- contrib/citext seems like the most likely first candidate. Why would citext need a nondefault default collation? OK, something that will probably be opened for discussion in 9.2 is fitting case-insensitivity into the core collation/type system, and then this might come into play, but we don't really know how the details of that will look like. I guess that since the CREATE TYPE parameter is named COLLATABLE, we could extend in an upward-compatible way by adding a parameter COLLATION name, Yes. but I would just as soon not have a parameter that's got such an obviously short time-to-live. I think the COLLATABLE parameter would still have a reason to live even then. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sync Rep v19
On Sun, 2011-03-06 at 16:51 +0900, Fujii Masao wrote: One comment; what about introducing built-in function to wake up all the waiting backends? When replication connection is closed, if we STONITH the standby, we can safely (for not physical data loss but logical one) switch the primary to standalone mode. But there is no way to wake up the waiting backends for now. Setting synchronous_replication to OFF and reloading the configuration file doesn't affect the existing waiting backends. The attached patch introduces the pg_wakeup_all_waiters (better name?) function which wakes up all the backends on the queue. Will apply this as a separate commit. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SET TRANSACTION .. DEFERRABLE missing docs?
Magnus Hagander wrote: I was reading through ref/set_transaction.sgml and noticed that the only documentation of DEFERRABLE is that it's a PostgreSQL language extension, not anything about what it actually does. Same for begin and start_transaction. I see it described in README-SSI and for the guc default_transaction_deferrable, but I think it needs to be documented on that ref page as well.. (in fact, the guc docs refer to the reference page, which doesn't have more info) I think the attached covers it. -Kevin ssi-set-transaction-deferrable.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: How should the primary behave when the sync standby goes away? Re: [HACKERS] Sync Rep v17
On Fri, 2011-03-04 at 16:57 +0900, Fujii Masao wrote: On Wed, Mar 2, 2011 at 11:30 PM, Fujii Masao masao.fu...@gmail.com wrote: On Wed, Mar 2, 2011 at 8:22 PM, Simon Riggs si...@2ndquadrant.com wrote: The WALSender deliberately does *not* wake waiting users if the standby disconnects. Doing so would break the whole reason for having sync rep in the first place. What we do is allow a potential standby to takeover the role of sync standby, if one is available. Or the failing standby can reconnect and then release waiters. If there is potential standby when synchronous standby has gone, I agree that it's not good idea to release the waiting backends soon. In this case, those backends should wait for next synchronous standby. On the other hand, if there is no potential standby, I think that the waiting backends should not wait for the timeout and should wake up as soon as synchronous standby has gone. Otherwise, those backends suspend for a long time (i.e., until the timeout expires), which would decrease the high-availability, I'm afraid. Keeping those backends waiting for the failed standby to reconnect is an idea. But this looks like the behavior for allow_standalone_primary = off. If allow_standalone_primary = on, it looks more natural to make the primary work alone without waiting the timeout. Also I think that the waiting backends should be released as soon as the last synchronous standby switches to asynchronous mode. Since there is no standby which is planning to reconnect, obviously they no longer need to wait. I've not done this, but we could. It can't run in a WALSender, so this code would need to live in either WALWriter or BgWriter. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
On Sun, 2011-03-06 at 18:09 -0500, Andrew Dunstan wrote: On 03/06/2011 05:51 PM, Simon Riggs wrote: Efficient transaction-controlled synchronous replication. I'm glad this is in, but I thought we agreed NOT to call it synchronous replication. The discussion on the thread was that its not sync rep unless we have the strictest guarantees. We have the strictest guarantees, so it qualifies as sync rep. Relaxations are possible and, to some people, desirable. Perhaps there is a more marketable term, and if so, we can rebrand. It wouldn't be the first time things got renamed in beta. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sync Rep v19
On Sat, 2011-03-05 at 21:11 +0100, Yeb Havinga wrote: I also got a first first 1000 tps score The committed version should be even faster. Would appreciate a retest. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Composite Index Structure
Hi all, I want to construct an Composite Index Structure i.e. a combination of gist and btree. What i am thinking is that first creating a Rtree structure that is pointing to another Btree structure. For example, Suppose i want to find vehicles between 2 to 4 pm on 14/2/2011 on X road. I am thinking of creating rtree structure for road network and then btree for time. For reaching X road i use Rtree, and from there btree begin i.e. leaf node of rtree contains the pointer to root node of btree ( in this way i have all time belonging to X road) My question is that how to implement this composite index structure in postgres? Let us suppose, if i create mygist index, then i have to write my own operator class? or can i use gist index as it is and btree tree as it is. I mean their operator class and their gist methods but how to establish linkage between them? Any idea ?? Thanks Raj
Re: [HACKERS] Composite Index Structure
On 07.03.2011 08:07, Nick Raj wrote: I want to construct an Composite Index Structure i.e. a combination of gist and btree. What i am thinking is that first creating a Rtree structure that is pointing to another Btree structure. For example, Suppose i want to find vehicles between 2 to 4 pm on 14/2/2011 on X road. I am thinking of creating rtree structure for road network and then btree for time. For reaching X road i use Rtree, and from there btree begin i.e. leaf node of rtree contains the pointer to root node of btree ( in this way i have all time belonging to X road) My question is that how to implement this composite index structure in postgres? Let us suppose, if i create mygist index, then i have to write my own operator class? or can i use gist index as it is and btree tree as it is. I mean their operator class and their gist methods but how to establish linkage between them? It sounds like a use case for a multi-column gist index. See btree_gist contrib module. You'll want something like: CREATE INDEX ... USING gist (coordinates, time) -- 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] Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
On 07.03.2011 01:28, Simon Riggs wrote: On Sun, 2011-03-06 at 18:09 -0500, Andrew Dunstan wrote: On 03/06/2011 05:51 PM, Simon Riggs wrote: Efficient transaction-controlled synchronous replication. I'm glad this is in, but I thought we agreed NOT to call it synchronous replication. The discussion on the thread was that its not sync rep unless we have the strictest guarantees. We have the strictest guarantees, so it qualifies as sync rep. What do you mean by strictes guarantees? I don't see allow_synchronous_standby setting in the committed patch. I presume you didn't make allow_synchronous_standby=off the default behavior. Also, the documentation that describes this as two-safe replication and claims that the only possibility that data can be lost is if both the primary and the standby suffer crashes at the same time needs big fat caveats to clarify that this doesn't actually achieve those guarantees. Please change the name. -- 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] Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
On Mon, 2011-03-07 at 09:29 +0200, Heikki Linnakangas wrote: I presume you didn't make allow_synchronous_standby=off the default behavior. You presume incorrectly. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] German Ladies start translation project
On 05.03.2011 20:09, Heikki Linnakangas wrote: So the number of lines has roughly doubled since, and about a quarter of the 7.3 lines have changed. Heikki, Yeah. Additionally, German language vocabulary changed in computer area. E.g. today download is an official German word - ten years ago it wasn't. Susanne -- Susanne Ebrecht Bielefeld -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
On 07.03.2011 09:48, Simon Riggs wrote: On Mon, 2011-03-07 at 09:29 +0200, Heikki Linnakangas wrote: I presume you didn't make allow_synchronous_standby=off the default behavior. Sorry, s/allow_synchronous_standby/allow_standalone_master You presume incorrectly. Ok, ok then. Thank you! Looks like I need to git pull and get myself up-to-speed with these latest developments :-). -- 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
