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 http://www.
Fujii Masao writes:
> On Thu, Mar 3, 2011 at 12:11 AM, Heikki Linnakangas
> 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 to
On Tue, Mar 01, 2011 at 08:40:37AM -0500, Robert Haas wrote:
> On Mon, Feb 28, 2011 at 10:32 PM, Greg Stark wrote:
> > On Tue, Mar 1, 2011 at 1:43 AM, David Christensen
> > wrote:
> >> Was this cluster upgraded to 8.4.4 from 8.4.0? It sounds to me like a
> >> known bug in 8.4.0 which was fixed
David Fetter 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 previous complai
On Mar 2, 2011, at 11:00 PM, Tom Lane wrote:
> "David E. Wheeler" 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,
"David E. Wheeler" 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 that it won't happ
On Thu, 2011-03-03 at 13:35 +0900, Fujii Masao wrote:
> On Thu, Mar 3, 2011 at 12:11 AM, Heikki Linnakangas
> 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 comm
On Thu, Mar 3, 2011 at 12:11 AM, Heikki Linnakangas
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 to make more sense.
Regards,
-
On Thu, Mar 3, 2011 at 6:33 AM, Robert Haas 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 allows the database s
On Thu, Mar 3, 2011 at 5:50 AM, Robert Haas 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
sync_replication_time
On Thu, Mar 3, 2011 at 3:22 AM, Alvaro Herrera 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 recycle old WAL segments. C
On Wed, Mar 02, 2011 at 04:20:24PM -0800, bricklen wrote:
> On Wed, Mar 2, 2011 at 3:53 PM, daveg 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/4
On Wed, Mar 2, 2011 at 3:53 PM, daveg 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 ma
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
> > message
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?
C
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
> >>> t
Yeb Havinga 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
> I
On Wed, 2011-03-02 at 16:16 -0500, Tom Lane wrote:
> Simon Riggs 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
> >> fe
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
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 sinc
On Wed, Mar 2, 2011 at 4:19 PM, Dimitri Fontaine wrote:
> Robert Haas 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 cle
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 v
"David E. Wheeler" 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 subscription:
http://
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
allow_standal
"David E. Wheeler" 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 pgsql-hackers mailing l
Robert Haas 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 on the
That ju
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. L
Simon Riggs 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 probably stay as
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 b
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 beari
Simon Riggs 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 specified, so no
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
Peter Eisentraut 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
>> collat
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 th
On Wed, Mar 2, 2011 at 3:45 PM, Kevin Grittner
wrote:
> Simon Riggs 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 the
Simon Riggs 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 retrieved. You can't ass
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 a
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
Joe Conway 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 occasionally seeing d
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
On Wed, 2011-03-02 at 14:26 -0600, Kevin Grittner wrote:
> Heikki Linnakangas 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
Andy Colson 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 for. You could t
Heikki Linnakangas 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 "synchronous replication" in
> the
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
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 thin
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 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 bette
Teodor Sigaev 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 (pgsql-hackers@postgresql.o
On Thu, Mar 3, 2011 at 12:54 AM, Andrew Dunstan wrote:
>
>
> On 03/02/2011 02:16 PM, Dave Page wrote:
>>
>> On Thu, Mar 3, 2011 at 12:42 AM, 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
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 h
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
> > wrote:
> >> On 02.03.2011 12:40, Simon Riggs wrote:
> >>>
> >>> allow_standalone_primary seems to need to be better through than it is
On 03/02/2011 02:16 PM, Dave Page wrote:
On Thu, Mar 3, 2011 at 12:42 AM, 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 b
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 cr
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 Thu, Mar 3, 2011 at 12:42 AM, 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 c
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 r
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 (pgsql-hackers@
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 in
Thank you! now I understand it...
On Wed, Mar 2, 2011 at 7:35 PM, Tom Lane wrote:
> Marios Vodas 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 Visua
2011/3/1 Andrew Dunstan :
> 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 parent/child/ancestor/
On Wed, Mar 2, 2011 at 12:39 PM, Merlin Moncure wrote:
> On Wed, Mar 2, 2011 at 9:58 AM, Dimitri Fontaine
> wrote:
>> Heikki Linnakangas 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 w
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 (pgsql-hackers@postgresql.o
On Wed, Mar 2, 2011 at 9:58 AM, Dimitri Fontaine wrote:
> Heikki Linnakangas 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 migh
Marios Vodas 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 to_composite(
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,
4))'::m_segment_ba
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
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 appa
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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 though, and did not f
On Wed, Mar 2, 2011 at 2:30 PM, Fujii Masao 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.
> 7. New primary does
Heikki Linnakangas 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 and simple. That's fine for a
> l
Heikki Linnakangas 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 issue a warning message, or
>> t
On 02/03/11 16:28, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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 module, or the plp
On 02.03.2011 17:07, Robert Haas wrote:
On Wed, Mar 2, 2011 at 9:53 AM, 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 thin
On 02.03.2011 17:07, Robert Haas wrote:
On Wed, Mar 2, 2011 at 9:30 AM, Fujii Masao 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 clie
On Wed, Mar 2, 2011 at 9:53 AM, 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 t
On Wed, Mar 2, 2011 at 9:30 AM, Fujii Masao 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 that case, WAL ha
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 curr
On Wed, Mar 2, 2011 at 7:40 PM, Simon Riggs 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.
>
> allow_standalone_primary s
On Wed, Mar 2, 2011 at 8:22 PM, Simon Riggs 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
On Wed, Mar 2, 2011 at 6:22 AM, Simon Riggs 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
On 02/03/11 14:25, Robert Haas wrote:
> On Wed, Mar 2, 2011 at 6:14 AM, Jan Urbański 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 circum
On Wed, Mar 2, 2011 at 6:14 AM, Jan Urbański 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
> spiexcept
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 cur
--On 28. Februar 2011 15:02:30 -0500 Tom Lane 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 librrd would be a solu
On Tue, 2011-03-01 at 15:25 +0900, Fujii Masao wrote:
> On Tue, Mar 1, 2011 at 9:19 AM, Simon Riggs 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 transaction is w
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 Berkus writes:
>> I'm ok with closing things as of th
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 neithe
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 http://www.rumko.net/0001-DragonFly-BSD-support-
89 matches
Mail list logo
