On 06.10.2010 01:14, Josh Berkus wrote:
Last I checked, our goal with synch standby was to increase availablity,
not decrease it.
No. Synchronous replication does not help with availability. It allows
you to achieve zero data loss, ie. if the master dies, you are
guaranteed that any transacti
On Tue, Oct 5, 2010 at 3:41 PM, Peter Eisentraut wrote:
> The reason why I think this is semi-important and not just cosmetic is
> that (for some reason that is not entirely clear to me) clients
> connecting to localhost end up appearing to the server as ::1 on a lot
> of machines I use which are
On Tue, 2010-10-05 at 18:52 -0700, Jeff Davis wrote:
> I'm not saying that an unavailable system is good, but I don't see how
> my particular complaint applies to the "wait for all servers to apply"
> case.
> The case I was worried about is:
> * 1 master and 2 standby
> * The rule is "wait for
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Between these issues and the speed concern, I don't think that we should
> change this.
+1.
Stephen
signature.asc
Description: Digital signature
KaiGai Kohei writes:
>> Note that we already default listen_addresses to 'localhost', so it
>> would only make sense to have pg_hba.conf behave the same by default.
>> To pick up on your argument, we effectively *do* make assumptions
>> about /etc/hosts now, and this change would remove them.
>>
On Tue, 2010-10-05 at 22:19 +0100, Simon Riggs wrote:
> > In other words, a lagging standby combined with a timeout mechanism is
> > essentially useless, because it will never catch up in time to be a part
> > of the quorum.
>
> Thanks for explaining what was meant.
>
> This issue is a serious pr
(2010/10/06 4:41), Peter Eisentraut wrote:
> On tis, 2010-10-05 at 12:35 +0900, KaiGai Kohei wrote:
>> It seems to me this patch has been left for a long time, although it tries
>> to provide a useful functionality.
>>
>> In the previous discussion, several issues were pointed out.
>>
>> * Case han
(2010/10/06 4:15), Heikki Linnakangas wrote:
On 05.10.2010 21:48, Tom Lane wrote:
Heikki Linnakangas writes:
On 05.10.2010 21:08, Greg Stark wrote:
If the users that have select access on the view don't have DDL access
doesn't that make them leak-proof for those users?
No. You can use built
(2010/10/06 4:06), Robert Haas wrote:
> On Tue, Oct 5, 2010 at 2:48 PM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> On 05.10.2010 21:08, Greg Stark wrote:
If the users that have select access on the view don't have DDL access
doesn't that make them leak-proof for those users?
>>
>
> Heikki had argued that a use case existed where Y out of Y (i.e. all)
> nodes must acknowledge before we commit. That was the use case that
> required us to have standby registration. It was optional in all other
> cases.
Yeah, Y of Y is just a special case of X of Y. And, IMHO, rather
pointle
Big thanks to everyone that was involved in the git conversion.
The commit instructions were flawless and the multiple workdirs option
works well for our setup.
git reset helped me out of a minor issue where I'd set the case of the
email address incorrectly. So git has already saved me once.
Th
Hi!
I'm on the committee for MySQL Conf this year, and the committee is
specifically seeking talks about PostgreSQL. The idea is to broaden
the scope of the conference to include a lot of different open source
database technology, including a bunch more about Postgres. The
organizing committee is
On Tue, 2010-10-05 at 15:14 -0700, Josh Berkus wrote:
> > I can only presume that Josh wants to prevent us from adopting a
> > design that allows sync against multiple standbys.
>
> Quorum commit == "X servers need to ack for commit", where X > 1.
> Usually done as "X out of Y servers must ack",
On Tue, Oct 5, 2010 at 5:05 PM, Oleg Bartunov wrote:
> Are you sure postgres doesn't have limitation at all ? There are a lot ot
> them. Of course, there are limitation and limitation and we should avoid
> limitations, which will require incompatible changes in future in user's
> code, or which pr
Simon, Robert,
> The points appear to be directed at "quorum commit", which is a name
> I've used. But most of the points apply more to Fujii's patch than my
> own.
Per previous discussion, I'm trying to get at what reasonable behavior
is, rather than targeting one patch or the other.
> I can
On Tue, 2010-10-05 at 17:21 -0400, Robert Haas wrote:
> On Tue, Oct 5, 2010 at 5:10 PM, Simon Riggs wrote:
> > The points appear to be directed at "quorum commit", which is a name
> > I've used. But most of the points apply more to Fujii's patch than my
> > own. I can only presume that Josh wants
On Tue, 2010-10-05 at 13:43 -0700, Josh Berkus wrote:
> Again, I'm just saying that merely doing single-server synch rep,
> *and*
> making HS/SR easier to admin in general, is going to be a big task for
> 9.1. Quorum Commit needs to be considered a separate feature, and one
> which is dispensible
On Tue, Oct 5, 2010 at 5:10 PM, Simon Riggs wrote:
> The points appear to be directed at "quorum commit", which is a name
> I've used. But most of the points apply more to Fujii's patch than my
> own. I can only presume that Josh wants to prevent us from adopting a
> design that allows sync agains
On Tue, 2010-10-05 at 13:45 -0700, Jeff Davis wrote:
> On Tue, 2010-10-05 at 12:11 -0700, Josh Berkus wrote:
> > B. Eventual Inconsistency
> > -
> > If we have a quorum commit, it's possible for any individual standby to
> > be indefinitely ahead of any standby which is not
On Tue, 2010-10-05 at 22:32 +0300, Heikki Linnakangas wrote:
> On 05.10.2010 22:11, Josh Berkus wrote:
> > There's been a lot of discussion on synch rep lately which involves
> > quorum commit. I need to raise some major design issues with quorum
> > commit which I don't think that people have rea
Robert,
Are you sure postgres doesn't have limitation at all ? There are a lot ot them.
Of course, there are limitation and limitation and we should avoid limitations,
which will require incompatible changes in future in user's code, or which
prevent future improvements (getting rid limitation
bricklen wrote:
> Kevin Grittner wrote:
>> Right now this is managed by query classes in our Java
>> applications, but as we're moving to a variety of new and
>> different technologies it's getting harder for the DBAs to ensure
>> that nothing is leaking to inappropriate recipients. :-( I
>> th
bricklen writes:
> Does Veil cover some of those needs?
> http://veil.projects.postgresql.org/curdocs/index.html
This entire discussion arose from the desire to plug the holes in Veil...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
On Tue, Oct 5, 2010 at 4:25 PM, Kevin Grittner
wrote:
>> The stronger form is that they shouldn't even be able to tell that
>> hidden rows exist, which is something your view doesn't try to do;
>> but there are at least some applications where that would be
>> desirable.
>
> I can understand that,
On Tue, 2010-10-05 at 12:11 -0700, Josh Berkus wrote:
> B. Eventual Inconsistency
> -
> If we have a quorum commit, it's possible for any individual standby to
> be indefinitely ahead of any standby which is not needed by the quorum.
> This means that:
>
> -- There is no c
Heikki,
> The master can not roll back or cancel the transaction. That's
> completely infeasible, the WAL record has been written to local disk
> already. The best it can do is halt and wait for enough standbys to
> appear to fulfill the quorum. The client will hang waiting for the
> COMMIT to fin
On Tue, Oct 5, 2010 at 1:25 PM, Kevin Grittner
wrote:
> Right now this is managed by query classes in our Java applications,
> but as we're moving to a variety of new and different technologies
> it's getting harder for the DBAs to ensure that nothing is leaking
> to inappropriate recipients. :-(
--On 30. September 2010 07:38:18 +0100 Dean Rasheed
wrote:
This version doesn't apply clean anymore due to some rejects in
plainmain.c. Corrected version attached.
Ah yes, those pesky bits have been rotting while I wasn't looking.
Thanks for fixing them!
Basic summary of this patch:
*
Tom Lane wrote:
> Well, the approach you suggested of putting a security wrapper
> around the output column might be bulletproof against that; I'm
> not entirely sure, but I don't see a hole in it at the moment.
> The trouble with it is that it's pretty bad from a performance
> point of view, a
"Kevin Grittner" writes:
> Tom Lane wrote:
>> I don't believe we can solve Kevin's version of the problem, which
>> is whether a stalker can verify the address of a victim that he's
>> not supposed to be able to see.
> I'm surprised; I thought that we were already there.
Well, the approach you
On tis, 2010-10-05 at 12:35 +0900, KaiGai Kohei wrote:
> It seems to me this patch has been left for a long time, although it tries
> to provide a useful functionality.
>
> In the previous discussion, several issues were pointed out.
>
> * Case handling when an IP-address has multiple hostnames.
On 05.10.2010 22:11, Josh Berkus wrote:
There's been a lot of discussion on synch rep lately which involves
quorum commit. I need to raise some major design issues with quorum
commit which I don't think that people have really considered, and may
be sufficient to prevent it from being included i
Tom Lane wrote:
> I don't believe we can solve Kevin's version of the problem, which
> is whether a stalker can verify the address of a victim that he's
> not supposed to be able to see.
I'm surprised; I thought that we were already there. If someone has
SELECT rights on that view, how would
On 05.10.2010 21:48, Tom Lane wrote:
Heikki Linnakangas writes:
On 05.10.2010 21:08, Greg Stark wrote:
If the users that have select access on the view don't have DDL access
doesn't that make them leak-proof for those users?
No. You can use built-in functions for leaking data as well.
The
All,
There's been a lot of discussion on synch rep lately which involves
quorum commit. I need to raise some major design issues with quorum
commit which I don't think that people have really considered, and may
be sufficient to prevent it from being included in 9.1.
A. Permanent Synchronization
On Tue, Oct 5, 2010 at 2:30 PM, Simon Riggs wrote:
> On Tue, 2010-10-05 at 10:41 -0400, Robert Haas wrote:
>> Much of the engineering we are doing centers around use cases that are
>> considerably more complex than what most people will do in real life.
>
> Why are we doing it then?
Because some
On Tue, Oct 5, 2010 at 2:48 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 05.10.2010 21:08, Greg Stark wrote:
>>> If the users that have select access on the view don't have DDL access
>>> doesn't that make them leak-proof for those users?
>
>> No. You can use built-in functions for leak
On Tue, 2010-10-05 at 14:49 -0400, Robert Haas wrote:
> On Tue, Oct 5, 2010 at 2:08 PM, Greg Stark wrote:
> > Though I find it unlikely the sales people would have direct access to
> > run arbitrary SQL -- let alone create custom functions.
>
> I have definitely seen shops where virtually everyon
Robert Haas writes:
> I'm somewhat afraid that a remote-PG adapter will turn into a can of
> worms. If we give up on remote statistics, does that mean we're also
> giving up on index use on the remote side? I fear that we'll end up
> crafting partial solutions that will only end up getting throw
On Tue, Oct 5, 2010 at 2:08 PM, Greg Stark wrote:
> Though I find it unlikely the sales people would have direct access to
> run arbitrary SQL -- let alone create custom functions.
I have definitely seen shops where virtually everyone has SQL-level
access to the database. Several of them. Most
Heikki Linnakangas writes:
> On 05.10.2010 21:08, Greg Stark wrote:
>> If the users that have select access on the view don't have DDL access
>> doesn't that make them leak-proof for those users?
> No. You can use built-in functions for leaking data as well.
There's a difference between "can be
Robert Haas writes:
> ... I agree it's hopeless to
> prevent all side-channel leaks, but I'd describe the goal like this:
> Prevent access to the actual tuple contents of the hidden rows.
> Failing to solve this problem at the database level doesn't remove the
> business requirement. I've solve
On Tue, Oct 5, 2010 at 12:49 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Oct 5, 2010 at 11:06 AM, Tom Lane wrote:
>>> IMO this is a *clear* case of premature optimization being the root of
>>> all evil. We should get it working first and then see what needs to be
>>> optimized by measu
On Tue, 2010-10-05 at 11:30 -0400, Steve Singer wrote:
> Will read-only queries running on a slave hold up transactions from
> being applied on that slave? I suspect that for most people running
> with 'apply' they would want the answer to be 'no'. Are we going to
> revisit the standby query
On Tue, 2010-10-05 at 10:41 -0400, Robert Haas wrote:
> Much of the engineering we are doing centers around use cases that are
> considerably more complex than what most people will do in real life.
Why are we doing it then?
What I have proposed behaves identically to Oracle Maximum Availability
On 05.10.2010 21:08, Greg Stark wrote:
If the users that have select access on the view don't have DDL access
doesn't that make them leak-proof for those users?
No. You can use built-in functions for leaking data as well.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
* Greg Stark (gsst...@mit.edu) wrote:
> Though I find it unlikely the sales people would have direct access to
> run arbitrary SQL -- let alone create custom functions.
I'm not really sure why..? Perhaps not quite the same, but I've got
quite a few users who have direct SQL access (though they us
On Tue, Oct 5, 2010 at 11:01 AM, Robert Haas wrote:
> Well, the only thing I've ever wanted to do this for was to allow
> sales reps to see their own customers but not the customers of other
> sales reps (because if they could pull our complete customer list,
> then once they left and went to work
On Tue, Oct 5, 2010 at 1:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Oct 5, 2010 at 12:27 PM, Tom Lane wrote:
>>> That doesn't make permissions on them useless, so you're attacking a
>>> straw man.
>
>> Really? I'm confused. What is the use case for the status quo?
>
> Access to ta
Robert Haas wrote:
> What is the use case for the status quo?
Much simplified:
create table party
(
countyno smallint not null,
caseno varchar(14) not null,
partyno smallint not null,
name text not null,
address text,
isaddrsealed boolean not null,
primary key (countyno, caseno,
On Tue, Oct 5, 2010 at 12:40 PM, Simon Riggs wrote:
>> Well, you only need to have the file at all on nodes you want to fail
>> over to. And aren't you going to end up rejiggering the config when
>> you fail over anyway, based on what happened? I mean, suppose you
>> have three servers and you r
Robert Haas writes:
> On Tue, Oct 5, 2010 at 12:27 PM, Tom Lane wrote:
>> That doesn't make permissions on them useless, so you're attacking a
>> straw man.
> Really? I'm confused. What is the use case for the status quo?
Access to tables that you have no direct privileges on, mainly.
(This i
On Tue, Oct 5, 2010 at 12:27 PM, Tom Lane wrote:
>> Option #1: Remove all mention from the documentation of using views
>> for security purposes. Don't allow views to have explicit permissions
>> attached to them; they are merely shorthand for a SELECT, for which
>> you either do or do not have p
Robert Haas writes:
> On Tue, Oct 5, 2010 at 11:06 AM, Tom Lane wrote:
>> IMO this is a *clear* case of premature optimization being the root of
>> all evil. We should get it working first and then see what needs to be
>> optimized by measuring, rather than guessing in a vacuum.
> I have no pro
On Tue, 2010-10-05 at 11:46 -0400, Robert Haas wrote:
> On Tue, Oct 5, 2010 at 10:46 AM, Simon Riggs wrote:
> > On Tue, 2010-10-05 at 10:41 -0400, Robert Haas wrote:
> >> >>
> >> >> When you have one server functioning at each site you'll block until
> >> >> you get a third machine back, rather th
Excerpts from Alvaro Herrera's message of mar oct 05 12:15:45 -0400 2010:
> Excerpts from Devrim GÜNDÜZ's message of mar oct 05 10:16:45 -0400 2010:
> > On Tue, 2010-10-05 at 10:12 -0400, Tom Lane wrote:
> > > > Does anybody know if pg_filedump for PostgreSQL 9.0 already exists?
> > >
> > > It's o
On Tue, 2010-10-05 at 12:27 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Oct 5, 2010 at 10:56 AM, Tom Lane wrote:
> >> Personally I think this is a dead end that we shouldn't be wasting
> >> any more time on.
>
> > But you haven't proposed a reasonable alternative.
>
> Tom: "This pr
Robert Haas writes:
> On Tue, Oct 5, 2010 at 10:56 AM, Tom Lane wrote:
>> Personally I think this is a dead end that we shouldn't be wasting
>> any more time on.
> But you haven't proposed a reasonable alternative.
Tom: "This problem is insoluble."
Robert: "You can't claim that without offering
Andrew Dunstan writes:
> I propose that we add the following test for this case:
> AC_CHECK_HEADER(Python.h, [], [AC_MSG_ERROR([header file
> is required for Python])])
You'd need to pay attention to python_includespec, but otherwise seems
reasonable.
regards, t
Excerpts from Devrim GÜNDÜZ's message of mar oct 05 10:16:45 -0400 2010:
> On Tue, 2010-10-05 at 10:12 -0400, Tom Lane wrote:
> > > Does anybody know if pg_filedump for PostgreSQL 9.0 already exists?
> >
> > It's on my todo list to look at that, but right now I would think
> > that it doesn't need
On 10/05/2010 11:37 AM, Peter Eisentraut wrote:
On tis, 2010-10-05 at 11:13 -0400, Andrew Dunstan wrote:
Specifically, a) when python was installed but python-devel was not,
configure passed by the compile for python failed quite miserably, and
Yeah. Same is true if libperl-dev or similar is
(2010/10/06 0:33), KaiGai Kohei wrote:
> (2010/10/05 23:56), Tom Lane wrote:
>> Robert Haas writes:
>>> Checking the functions of the operators is the right thing to do, but
>>> assuming that internal = safe does not work. For example, pushing
>>> down arithmetic operators allows you to probe fo
On Tue, Oct 5, 2010 at 10:46 AM, Simon Riggs wrote:
> On Tue, 2010-10-05 at 10:41 -0400, Robert Haas wrote:
>> >>
>> >> When you have one server functioning at each site you'll block until
>> >> you get a third machine back, rather than replicating to both sites
>> >> and remaining functional.
>>
On Tue, Oct 5, 2010 at 11:06 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Oct 5, 2010 at 10:41 AM, Tom Lane wrote:
>>> (I'd also say that your performance estimate is miles in advance of any
>>> facts; but even if it's true, the caching ought to be inside the FDW,
>>> because we have no
On tis, 2010-10-05 at 11:13 -0400, Andrew Dunstan wrote:
> > > Specifically, a) when python was installed but python-devel was not,
> > > configure passed by the compile for python failed quite miserably, and
> > Yeah. Same is true if libperl-dev or similar is not installed.
>
> No, actually co
(2010/10/05 23:56), Tom Lane wrote:
> Robert Haas writes:
>> Checking the functions of the operators is the right thing to do, but
>> assuming that internal = safe does not work. For example, pushing
>> down arithmetic operators allows you to probe for any given value in a
>> hidden row by testin
On Tue, 2010-10-05 at 09:56 -0500, Kevin Grittner wrote:
> Simon Riggs wrote:
>
> > Is it a common use case that people have more than 3 separate
> > servers for one application, which is where the difference shows
> > itself.
>
> I don't know how common it is, but we replicate circuit court d
On 10-10-05 04:32 AM, Simon Riggs wrote:
This is an attempt to compile everybody's stated viewpoints and come to
an understanding about where we are and where we want to go. The idea
from here is that we discuss what we are trying to achieve
(requirements) and then later come back to how (design
On 2010-10-05 3:37 PM +0300, Hitoshi Harada wrote:
2010/10/5 Marko Tiikkaja:
This patch conflicted with Tom's WITH .. INSERT change. I tweaked the
patch just a bit and it now passes all regression tests so I can review
it. New version attached for documentation purposes.
Thank you, I didn't
On Tue, Oct 5, 2010 at 10:56 AM, Tom Lane wrote:
> Personally I think this is a dead end that we shouldn't be wasting
> any more time on.
But you haven't proposed a reasonable alternative.
As far as I can see, there are only two ways to go here.
Option #1: Remove all mention from the documentat
Heikki Linnakangas writes:
> On 05.10.2010 17:56, Robert Haas wrote:
>> I can't imagine how an FDW could possibly be expected to perform well
>> without some persistent local data storage.
> It doesn't seem completely out of the question to me.
One other point that could be made here is that it'
OK, it's pretty much ready for proper testing now. If a few people are
happy with the results and think it's a good idea I'll chuck it in the
commitfest app.
As built, the crash dump handler works with a stock PostgreSQL 9.0
(release build) as shipped in EDB's installer. Just drop crashdump.dl
On 10/02/2010 01:35 PM, Peter Eisentraut wrote:
On lör, 2010-10-02 at 13:01 -0400, Andrew Dunstan wrote:
Specifically, a) when python was installed but python-devel was not,
configure passed by the compile for python failed quite miserably, and
Yeah. Same is true if libperl-dev or similar is
On 05.10.2010 17:56, Robert Haas wrote:
On Tue, Oct 5, 2010 at 10:41 AM, Tom Lane wrote:
(I'd also say that your performance estimate is miles in advance of any
facts; but even if it's true, the caching ought to be inside the FDW,
because we have no clear idea of what it will need to cache.)
Robert Haas writes:
> On Tue, Oct 5, 2010 at 10:41 AM, Tom Lane wrote:
>> (I'd also say that your performance estimate is miles in advance of any
>> facts; but even if it's true, the caching ought to be inside the FDW,
>> because we have no clear idea of what it will need to cache.)
> I can't im
Another check: does specifying replication by server in such detail mean
we can't specify robustness at the transaction level? If we gave up that
feature, it would be a greatloss for performance tuning.
It's orthagonal. The kinds of configurations we're talking about simply
define what it wi
Simon Riggs wrote:
> Is it a common use case that people have more than 3 separate
> servers for one application, which is where the difference shows
> itself.
I don't know how common it is, but we replicate circuit court data
to two machines each at two sites. That way a disaster which took
Robert Haas writes:
> Checking the functions of the operators is the right thing to do, but
> assuming that internal = safe does not work. For example, pushing
> down arithmetic operators allows you to probe for any given value in a
> hidden row by testing whether 1 / (x - constant) throws a divi
On Tue, Oct 5, 2010 at 10:41 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Oct 5, 2010 at 10:25 AM, Tom Lane wrote:
>>> This whole discussion seems to me to be about trying to do things outside
>>> the FDW that should properly be left inside the FDW. Who's to say that
>>> the remote side
On Tue, 2010-10-05 at 10:41 -0400, Robert Haas wrote:
> >>
> >> When you have one server functioning at each site you'll block until
> >> you get a third machine back, rather than replicating to both sites
> >> and remaining functional.
> >
> > And that is so important a consideration that you woul
Robert Haas writes:
> On Tue, Oct 5, 2010 at 10:25 AM, Tom Lane wrote:
>> This whole discussion seems to me to be about trying to do things outside
>> the FDW that should properly be left inside the FDW. Who's to say that
>> the remote side even *has* statistics of the sort that PG creates?
>>
On Tue, Oct 5, 2010 at 10:33 AM, Simon Riggs wrote:
> On Tue, 2010-10-05 at 09:07 -0500, Kevin Grittner wrote:
>> Simon Riggs wrote:
>> > Robert Haas wrote:
>> >> Simon Riggs wrote:
>> >>> Josh Berkus wrote:
>> >>> Quorum commit, even with configurable vote weights, can't
>> >>> handle a
On Tue, Oct 5, 2010 at 10:27 AM, KaiGai Kohei wrote:
> (2010/10/05 23:16), Robert Haas wrote:
>>
>> 2010/10/5 KaiGai Kohei:
The term "built-in functions" means functions written in INTERNAL
language
here. But we also have SQL functions by default. Some of them are just a
w
On Tue, 2010-10-05 at 09:07 -0500, Kevin Grittner wrote:
> Simon Riggs wrote:
> > Robert Haas wrote:
> >> Simon Riggs wrote:
> >>> Josh Berkus wrote:
> >>> Quorum commit, even with configurable vote weights, can't
> >>> handle a requirement that a particular commit be replicated
> >>>
Craig Ringer writes:
> The cause turns out to be the automatic .DEF file generation. It skips
> DEF file generation if a DEF file already exists, even if the
> object/sources are newer than the existing DEF file.
Um, so can't we fix that? It seems like a rather basic expectation of a
build pro
On Tue, Oct 5, 2010 at 8:10 AM, Shigeru HANADA
wrote:
> On Mon, 4 Oct 2010 19:31:52 -0400
> Robert Haas wrote:
>> On Thu, Sep 30, 2010 at 3:48 AM, Shigeru HANADA
>> wrote:
>> > How about having cost hints in generic option of the foreign table or
>> > its columns? ?Generic options are storage fo
(2010/10/05 23:16), Robert Haas wrote:
2010/10/5 KaiGai Kohei:
The term "built-in functions" means functions written in INTERNAL language
here. But we also have SQL functions by default. Some of them are just a
wrapper to internal functions. I'm not sure the checking of INTERNAL language
is the
On Tue, Oct 5, 2010 at 10:25 AM, Tom Lane wrote:
> Shigeru HANADA writes:
>> Can we treat statistics of a foreign table separately?
>
>> 1. Same as local tables (maybe required)
>> (pg_statistic.*, pg_class.reltuples/relpages)
>
> This whole discussion seems to me to be about trying to do thin
Shigeru HANADA writes:
> Can we treat statistics of a foreign table separately?
> 1. Same as local tables (maybe required)
>(pg_statistic.*, pg_class.reltuples/relpages)
This whole discussion seems to me to be about trying to do things outside
the FDW that should properly be left inside the
On 10/05/2010 04:07 PM, Kevin Grittner wrote:
> When you have one server functioning at each site you'll block until
> you get a third machine back, rather than replicating to both sites
> and remaining functional.
That's not a very likely failure scenario, but yes.
What if the admin wants to add
On Tue, 2010-10-05 at 10:12 -0400, Tom Lane wrote:
> > Does anybody know if pg_filedump for PostgreSQL 9.0 already exists?
>
> It's on my todo list to look at that, but right now I would think
> that it doesn't need any changes since 8.4.
Is there a test suite or so ? I can give it a try while bu
2010/10/5 KaiGai Kohei :
>> The term "built-in functions" means functions written in INTERNAL language
>> here. But we also have SQL functions by default. Some of them are just a
>> wrapper to internal functions. I'm not sure the checking of INTERNAL language
>> is the best way for the purpose. Did
Tatsuo Ishii writes:
> Does anybody know if pg_filedump for PostgreSQL 9.0 already exists?
It's on my todo list to look at that, but right now I would think
that it doesn't need any changes since 8.4.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacke
Simon Riggs wrote:
> Robert Haas wrote:
>> Simon Riggs wrote:
>>> Josh Berkus wrote:
>>> Quorum commit, even with configurable vote weights, can't
>>> handle a requirement that a particular commit be replicated
>>> to (A || B) && (C || D).
>> Good point.
>>>
>>> Asking for quorum_
On Tue, Oct 5, 2010 at 8:25 PM, Simon Riggs wrote:
> Presumably we will have an option to *not* wait forever? So we would be
> able to set the option prior to running the base backup? So there isn't
> any need to do this rollback trick suggested.
At the initial setup of the standby, we can easily
On Tue, 2010-10-05 at 08:57 -0400, Robert Haas wrote:
> On Tue, Oct 5, 2010 at 8:34 AM, Simon Riggs wrote:
> > On Mon, 2010-10-04 at 12:45 -0700, Josh Berkus wrote:
> >> >>> Quorum commit, even with configurable vote weights, can't handle a
> >> >>> requirement that a particular commit be replicat
On Tue, 2010-10-05 at 08:56 -0400, Robert Haas wrote:
> On Mon, Oct 4, 2010 at 12:42 PM, Simon Riggs wrote:
> > On Mon, 2010-10-04 at 20:38 +0900, Fujii Masao wrote:
> >> >
> >> > That looks contrary to the documented behavior. Shouldn't i get a forced
> >> > disconnect on this connection instead?
On 4/10/2010 8:27 PM, Heikki Linnakangas wrote:
On 04.10.2010 15:21, Craig Ringer wrote:
Thinking about it, a possibly better alternative is to ship it as a
library as is done with the pl/pgsql debugger, and use (I think)
shared_preload_libraries to load it when desired. That way there's zero
co
On Mon, Oct 4, 2010 at 11:48 PM, Fujii Masao wrote:
> How can we take a base backup for that synchronous standby? You mean
> that we should disable the wait-forever option, start the master, take
> a base backup, shut down the master, enable the wait-forever option,
> start the master, and start
On Tue, Oct 5, 2010 at 12:11 AM, Tom Lane wrote:
> Robert Haas writes:
>> Yeah, but isn't the current behavior awfully flaky?
>
> The reason the particular case acts so oddly is there's no such thing as
> half a point: you can't have a point with one null and one non-null
> component. So there's
1 - 100 of 130 matches
Mail list logo
