On Tuesday 1. of March 2011 23:05:17 Rumko wrote:
On Tuesday 1. of March 2011 22:44:16 Peter Eisentraut wrote:
On tis, 2011-03-01 at 22:22 +0100, Rumko wrote:
Well, wouldn't consider it ugly, but the patch (attached and available
at
On Tue, 2011-03-01 at 15:25 +0900, Fujii Masao wrote:
No, I've never wished wait-forever option for now. I'd like to make
the primary work alone when there is no connected standby, for
high-availability.
allow_standalone_primary seems to need to be better through than it is
now, yet neither
On 02/03/11 01:05, Andrew Dunstan wrote:
On 03/01/2011 05:19 PM, Jan Urbański wrote:
On 01/03/11 22:07, Andrew Dunstan wrote:
On 03/01/2011 03:53 PM, Jan Urbański wrote:
On 01/03/11 21:35, Tom Lane wrote:
Josh Berkusj...@agliodbs.com writes:
I'm ok with closing things as of the end of
On Tue, 2011-03-01 at 15:25 +0900, Fujii Masao wrote:
On Tue, Mar 1, 2011 at 9:19 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2011-02-28 at 18:40 +, Simon Riggs wrote:
SyncRepReleaseWaiters should be called when walsender exits. Otherwise,
if the standby crashes while a
--On 28. Februar 2011 15:02:30 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
Because it's fifty times more mechanism than we need here? We don't
want a SQL interface (not even a lightweight one) and it's unclear that
we ever want the data to go to disk at all.
I wonder wether a library like
On 2011-03-02 11:40, Simon Riggs wrote:
allow_standalone_primary seems to need to be better through than it is
now, yet neither of us think its worth having.
If the people that want it can think it through a little better then it
might make this release, but I propose to remove it from this
On Wed, Mar 2, 2011 at 6:14 AM, Jan Urbański wulc...@wulczer.org wrote:
That seems to have fixed it, so I have applied the patch. Would you like
to supply some comments to got with it?
The comment would be something like
/* XXX it appears that in some circumstantes the reference count of the
On 02/03/11 14:25, Robert Haas wrote:
On Wed, Mar 2, 2011 at 6:14 AM, Jan Urbański wulc...@wulczer.org wrote:
That seems to have fixed it, so I have applied the patch. Would you like
to supply some comments to got with it?
The comment would be something like
/* XXX it appears that in some
On Wed, Mar 2, 2011 at 6:22 AM, 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
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
On Wed, Mar 2, 2011 at 7:40 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2011-03-01 at 15:25 +0900, Fujii Masao wrote:
No, I've never wished wait-forever option for now. I'd like to make
the primary work alone when there is no connected standby, for
high-availability.
On 02.03.2011 12:40, Simon Riggs wrote:
allow_standalone_primary seems to need to be better through than it is
now, yet neither of us think its worth having.
If the people that want it can think it through a little better then it
might make this release, but I propose to remove it from this
On Wed, Mar 2, 2011 at 9:30 AM, Fujii Masao masao.fu...@gmail.com wrote:
What I'm thinking is: when the waiting backends are released because
of the timeout while the fast shutdown is being done in the master,
those backends should not return the success indication to the client.
Of course, in
On Wed, Mar 2, 2011 at 9:53 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 02.03.2011 12:40, Simon Riggs wrote:
allow_standalone_primary seems to need to be better through than it is
now, yet neither of us think its worth having.
If the people that want it can think it
On 02.03.2011 17:07, Robert Haas wrote:
On Wed, Mar 2, 2011 at 9:30 AM, Fujii Masaomasao.fu...@gmail.com wrote:
What I'm thinking is: when the waiting backends are released because
of the timeout while the fast shutdown is being done in the master,
those backends should not return the success
On 02.03.2011 17:07, Robert Haas wrote:
On Wed, Mar 2, 2011 at 9:53 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 02.03.2011 12:40, Simon Riggs wrote:
allow_standalone_primary seems to need to be better through than it is
now, yet neither of us think its worth having.
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
On 02/03/11 14:25, Robert Haas wrote:
But does bumping the ref count then create a leak the rest of the time?
Not really, because you never want to garbage collect the spiexceptions
module (just like you don't want to GC th plpy
On 02/03/11 16:28, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
On 02/03/11 14:25, Robert Haas wrote:
But does bumping the ref count then create a leak the rest of the time?
Not really, because you never want to garbage collect the spiexceptions
module (just
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
To achieve the effect Fujii is looking for, we would have to silently drop
the connection. That would correctly leave the client not knowing whether
the transaction committed or not.
+1
It might be reasonable to COMMIT but also
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
The defining property of synchronous replication is that when a
transaction is acknowledged as committed to the client, it has
also been replicated to the standby. You don't achieve that with
allow_standalone_primary=on, plain
On Wed, Mar 2, 2011 at 2:30 PM, Fujii Masao masao.fu...@gmail.com wrote:
1. The primary is running with allow_standalone_primary = on. There
is only one (synchronous) standby connected.
OK. Explicitly configured to allow the master to report as commited
stuff which isn't on a/any slave.
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
FWIW I looked at these patches yesterday when I was trying to reproduce
the bug, but did not find anything interesting. It's mostly for stuff in
the standard library. I haven't tried building Python with all of of
these patches
On 03/02/2011 11:49 AM, Tom Lane wrote:
Well, we can eliminate that last theory, because there were both 32 and
64 bit buildfarm machines showing the crash, cf bobcat and crake.
BTW, I see the former is now running F14, not F13 as claimed on the
buildfarm dashboard,
That's because David
On Wed, Mar 02, 2011 at 12:02:30PM -0500, Andrew Dunstan wrote:
On 03/02/2011 11:49 AM, Tom Lane wrote:
Well, we can eliminate that last theory, because there were both 32 and
64 bit buildfarm machines showing the crash, cf bobcat and crake.
BTW, I see the former is now running F14, not F13 as
I have developed some custom composite and base types in PostgreSQL 9 which
you can find in the code I provide below.
I compile my C library using GCC 4.5 under Linux and Visual Studio 2010
under Windows.
The problem is when I run this command: *SELECT to_composite('((1, 2), (3,
Marios Vodas mvo...@gmail.com writes:
I have developed some custom composite and base types in PostgreSQL 9 which
you can find in the code I provide below.
I compile my C library using GCC 4.5 under Linux and Visual Studio 2010
under Windows.
The problem is when I run this command: *SELECT
On Wed, Mar 2, 2011 at 9:58 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
To achieve the effect Fujii is looking for, we would have to silently drop
the connection. That would correctly leave the client not knowing whether
the
On Mar 2, 2011, at 9:02 AM, Andrew Dunstan wrote:
That's because David apparently hasn't run update_personality.pl, although he
has in the past.
Is this something we can run against crazier community members?
Best,
David
--
Sent via pgsql-hackers mailing list
On Wed, Mar 2, 2011 at 12:39 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Wed, Mar 2, 2011 at 9:58 AM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
To achieve the effect Fujii is looking for, we would have to silently drop
2011/3/1 Andrew Dunstan and...@dunslane.net:
I think hierarchical data really only scratches the surface of the problem.
It would be nice to be able to specify all sorts of context for searches:
* foo after bar
* foo near bar
* foo and bar in the same paragraph
* foo as a
Thank you! now I understand it...
On Wed, Mar 2, 2011 at 7:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Marios Vodas mvo...@gmail.com writes:
I have developed some custom composite and base types in PostgreSQL 9
which
you can find in the code I provide below.
I compile my C library using
I noticed that in standalone mode, WAL segments don't seem to be
recycled. This could get problematic if you're forced to vacuum large
tables in that mode and space for WAL is short.
I can reproduce in HEAD easily by doing a large bulk insertion in
standalone mode. If I stop the server, start
Hello,
I've produced a dumb patch for psql which allow to use tab completion after
JOIN keyword.
Patch was done against 2f6c8453cf3f38a70adbcb59489630cd5be92570 revision from
GitHub mirror.
join_completion.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list
Excerpts from Andrew Dunstan's message of mié mar 02 14:02:30 -0300 2011:
On 03/02/2011 11:49 AM, Tom Lane wrote:
Well, we can eliminate that last theory, because there were both 32 and
64 bit buildfarm machines showing the crash, cf bobcat and crake.
BTW, I see the former is now running
On Thu, Mar 3, 2011 at 12:42 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Andrew Dunstan's message of mié mar 02 14:02:30 -0300 2011:
On 03/02/2011 11:49 AM, Tom Lane wrote:
Well, we can eliminate that last theory, because there were both 32 and
64 bit buildfarm
On ons, 2011-03-02 at 09:10 +0100, Rumko wrote:
What about this patch (
http://www.rumko.net/0001-DragonFly-BSD-support-linked-nbsd.patch )?
instead of linking to freebsd, it's linked to netbsd and It still
compiles due to the two templates being similar enough.
Looks good. Committed.
--
On 03/02/2011 02:12 PM, Alvaro Herrera wrote:
Excerpts from Andrew Dunstan's message of mié mar 02 14:02:30 -0300 2011:
On 03/02/2011 11:49 AM, Tom Lane wrote:
Well, we can eliminate that last theory, because there were both 32 and
64 bit buildfarm machines showing the crash, cf bobcat and
On 03/02/2011 02:16 PM, Dave Page wrote:
On Thu, Mar 3, 2011 at 12:42 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Andrew Dunstan's message of mié mar 02 14:02:30 -0300 2011:
On 03/02/2011 11:49 AM, Tom Lane wrote:
Well, we can eliminate that last theory, because
On Wed, 2011-03-02 at 17:23 +0200, Heikki Linnakangas wrote:
On 02.03.2011 17:07, Robert Haas wrote:
On Wed, Mar 2, 2011 at 9:53 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 02.03.2011 12:40, Simon Riggs wrote:
allow_standalone_primary seems to need to be better
On 1/23/2011 5:11 AM, Michael Meskes wrote:
On Sat, Jan 22, 2011 at 08:40:13PM -0500, Andrew Dunstan wrote:
I think these really need to be rewritten from scratch. They look
like they were written by someone who never heard of Perl 5 (it's
only about 16 years old).
You might remember that we
On Thu, Mar 3, 2011 at 12:54 AM, Andrew Dunstan and...@dunslane.net wrote:
On 03/02/2011 02:16 PM, Dave Page wrote:
On Thu, Mar 3, 2011 at 12:42 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Andrew Dunstan's message of mié mar 02 14:02:30 -0300 2011:
On 03/02/2011
Teodor Sigaev teo...@sigaev.ru writes:
[ builtin_knngist_contrib_btree_gist-0.12 patch ]
Applied with some corrections --- mostly, that the upgrade script was
all wet. I added some documentation too.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Wed, 2011-03-02 at 16:53 +0200, Heikki Linnakangas wrote:
On 02.03.2011 12:40, Simon Riggs wrote:
allow_standalone_primary seems to need to be better through than it is
now, yet neither of us think its worth having.
If the people that want it can think it through a little better then
It occurred to me that it might be a good idea to describe how
I've been testing extension upgrade scripts. So:
1. Install the 9.0 version of the module in an empty 9.0 database.
pg_dump this database.
2. Load the pg_dump script into an empty 9.1 database, with the
underlying shared library (if
On 02.03.2011 21:48, Simon Riggs wrote:
On Wed, 2011-03-02 at 16:53 +0200, Heikki Linnakangas wrote:
On 02.03.2011 12:40, Simon Riggs wrote:
allow_standalone_primary seems to need to be better through than it is
now, yet neither of us think its worth having.
If the people that want it can
I'm working with a client on an application upgrade script which
executes a function to conditionally do an:
ALTER TABLE foo ALTER COLUMN bar SET DATA TYPE baz
If this is run while the application is concurrently doing inserts into
foo, we are occasionally seeing deadlocks. Aside from the fact
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
All I'm saying is that if we end up shipping without that
parameter (implying allow_standalone_primary=on), we need to call
the feature something else. The GUCs and code can probably stay as
it is, but we shouldn't use the term
Andy Colson a...@squeakycode.net writes:
Here is a parse.pl, with some major refactoring.
I am sure there are new bugs. I have not run it on anything but 9.0.1.
Are there other .y files you might feed it? (something other than
backend/parser/gram.y?)
That's the only file it has to work
On Wed, 2011-03-02 at 14:26 -0600, Kevin Grittner wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
All I'm saying is that if we end up shipping without that
parameter (implying allow_standalone_primary=on), we need to call
the feature something else. The GUCs and code
On Wed, 2011-03-02 at 22:10 +0200, Heikki Linnakangas wrote:
On 02.03.2011 21:48, Simon Riggs wrote:
On Wed, 2011-03-02 at 16:53 +0200, Heikki Linnakangas wrote:
On 02.03.2011 12:40, Simon Riggs wrote:
allow_standalone_primary seems to need to be better through than it is
now, yet neither
Joe Conway m...@joeconway.com writes:
I'm working with a client on an application upgrade script which
executes a function to conditionally do an:
ALTER TABLE foo ALTER COLUMN bar SET DATA TYPE baz
If this is run while the application is concurrently doing inserts into
foo, we are
On 03/02/2011 03:39 PM, Simon Riggs wrote:
Truly synchronous requires two-phase commit, which this never was. So
the absence or presence of the poorly specified parameter called
allow_standalone_primary should have no bearing on what we call this
feature.
I haven't been following this very
On tis, 2011-03-01 at 16:31 -0500, Tom Lane wrote:
I can't say that this makes me think any better of the design here.
If a boolean true/false is a sufficient representation of a type's
collation property, why isn't the column in pg_type just a boolean?
If the idea of storing an OID is to
Simon Riggs si...@2ndquadrant.com wrote:
allow_standalone_primary=off means wait forever. It does nothing
to reduce data loss since you can't replicate to a server that
isn't there.
Unless you're pulling from some persistent source which will then
feel free to discard what you have
On Wed, Mar 2, 2011 at 3:45 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Simon Riggs si...@2ndquadrant.com wrote:
allow_standalone_primary=off means wait forever. It does nothing
to reduce data loss since you can't replicate to a server that
isn't there.
Unless you're pulling from
On 03/02/2011 12:41 PM, Tom Lane wrote:
Looks like the process trying to do the ALTER has already got some
lower-level lock on the table. It evidently hasn't got
AccessExclusiveLock, but nonetheless has something strong enough to
block an INSERT, such as ShareLock.
Hmmm, is it possible that
Peter Eisentraut pete...@gmx.net writes:
On tis, 2011-03-01 at 16:31 -0500, Tom Lane wrote:
If a boolean true/false is a sufficient representation of a type's
collation property, why isn't the column in pg_type just a boolean?
If the idea of storing an OID is to allow reference to a choice of
On Wed, 2011-03-02 at 15:50 -0500, Robert Haas wrote:
I assumed that when Simon was talking about removing
allow_standalone_primary, he meant making the code always behave as if
it were turned OFF.
That is the part that is currently not fully specified, so no that is
not currently included
Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2011-03-02 at 15:50 -0500, Robert Haas wrote:
I assumed that when Simon was talking about removing
allow_standalone_primary, he meant making the code always behave
as if it were turned OFF.
That is the part that is currently not fully
On Wed, 2011-03-02 at 15:44 -0500, Andrew Dunstan wrote:
On 03/02/2011 03:39 PM, Simon Riggs wrote:
Truly synchronous requires two-phase commit, which this never was. So
the absence or presence of the poorly specified parameter called
allow_standalone_primary should have no bearing on
It's about dependences.
If my extension requires a procedural language, will adding that language to
the `requires` control key do what I think it should do?
If not, how should one require a PL? Come to think of it, how might I require
other features that might not be included in a particular
Simon Riggs si...@2ndquadrant.com writes:
On Wed, 2011-03-02 at 22:10 +0200, Heikki Linnakangas wrote:
Fair enough. All I'm saying is that if we end up shipping without that
parameter (implying allow_standalone_primary=on), we need to call the
feature something else. The GUCs and code can
You should blog this.
David
On Mar 2, 2011, at 11:58 AM, Tom Lane wrote:
It occurred to me that it might be a good idea to describe how
I've been testing extension upgrade scripts. So:
1. Install the 9.0 version of the module in an empty 9.0 database.
pg_dump this database.
2. Load
Robert Haas robertmh...@gmail.com writes:
1. Everything is humming along.
2. The network link between the master and standby drops.
3. Then it comes back up again.
After (2) and before (3), what should the behavior the master be? It
seems clear to me that it should WAIT. Otherwise, a crash
David E. Wheeler da...@kineticode.com writes:
You should blog this.
[ shrug... ] I don't own a blog, and if I did the entries in it would
not be included in the pgsql archives, which is where material like this
probably ought to be.
regards, tom lane
--
Sent via
On 03/02/2011 04:13 PM, Simon Riggs wrote:
On Wed, 2011-03-02 at 15:44 -0500, Andrew Dunstan wrote:
On 03/02/2011 03:39 PM, Simon Riggs wrote:
Truly synchronous requires two-phase commit, which this never was. So
the absence or presence of the poorly specified parameter called
David E. Wheeler da...@kineticode.com writes:
You should blog this.
He just did, didn't he? :)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Tue, Mar 01, 2011 at 01:20:43PM -0800, daveg wrote:
On Tue, Mar 01, 2011 at 12:00:54AM +0200, Heikki Linnakangas wrote:
On 28.02.2011 23:28, daveg wrote:
On Wed, Jan 12, 2011 at 10:46:14AM +0200, Heikki Linnakangas wrote:
We'll likely need to go back and forth a few times with various
On Wed, Mar 2, 2011 at 4:19 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
1. Everything is humming along.
2. The network link between the master and standby drops.
3. Then it comes back up again.
After (2) and before (3), what should the
Excerpts from daveg's message of mié mar 02 18:30:34 -0300 2011:
After a restart and vacuum of all dbs with no other activity things were
quiet for a couple hours and then we started seeing these PD_ALL_VISIBLE
messages again.
Going back through the logs we have been getting these since at
On 2011-03-02 21:26, Kevin Grittner wrote:
I think including synchronous is OK as long as it's properly
qualified. Off-hand thoughts in no particular order:
semi-synchronous
conditionally synchronous
synchronous with automatic failover to standalone
It would be good to name the concept equal
On Wed, 2011-03-02 at 16:16 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Wed, 2011-03-02 at 22:10 +0200, Heikki Linnakangas wrote:
Fair enough. All I'm saying is that if we end up shipping without that
parameter (implying allow_standalone_primary=on), we need to call
Yeb Havinga yebhavi...@gmail.com wrote:
On 2011-03-02 21:26, Kevin Grittner wrote:
I think including synchronous is OK as long as it's properly
qualified. Off-hand thoughts in no particular order:
semi-synchronous
conditionally synchronous
synchronous with automatic failover to standalone
On Wed, 2011-03-02 at 16:24 -0500, Andrew Dunstan wrote:
On 03/02/2011 04:13 PM, Simon Riggs wrote:
On Wed, 2011-03-02 at 15:44 -0500, Andrew Dunstan wrote:
On 03/02/2011 03:39 PM, Simon Riggs wrote:
Truly synchronous requires two-phase commit, which this never was. So
the absence or
On Wed, Mar 02, 2011 at 07:45:05PM +, Tom Lane wrote:
Add KNNGIST support to contrib/btree_gist.
This extends GiST's support for nearest-neighbor searches to many of the
standard data types.
Teodor Sigaev
Neat!
What stands between where we are and including these in 9.2 core?
On Wed, Mar 02, 2011 at 06:45:13PM -0300, Alvaro Herrera wrote:
Excerpts from daveg's message of mié mar 02 18:30:34 -0300 2011:
After a restart and vacuum of all dbs with no other activity things were
quiet for a couple hours and then we started seeing these PD_ALL_VISIBLE
messages
On Wed, Mar 2, 2011 at 3:53 PM, daveg da...@sonic.net wrote:
Postgresql version is 8.4.4.
I don't see how this could be related, but since you're running on NFS,
maybe it is, somehow:
http://archives.postgresql.org/message-id/4d40ddb7.1010...@credativ.com
(for example what if the visibility
On Wed, Mar 02, 2011 at 04:20:24PM -0800, bricklen wrote:
On Wed, Mar 2, 2011 at 3:53 PM, daveg da...@sonic.net wrote:
Postgresql version is 8.4.4.
I don't see how this could be related, but since you're running on NFS,
maybe it is, somehow:
On Thu, Mar 3, 2011 at 3:22 AM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote:
I noticed that in standalone mode, WAL segments don't seem to be
recycled. This could get problematic if you're forced to vacuum large
tables in that mode and space for WAL is short.
Checkpoint is required to
On Thu, Mar 3, 2011 at 5:50 AM, Robert Haas robertmh...@gmail.com wrote:
I agree. I assumed that when Simon was talking about removing
allow_standalone_primary, he meant making the code always behave as if
it were turned OFF.
I feel the same thing.. Despite his saying, the patch implements
On Thu, Mar 3, 2011 at 6:33 AM, Robert Haas robertmh...@gmail.com wrote:
I don't understand how synchronous replication with
allow_standalone_primary=on gives you ANY extra nines.
When you start the primary (or when there is one connected standby and
it crashes), allow_standalone_primary = on
On Thu, Mar 3, 2011 at 12:11 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
To achieve the effect Fujii is looking for, we would have to silently drop
the connection. That would correctly leave the client not knowing whether
the transaction committed or not.
Yeah, this seems
On Thu, 2011-03-03 at 13:35 +0900, Fujii Masao wrote:
On Thu, Mar 3, 2011 at 12:11 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
To achieve the effect Fujii is looking for, we would have to silently drop
the connection. That would correctly leave the client not knowing
David E. Wheeler da...@kineticode.com writes:
If my extension requires a procedural language, will adding that language to
the `requires` control key do what I think it should do?
No.
Probably in future the standard PLs will be packaged as extensions, and
then it will work. The main reason
On Mar 2, 2011, at 11:00 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
If my extension requires a procedural language, will adding that language to
the `requires` control key do what I think it should do?
No.
Probably in future the standard PLs will be packaged as
David Fetter da...@fetter.org writes:
On Wed, Mar 02, 2011 at 07:45:05PM +, Tom Lane wrote:
Add KNNGIST support to contrib/btree_gist.
What stands between where we are and including these in 9.2 core?
Well, the inet case at least is not up to the standards I'd expect
of core code; see
On Tue, Mar 01, 2011 at 08:40:37AM -0500, Robert Haas wrote:
On Mon, Feb 28, 2011 at 10:32 PM, Greg Stark gsst...@mit.edu wrote:
On Tue, Mar 1, 2011 at 1:43 AM, David Christensen da...@endpoint.com
wrote:
Was this cluster upgraded to 8.4.4 from 8.4.0? It sounds to me like a
known bug
Fujii Masao masao.fu...@gmail.com writes:
On Thu, Mar 3, 2011 at 12:11 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
To achieve the effect Fujii is looking for, we would have to silently drop
the connection. That would correctly leave the client not knowing whether
the
On 02.03.2011 20:28, Andrey Popp wrote:
I've produced a dumb patch for psql which allow to use tab completion after
JOIN keyword.
Patch was done against 2f6c8453cf3f38a70adbcb59489630cd5be92570 revision from
GitHub mirror.
Thanks, applied.
--
Heikki Linnakangas
EnterpriseDB
89 matches
Mail list logo
