On tis, 2010-12-28 at 20:51 -0500, Andrew Dunstan wrote:
> try:
>
> diff -F '^CREATE' ...
This works about 67% of the time and still doesn't actually tell at a
glance what changed. It will only tell you what the change you are
currently looking at probably belongs to.
--
Sent via pgsql-hack
On tis, 2010-12-28 at 12:33 -0500, Tom Lane wrote:
> (2) randomly different ordering of rows within a table. Your patch
> didn't address that, unless I misunderstood quite a bit.
This issue here is just comparing schemas, so that part is a separate
problem for someone else.
> I think the correct
We're coming the end of the 9.1 development cycle, and I think that
there is a serious danger of insufficient bandwidth to handle the
large patches we have outstanding. For my part, I am hoping to find
the bandwidth to two, MAYBE three major commits between now and the
end of 9.1CF4, but I am not
On Mon, Dec 27, 2010 at 10:16 PM, Robert Haas wrote:
> On Sat, Dec 25, 2010 at 11:52 PM, Robert Haas wrote:
>> I'm working on getting a first chunk of this committed.
>
> OK, here's the patch.
I've now committed a version of this with a bunch of further
revisions, corrections, and cleanup. It l
On Sat, Jan 1, 2011 at 6:54 AM, Simon Riggs wrote:
> Yes, working out the math is a good idea. Things are much clearer if we
> do that.
>
> Let's assume we have 98% availability on any single server.
>
> 1. Having one primary and 2 standbys, either of which can acknowledge,
> and we never lock up
On Sat, Jan 1, 2011 at 6:08 PM, Simon Riggs wrote:
> On Sat, 2011-01-01 at 14:40 -0800, Josh Berkus wrote:
>
>> Standby in general deals with the A,D,R triangle (Availability,
>> Durability, Response time). "Any one" configuration is the A,R
>> configuration, and the only reason to go out with it
On Sat, 2011-01-01 at 14:40 -0800, Josh Berkus wrote:
> Standby in general deals with the A,D,R triangle (Availability,
> Durability, Response time). "Any one" configuration is the A,R
> configuration, and the only reason to go out with it for 9.1 is
> because it's simpler to implement than the D
On Sat, 2011-01-01 at 21:41 +0200, Heikki Linnakangas wrote:
> On 31.12.2010 23:18, Hannu Krosing wrote:
> > On 31.12.2010 13:40, Heikki Linnakangas wrote:
> >> That thread makes no mention of how to specify which standbys are
> >> synchronous and which are not.
> > The simplest way would be to hav
On 1/1/11 5:59 AM, Stefan Kaltenbrunner wrote:
> well you keep saying that but to be honest I cannot really even see a
> usecase for me - what is "only a random one of a set of servers is sync
> at any time and I don't really know which one".
> My usecases would al involved 2 sync standbys and 1 or
On Sat, Jan 1, 2011 at 4:28 PM, Peter Eisentraut wrote:
> On lör, 2011-01-01 at 00:05 -0500, Robert Haas wrote:
>> Yeah, and I still believe that. I'm having difficulty coming up with
>> a workable approach, though.
>
> I don't see anything wrong with having 20 or 30 messages of variants of
>
> "
On Sat, Jan 1, 2011 at 4:24 PM, Peter Eisentraut wrote:
> On lör, 2011-01-01 at 13:17 -0500, Tom Lane wrote:
>> ALTER RENAME and ALTER SET SCHEMA are both in the nature of changing the
>> object's identity. Consider the fairly typical use-case where you are
>> renaming an "old" instance out of th
On lör, 2011-01-01 at 10:00 -0500, Robert Haas wrote:
> Is it in any better if we write one string per feature, like this:
>
> constraints cannot be used on %s
> triggers cannot be used on %s
>
> ...where %s is a plural object type (views, foreign tables, etc.).
No, this won't work.
--
Sent v
On lör, 2011-01-01 at 00:05 -0500, Robert Haas wrote:
> Yeah, and I still believe that. I'm having difficulty coming up with
> a workable approach, though.
I don't see anything wrong with having 20 or 30 messages of variants of
"foo cannot be used on bar"
without placeholders.
--
Sent via pg
On lör, 2011-01-01 at 13:17 -0500, Tom Lane wrote:
> ALTER RENAME and ALTER SET SCHEMA are both in the nature of changing the
> object's identity. Consider the fairly typical use-case where you are
> renaming an "old" instance out of the way and renaming another one into
> the same schema/name. D
I've got low-level routines coded for interfacing predicate.c to SLRU
to handle old committed transactions, so that SSI can deal with
situations where a large number of transactions are run during the
lifetime of a single serializable transaction. I'm not actually
*using* these new functions yet,
Robert Treat wrote:
> > > What _is_ interesting is that Postgres often has sequential and
> > > random/disk ways of doing things, and by reducing random_page_cost when
> > > using SSDs, you automatically use more random operations, so in a way
> > > the Postgres code was already prepared for SSD us
Peter Eisentraut wrote:
> On fre, 2010-12-31 at 17:26 -0500, Bruce Momjian wrote:
> > Patch applied, and TODO item removed because patch mostly detects if a
> > stale postmaster created the postmaster.pid file. The TODO was:
>
> Please fix this new compiler warning:
>
> pg_ctl.c:1787: warning: i
On fre, 2010-12-31 at 17:26 -0500, Bruce Momjian wrote:
> Patch applied, and TODO item removed because patch mostly detects if a
> stale postmaster created the postmaster.pid file. The TODO was:
Please fix this new compiler warning:
pg_ctl.c:1787: warning: implicit declaration of function ‘time’
On 31.12.2010 23:18, Hannu Krosing wrote:
On 31.12.2010 13:40, Heikki Linnakangas wrote:
That thread makes no mention of how to specify which standbys are
synchronous and which are not.
The simplest way would be to have separate database users for sync and
async standbys ?
That would allow any
On 01.01.2011 19:03, Simon Riggs wrote:
On Sat, 2011-01-01 at 17:37 +0100, Stefan Kaltenbrunner wrote:
On 01/01/2011 05:28 PM, Dimitri Fontaine wrote:
Stefan Kaltenbrunner writes:
well you keep saying that but to be honest I cannot really even see a
usecase for me - what is "only a random on
2010/12/30 JotaComm
> Hello,
>
> Last week I had a serious problem with my PostgreSQL database. My
> autovacuum is OFF, but in September it started to prevent the transaction
> wraparoud; however last week the following message appeared continuously in
> my log:
>
> WARNING: database "production"
On Sat, 2011-01-01 at 18:49 +0100, Stefan Kaltenbrunner wrote:
> hmm maybe my "surviving" standbys(the case I'm wondering about is
> whole
> datacenter failures which might take out more than just the master)
> was
> not clear - consider three boxes, one master and two standby and
> semisync rep
Simon Riggs writes:
> On Sat, 2011-01-01 at 11:06 -0500, Robert Haas wrote:
>> While reviewing the SQL/MED patch, I happened to notice that
>> ExecAlterObjectSchemaStmt calls AlterTableNamespace with a lock mode
>> argument of AccessExclusiveLock. Does anyone see a reason why
>> ShareUpdateExclusi
On 01/01/2011 06:29 PM, Simon Riggs wrote:
On Sat, 2011-01-01 at 18:13 +0100, Stefan Kaltenbrunner wrote:
On 01/01/2011 05:55 PM, Simon Riggs wrote:
It appears to me there has been substantial confusion over alternatives,
because of a misunderstanding about how synchronisation works. Requiring
On Sat, 2011-01-01 at 17:28 +0100, Dimitri Fontaine wrote:
> something visible through a system view for
> users? This as been asked for before and I was thinking there was a
> consensus on this.
Yes, it will be there.
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Dev
On Sat, 2011-01-01 at 18:13 +0100, Stefan Kaltenbrunner wrote:
> On 01/01/2011 05:55 PM, Simon Riggs wrote:
> >
> > It appears to me there has been substantial confusion over alternatives,
> > because of a misunderstanding about how synchronisation works. Requiring
> > confirmation that standbys ar
On Sat, 2011-01-01 at 11:06 -0500, Robert Haas wrote:
> While reviewing the SQL/MED patch, I happened to notice that
> ExecAlterObjectSchemaStmt calls AlterTableNamespace with a lock mode
> argument of AccessExclusiveLock. Does anyone see a reason why
> ShareUpdateExclusiveLock would be insufficie
On 01/01/2011 05:55 PM, Simon Riggs wrote:
On Sat, 2011-01-01 at 16:12 +0100, Stefan Kaltenbrunner wrote:
I still would like to get a statement on why simon thinks that
the design heikki and others have proposed
I've explained in huge detail why I think what I think, nor avoided any
technical
On Sat, 2011-01-01 at 17:37 +0100, Stefan Kaltenbrunner wrote:
> On 01/01/2011 05:28 PM, Dimitri Fontaine wrote:
> > Stefan Kaltenbrunner writes:
> >> well you keep saying that but to be honest I cannot really even see a
> >> usecase for me - what is "only a random one of a set of servers is sync
On Sat, 2011-01-01 at 16:12 +0100, Stefan Kaltenbrunner wrote:
> I still would like to get a statement on why simon thinks that
> the design heikki and others have proposed
I've explained in huge detail why I think what I think, nor avoided any
technical issue.
It appears to me there has been
On 01/01/2011 05:28 PM, Dimitri Fontaine wrote:
Stefan Kaltenbrunner writes:
well you keep saying that but to be honest I cannot really even see a
usecase for me - what is "only a random one of a set of servers is sync at
any time and I don't really know which one".
It looks easy enough to ge
On Sat, 2011-01-01 at 05:13 -0800, Jeff Janes wrote:
> On 12/31/10, Simon Riggs wrote:
> > On Fri, 2010-12-31 at 09:27 +0100, Stefan Kaltenbrunner wrote:
> >
> >> Maybe it has been discussed but I still don't see way it makes any
> >> sense. If I declare a standby a sync standby I better want it s
Stefan Kaltenbrunner writes:
> well you keep saying that but to be honest I cannot really even see a
> usecase for me - what is "only a random one of a set of servers is sync at
> any time and I don't really know which one".
It looks easy enough to get to know which one it is. Surely the primary
While reviewing the SQL/MED patch, I happened to notice that
ExecAlterObjectSchemaStmt calls AlterTableNamespace with a lock mode
argument of AccessExclusiveLock. Does anyone see a reason why
ShareUpdateExclusiveLock would be insufficient?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
Le 01/01/2011 16:00, Robert Haas a écrit :
> On Sat, Jan 1, 2011 at 9:53 AM, Guillaume Lelarge
> wrote:
>> Le 01/01/2011 06:05, Robert Haas a écrit :
>>> On Fri, Dec 31, 2010 at 8:48 AM, Peter Eisentraut wrote:
On tor, 2010-12-30 at 11:03 -0500, Robert Haas wrote:
> No, quite the opposit
On 01/01/2011 03:15 PM, Robert Haas wrote:
On Sat, Jan 1, 2011 at 9:03 AM, Stefan Kaltenbrunner
wrote:
that is exactly my point - if have no guarantee that your SYNC standby is
actually sync there is no use for it being used in business cases that
require sync replication.
If we cannot support
On Sat, Jan 1, 2011 at 9:53 AM, Guillaume Lelarge
wrote:
> Le 01/01/2011 06:05, Robert Haas a écrit :
>> On Fri, Dec 31, 2010 at 8:48 AM, Peter Eisentraut wrote:
>>> On tor, 2010-12-30 at 11:03 -0500, Robert Haas wrote:
No, quite the opposite. With the other approach, you needed:
Le 01/01/2011 06:05, Robert Haas a écrit :
> On Fri, Dec 31, 2010 at 8:48 AM, Peter Eisentraut wrote:
>> On tor, 2010-12-30 at 11:03 -0500, Robert Haas wrote:
>>> No, quite the opposite. With the other approach, you needed:
>>>
>>> constraints cannot be used on views
>>> constraints cannot be use
On Sat, Jan 1, 2011 at 9:03 AM, Stefan Kaltenbrunner
wrote:
> that is exactly my point - if have no guarantee that your SYNC standby is
> actually sync there is no use for it being used in business cases that
> require sync replication.
> If we cannot support that usecase I would either like to se
On 01/01/2011 02:13 PM, Jeff Janes wrote:
On 12/31/10, Simon Riggs wrote:
On Fri, 2010-12-31 at 09:27 +0100, Stefan Kaltenbrunner wrote:
Maybe it has been discussed but I still don't see way it makes any
sense. If I declare a standby a sync standby I better want it sync - not
"maybe sync". co
On 12/31/2010 08:15 PM, Simon Riggs wrote:
On Fri, 2010-12-31 at 14:40 +0200, Heikki Linnakangas wrote:
On 31.12.2010 13:48, Simon Riggs wrote:
I see significant real-world issues with configuring replication using
multiple named servers, as described in the link above:
All of these points o
On 12/31/10, Simon Riggs wrote:
> On Fri, 2010-12-31 at 09:27 +0100, Stefan Kaltenbrunner wrote:
>
>> Maybe it has been discussed but I still don't see way it makes any
>> sense. If I declare a standby a sync standby I better want it sync - not
>> "maybe sync". consider the case of a 1 master and
On lör, 2011-01-01 at 13:24 +0100, Jan Urbański wrote:
> On 01/01/11 01:00, Peter Eisentraut wrote:
> > On tor, 2010-12-23 at 14:41 +0100, Jan Urbański wrote:
> >> It does some architectural changes to PL/Python that make it easier to
> >> implement other features, like for instance a validator fun
On 01/01/11 01:00, Peter Eisentraut wrote:
> On tor, 2010-12-23 at 14:41 +0100, Jan Urbański wrote:
>> It does some architectural changes to PL/Python that make it easier to
>> implement other features, like for instance a validator function. The
>> full list of changes in the patch is:
>
> I woul
On Fri, 2010-12-31 at 22:18 +0100, Hannu Krosing wrote:
> On 31.12.2010 13:40, Heikki Linnakangas wrote:
> >
> > Sounds good.
> >
> > I still don't like the synchronous_standbys='' and
> > synchronous_replication=on combination, though. IMHO that still
> > amounts to letting the standby control t
On Thu, 2010-12-30 at 10:45 -0500, Tom Lane wrote:
> Comments?
Thanks for working on this. I love the reuse of tuple flags; I can't
help feeling that opens up doors, just not sure how yet...
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Train
2010/12/31 Simon Riggs
> Please call it something other than "snapshot". There's already about 3
> tools called something similar and a couple of different meanings of the
> term in the world of Postgres.
>
>
Renamed the entire github project as well:
https://github.com/gluefinance/fsnapshot
--
47 matches
Mail list logo
