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?
>
> Probably yes. To do that, ISTM that we should make ALTER DATABASE .. RENAME
> issue something like XLOG_DBASE_RENAME
On 04.10.2010 18:23, Tom Lane wrote:
I wrote:
Heikki Linnakangas writes:
Why is OUTER a type_func_name_keyword? The grammar doesn't require that,
it could as well be unreserved.
Hm, you sure? All the JOIN-related keywords used to need to be at least
that to avoid conflicts, IIRC.
Yes. OU
On Tue, 2010-10-05 at 13:29 +0900, Fujii Masao wrote:
> On Tue, Oct 5, 2010 at 3:42 AM, Tom Lane wrote:
> > OTOH, we don't have a similar interlock to prevent renaming users
> > who have active sessions, so maybe we are being overprotective here.
>
> Yep. What is worse is that we can drop users w
On Tue, Oct 5, 2010 at 5:11 PM, Simon Riggs wrote:
> On Tue, 2010-10-05 at 13:29 +0900, Fujii Masao wrote:
>> On Tue, Oct 5, 2010 at 3:42 AM, Tom Lane wrote:
>> > OTOH, we don't have a similar interlock to prevent renaming users
>> > who have active sessions, so maybe we are being overprotective
Hi,
Does anybody know if pg_filedump for PostgreSQL 9.0 already exists?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
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).
To explain replication I use a simplifi
On 5 October 2010 07:04, Hitoshi Harada wrote:
> 2010/10/5 Dean Rasheed :
>> On 4 October 2010 18:22, Robert Haas wrote:
>>> On Mon, Oct 4, 2010 at 2:58 AM, Dean Rasheed
>>> wrote:
That requires a new sort for each row. I generated this with a minor
tweak to Pavel's patch to just rest
On 04.10.2010 17:22, Fujii Masao wrote:
If we make all the transactions wait until specified standbys have
connected to the master, how do we take a base backup from the
master for those standbys? We seem to be unable to do that because
pg_start_backup also waits forever. Is this right?
Hmm, pg
(Oops, this didn't go to -HACKERS)
On 2010-10-04 2:46 PM +0300, Erik Rijkers wrote:
(HEAD from git://git.postgresql.org/git/postgresql.git)
The patch applies only with error.
If that error is ignored, the regression 'with' test failes.
If that is also ignored, it runs.
This patch conflicted w
2010/9/6 KaiGai Kohei :
> The attached patch tackles both of the above two points, and allows to
> control this deoptimization when CREATE SECURITY VIEW is used.
I'll send a review for the patch.
Contents & Purpose
==
The patch adds a new SECURITY option for VIEWs. Views defined w
(2010/10/01 11:23), Robert Haas wrote:
> On Sep 30, 2010, at 9:01 PM, KaiGai Kohei wrote:
>> (2010/10/01 3:09), Robert Haas wrote:
>>> 2010/9/29 KaiGai Kohei:
In addition, I want to give these entrypoints its name which
represents an appropriate purpose of the hook, rather than
a un
(2010/10/05 18:01), Itagaki Takahiro wrote:
> 2010/9/6 KaiGai Kohei:
>> The attached patch tackles both of the above two points, and allows to
>> control this deoptimization when CREATE SECURITY VIEW is used.
>
> I'll send a review for the patch.
>
Thanks for your reviewing.
> Contents& Purpose
On Tue, Oct 5, 2010 at 5:49 PM, Heikki Linnakangas
wrote:
> On 04.10.2010 17:22, Fujii Masao wrote:
>>
>> If we make all the transactions wait until specified standbys have
>> connected to the master, how do we take a base backup from the
>> master for those standbys? We seem to be unable to do th
On 05.10.2010 12:47, Fujii Masao wrote:
I have another question: when should the waiting transactions resume?
It's a moment the standby has connected to the master? It's a moment
the standby has caught up with the master? For no data loss, the
latter seems to be required. Right?
Yep.
The thir
At this page in documentation
http://www.postgresql.org/docs/9.0/static/gist-implementation.html and under
"picksplit" the loop that iterates through entryvec->vector[] starts from 1
(since FirstOffsetNumber equals 1).
for (i = FirstOffsetNumber; i <= maxoff; i = OffsetNumberNext(i))
I would expec
On Tue, 2010-10-05 at 18:47 +0900, Fujii Masao wrote:
> On Tue, Oct 5, 2010 at 5:49 PM, Heikki Linnakangas
> wrote:
> > On 04.10.2010 17:22, Fujii Masao wrote:
> >>
> >> If we make all the transactions wait until specified standbys have
> >> connected to the master, how do we take a base backup fr
On Fri, 2010-10-01 at 07:16 -0700, David Fetter wrote:
> On Fri, Oct 01, 2010 at 07:48:25PM +0900, Fujii Masao wrote:
> > I proposed to implement the "return-immediately" at first because it
> > doesn't require standby registration. But if many people think that
> > the "wait-forever" is the core r
On Fri, 2010-10-01 at 19:48 +0900, Fujii Masao wrote:
> My intention is to commit the core part of synchronous replication (which
> would
> be used for every use cases) at first. Then we can implement the
> feature for each
> use case.
I completely agree that we should commit the core part of sy
Josh Berkus writes:
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.
So I've been trying to come up with something manually and failed. I
blame the fever — without it maybe
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 for wrappers, not for
> > PostgreSQL core modules. ?Wrappers can
On mån, 2010-10-04 at 23:41 -0400, Robert Haas wrote:
> > Well, it's not really useful, but that's how it works "everywhere". On
> > Linux, fsync carries the stuff from the kernel's RAM to the disk
> > controller's RAM, and then it depends on some hdparm magic or something
> > what happens next.
>
2010/10/5 Dean Rasheed :
> On 5 October 2010 07:04, Hitoshi Harada wrote:
> Extrapolating from few quick timing tests, even in the best case, on
> my machine, it would take 7 days for the running median to use up
> 100MB, and 8 years for it to use 2GB. So setting the tuplesort's
> workMem to 2GB (
On Mon, 2010-10-04 at 14:25 -0500, David Christensen wrote:
> Is there any benefit to be had from having standby roles instead of
> individual names? For instance, you could integrate this into quorum
> commit to express 3 of 5 "reporting" standbys, 1 "berlin" standby and
> 1 "tokyo" standby from
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 replicated to (A || B) && (C
> >>> || D).
> >> Good point.
Asking for quorum_commit = 3 would cover that requirement.
Not ex
Hi
I lost a few hours trying to nut out an issue with the crash handler I'm
building as a contrib module. Having found out what was going on, I want
to post it here to help Google find it if others hit it later.
Compilation of the contrib module was failing during linkage with
bizarre errors
ses.
Thank you, I didn't notice that commit. In your last patch, the
snippet to add errhint() and ref/insert sgml is unnecessary since it
was for INSERT ... VALUES fix.
Regards,
--
Hitoshi Harada
toplevel-dml-cte.20101005.diff
Description: Binary data
--
Sent via pgsql-hackers mail
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?
>>
>> Probably yes. To do that, ISTM that we should make ALTER
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 replicated to (A || B) && (C
>> >>> || D).
>> >> Good point.
>
> Askin
* Marcelo Zabani (mzab...@gmail.com) wrote:
> However, with the huge popularity of ORM solutions and the complexity of
> db-specific datatypes (geometric types in other dbs probably work
> differently), we can't really expect ORM software to do all the mapping
> successfully (although projects such
On 5 October 2010 13:14, Hitoshi Harada wrote:
> 2010/10/5 Dean Rasheed :
>> On 5 October 2010 07:04, Hitoshi Harada wrote:
>> Extrapolating from few quick timing tests, even in the best case, on
>> my machine, it would take 7 days for the running median to use up
>> 100MB, and 8 years for it to
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
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 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 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 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, 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
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_
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
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
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
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
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 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
(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 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
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, 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
> >>>
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, 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
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, 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
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
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
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
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
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
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.)
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
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
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'
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
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 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 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
(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 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
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 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.
>>
(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 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
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
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
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
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
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 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
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, 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 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: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 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 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
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
* 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 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
--
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 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, 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
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
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
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
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, 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
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, 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
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 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
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 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
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.
1 - 100 of 130 matches
Mail list logo
