u Hanada
20101227-psql_dE_doc.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> The simple truth is
>
> 1) sampling-based estimators are a dead-end
While I don't want to discourage you from working on steam-based
estimators ... I'd love to see you implement a proof-of-concept for
PostgreSQL, and test it ... the above is a non-argument. It requires us
to accept that sampl
On Tue, Dec 28, 2010 at 03:49:16AM +, Peter Geoghegan wrote:
> On 28 December 2010 01:09, Kevin Grittner wrote:
> > Personally, I think it's worth fixing. This sort of disjunction
> > between code and documentation can cause confusing for someone
> > trying to get started on hacking. It is a
On 12/27/10 7:35 PM, Josh Berkus wrote:
> On 12/27/10 1:45 PM, Peter Eisentraut wrote:
>> I'm unable to produce any really "exciting" release notes for alpha3. I
>> have produced a draft here:
>> http://wiki.postgresql.org/wiki/Alpha_release_notes_draft Please edit
>> the bullet points if you hav
On 28 December 2010 01:09, Kevin Grittner wrote:
> Personally, I think it's worth fixing. This sort of disjunction
> between code and documentation can cause confusing for someone
> trying to get started on hacking. It is an exception to the
> otherwise excellent documentation of both the produc
On 12/27/10 1:45 PM, Peter Eisentraut wrote:
> I'm unable to produce any really "exciting" release notes for alpha3. I
> have produced a draft here:
> http://wiki.postgresql.org/wiki/Alpha_release_notes_draft Please edit
> the bullet points if you have some idea.
I'll see what I can do.
--
, eventually commit
something based on the version attached here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
fdw-syntax-20101227.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to consider libpqtypes for contrib (which we don't have time for atm).
... or as a libpq sibling :)
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
On Mon, Dec 27, 2010 at 09:51:01PM -0500, Robert Haas wrote:
> On Mon, Dec 27, 2010 at 9:28 PM, David Fetter wrote:
> > On Tue, Dec 28, 2010 at 12:19:47AM +, Peter Geoghegan wrote:
> >> It's worth noting that officially (i.e. in the docs), we don't even
> >> call CTEs CTEs at any point. We cal
On Mon, Dec 27, 2010 at 9:28 PM, David Fetter wrote:
> On Tue, Dec 28, 2010 at 12:19:47AM +, Peter Geoghegan wrote:
>> It's worth noting that officially (i.e. in the docs), we don't even
>> call CTEs CTEs at any point. We call them WITH queries. I think that
>> that's a mistake because we call
On Tue, Dec 28, 2010 at 12:19:47AM +, Peter Geoghegan wrote:
> It's worth noting that officially (i.e. in the docs), we don't even
> call CTEs CTEs at any point. We call them WITH queries. I think that
> that's a mistake because we call them CTEs everywhere else.
Agreed.
> Is there interest i
On Mon, Dec 27, 2010 at 4:21 PM, Bruce Momjian wrote:
> Dmitriy Igrishin wrote:
>> IMO, it would be better to implement some utility functions to
>> make it easy to construct arrays dynamically for PQexecParams
>> and PQexecPrepared. This seems to me more universal solution
>> and it is useful for
Peter Geoghegan wrote:
> It's worth noting that officially (i.e. in the docs), we don't even
> call CTEs CTEs at any point. We call them WITH queries. I think
> that that's a mistake because we call them CTEs everywhere else.
>
> Is there interest in correcting this, by putting "CTEs" or "Commo
Dne 28.12.2010 00:04, Kevin Grittner napsal(a):
> Tom Lane wrote:
>
>> Well, first, those scans occur only once every few hundred million
>> transactions, which is not likely a suitable timescale for
>> maintaining statistics.
>
> I was assuming that the pass of the entire table was priming fo
It's worth noting that officially (i.e. in the docs), we don't even
call CTEs CTEs at any point. We call them WITH queries. I think that
that's a mistake because we call them CTEs everywhere else.
Is there interest in correcting this, by putting "CTEs" or "Common
table expressions" in parenthesis
Dne 27.12.2010 22:46, Robert Haas napsal(a):
> 2010/12/27 Tomas Vondra :
>> But even though these disadvantages, there really is no other
>> way to enhance the estimates. I don't think this should be a
>> default behavior - just as in case of cross-column stats this should
>> be optional wh
Tom Lane wrote:
> Well, first, those scans occur only once every few hundred million
> transactions, which is not likely a suitable timescale for
> maintaining statistics.
I was assuming that the pass of the entire table was priming for the
incremental updates described at the start of this th
"Kevin Grittner" writes:
> Robert Haas wrote:
>> With respect to (b), I think I'd need to see a much more detailed
>> design for how you intend to make this work. Off the top of my
>> head there seems to be some pretty serious feasibility problems.
> I had one random thought on that -- it seem
Robert Haas wrote:
> With respect to (b), I think I'd need to see a much more detailed
> design for how you intend to make this work. Off the top of my
> head there seems to be some pretty serious feasibility problems.
I had one random thought on that -- it seemed like a large concern
was tha
I wrote:
> Dan and I have now implemented most of the mitigation techniques
> ..., and I now feel confident I have a good grasp of how long each
> type of data is useful. (By useful I mean that to maintain data
> integrity without them it will be necessary to roll back some
> transactions which
On Mon, Dec 27, 2010 at 11:47:14PM +0200, Peter Eisentraut wrote:
> On ons, 2010-12-22 at 20:44 +0200, Marko Tiikkaja wrote:
> > On 2010-12-22 8:28 PM, Peter Eisentraut wrote:
> > > As a side note, I think the term "writable CTE" is a misnomer. The CTE
> > > is not writable. The CTE is the result
On Mon, Dec 27, 2010 at 4:58 PM, Azat Khuzhin wrote:
> Hi all!
> Yesterday-today I try to install postgresql, and I have noticed bug in
> configure script
> If path which you try to install postgresql from, contains "&" symbol, then
> configure doesn`t work correctly (it doesn`t make make file)
>
Hi all!
Yesterday-today I try to install postgresql, and I have noticed bug in
configure script
If path which you try to install postgresql from, contains "&" symbol, then
configure doesn`t work correctly (it doesn`t make make file)
It writes some thing like this:
config.status: creating GNUmakef
On Mon, Dec 27, 2010 at 22:42, Tom Lane wrote:
> Magnus Hagander writes:
>> Updated patch, still pending docs, but otherwise updated: allow
>> start/stop backup, make sure only superuser can turn on/off the flag,
>> include in system views, show properly in psql.
>
> I'd suggest avoiding creating
On Mon, Dec 27, 2010 at 4:45 PM, Peter Eisentraut wrote:
> I'm unable to produce any really "exciting" release notes for alpha3. I
> have produced a draft here:
> http://wiki.postgresql.org/wiki/Alpha_release_notes_draft Please edit
> the bullet points if you have some idea.
Yeesh. That was
On ons, 2010-12-22 at 20:44 +0200, Marko Tiikkaja wrote:
> On 2010-12-22 8:28 PM, Peter Eisentraut wrote:
> > As a side note, I think the term "writable CTE" is a misnomer. The CTE
> > is not writable. The CTE is the result of a write operation.
> >
> > A writable CTE would look like this:
> >
>
2010/12/27 Tomas Vondra :
> But even though these disadvantages, there really is no other
> way to enhance the estimates. I don't think this should be a
> default behavior - just as in case of cross-column stats this should
> be optional when the current estimator does not work well.
This
I'm unable to produce any really "exciting" release notes for alpha3. I
have produced a draft here:
http://wiki.postgresql.org/wiki/Alpha_release_notes_draft Please edit
the bullet points if you have some idea.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
Magnus Hagander writes:
> Updated patch, still pending docs, but otherwise updated: allow
> start/stop backup, make sure only superuser can turn on/off the flag,
> include in system views, show properly in psql.
I'd suggest avoiding creating the static cache variable
AuthenticatedUserIsReplicatio
"Kevin Grittner" writes:
> *** ** wrote:
>> 2010/12/27 Kevin Grittner
>>> Did you configure --with_ossp_uuid? Did you get any errors or
>>> warnings when you ran ./configure?
>> yes. I configure with this flag.
>> Configure ends successfull.
> Oh, by the way, my copy/paste of the swi
Dmitriy Igrishin wrote:
> IMO, it would be better to implement some utility functions to
> make it easy to construct arrays dynamically for PQexecParams
> and PQexecPrepared. This seems to me more universal solution
> and it is useful for both -- high level libpq-libraries authors and for
> those w
*** ** wrote:
> 2010/12/27 Kevin Grittner
>> Did you configure --with_ossp_uuid? Did you get any errors or
>> warnings when you ran ./configure?
> yes. I configure with this flag.
> Configure ends successfull.
Odd. I don't have the required packages installed (which on my
system wo
On Mon, Dec 27, 2010 at 16:40, Magnus Hagander wrote:
> On Mon, Dec 27, 2010 at 16:33, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Mon, Dec 27, 2010 at 10:53, Magnus Hagander wrote:
We could quite easily make a replication role *never* be able to
connect to a non-walsender backe
Bruce Momjian writes:
> While I am working on pg_ctl, I saw this TODO item:
> Have the postmaster write a random number to a file on startup that
> pg_ctl checks against the contents of a pg_ping response on its initial
> connection (without login)
> This will
Yes.
I install ossp-uuid package.
[/usr/src/postgresql-9.0.2] $ ls /usr/lib | grep uuid
drwxr-xr-x 3 root root4,0K Дек 20 22:39 ossp_uuid
-rw-r--r-- 1 root root 17K Авг 2 18:27 libuuid.a
lrwxrwxrwx 1 root root 22 Дек 23 21:35 libuuid.so ->
/usr/lib/libuuid.so.16
lrwxrwxr
yes. I configure with this flag.
Configure ends successfull.
It print a lot to output so where I have to see for warning messages?
2010/12/27 Kevin Grittner
> *** ** wrote:
>
> > Can you tell me what I doing wrong?
>
> Did you configure --with_ossp_uuid? Did you get any errors or
> war
=?KOI8-R?B?7snLz8zByiDp1snLz9c=?= writes:
> Hello?
> Any body here?
> I just want to build postgresql from source.
> Can you tell me what I doing wrong?
contrib/uuid-ossp relies on OSSP's uuid library, which you don't seem to
have installed. See
http://www.ossp.org/pkg/lib/uuid/
Most Linux distr
*** ** wrote:
> Can you tell me what I doing wrong?
Did you configure --with_ossp_uuid? Did you get any errors or
warnings when you ran ./configure?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
Fujii Masao wrote:
> On Fri, Dec 24, 2010 at 11:47 PM, Bruce Momjian wrote:
> > Applied.
>
> storage.sgml seems to need to be updated.
Ah, I see that now, thanks. Patch attached and applied.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterp
Alvaro Herrera writes:
> Excerpts from Peter Geoghegan's message of lun dic 27 16:13:33 -0300 2010:
>> constexpr
>> decltype
>> nullptr
>> static_assert
> I think only constexpr is being currently used from this list, and it's
> easily fixed because it's not exposed beyond a single file.
If you'
Hello?
Any body here?
I just want to build postgresql from source.
Can you tell me what I doing wrong?
27 декабря 2010 г. 12:28 пользователь Николай Ижиков
написал:
> I got following error when try your advice.
>
> uuid-ossp.c:29:2: ошибка: #error OSSP uuid.h not found
> uuid-ossp.c:35:2: ошибк
Excerpts from Peter Geoghegan's message of lun dic 27 16:13:33 -0300 2010:
> I hope that we don't make the mistake of not checking for collisions
> with C++0x keywords, for which GCC 4.3+ has partial support. The new
> standard is almost complete, so it will probably become a lot more
> relevant so
On Mon, 2010-12-27 at 13:33 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > Do you disagree with the ADD or the DROP, or both?
>
> Both.
>
> > What "stuff" will break, in your opinion? I'm not asking you to do the
> > research, but a few curveballs would be enough to end this quickly, and
> > l
On 27 December 2010 19:17, Tom Lane wrote:
> [ shrug... ] If it's not a keyword according to popularly available
> tools, then I really have zero interest in worrying about it. This
> is an exercise in making the headers useful in practice, not in academic
> standards conformance.
It isn't acad
Peter Geoghegan writes:
> I hope that we don't make the mistake of not checking for collisions
> with C++0x keywords, for which GCC 4.3+ has partial support. The new
> standard is almost complete, so it will probably become a lot more
> relevant soon. There are quite a few new keywords in C++0x, i
I hope that we don't make the mistake of not checking for collisions
with C++0x keywords, for which GCC 4.3+ has partial support. The new
standard is almost complete, so it will probably become a lot more
relevant soon. There are quite a few new keywords in C++0x, including:
constexpr
decltype
nul
On Mon, Dec 27, 2010 at 10:18 AM, Tom Lane wrote:
> Robert Haas writes:
>> or if we go with the some-assembly required version, perhaps:
>
>> "tables do not support %s"
>> "views do not support %s"
>> "indexes do not support %s"
>
> +1 for that way. Although personally I'd reverse the phrasing:
Simon Riggs writes:
> Do you disagree with the ADD or the DROP, or both?
Both.
> What "stuff" will break, in your opinion? I'm not asking you to do the
> research, but a few curveballs would be enough to end this quickly, and
> leave a good record for the archives.
The most obvious point is tha
I'm working on a tool to simplify updating the source code of database
functions.
To do a "revert" my plan is to store the values of pg_proc.* before
updating, and then to restore pg_proc for the given oid if a revert is
necessary.
This raises the question,
Is it "safe" to do,
UPDATE pg_proc SET
BTW, the cpluspluscheck script invokes g++ with -fno-operator-names,
saying
# -fno-operator-names omits the definition of bitand and bitor, which
# collide with varbit.h. Could be fixed, if one were so inclined.
I just confirmed that those two function definitions are the only is
Magnus Hagander writes:
> On Mon, Dec 27, 2010 at 18:50, Tom Lane wrote:
>> src/tools/pginclude/ already contains several scripts for this sort of
>> thing. Bruce runs them by hand occasionally, although I just found out
>> that he's evidently not run the does-each-header-compile-standalone
>> t
On Mon, Dec 27, 2010 at 18:50, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Tom Lane's message of lun dic 27 13:54:56 -0300 2010:
>>> [ lightbulb ] ... although we could improve that quite a bit if we
>>> processed each .h file separately instead of insisting on smashing
>>> everythi
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of lun dic 27 13:54:56 -0300 2010:
>> [ lightbulb ] ... although we could improve that quite a bit if we
>> processed each .h file separately instead of insisting on smashing
>> everything into one compilation. Let me go try that.
> FWIW
On mån, 2010-12-27 at 12:33 -0500, Andrew Dunstan wrote:
> On a more general point, it would be useful to have some
> infrastructure for running quality checks like this and publishing the
> results. We should be way beyond the point where we rely on
> individuals doing this sort of stuff.
I had a
On Mon, Dec 27, 2010 at 12:33:00PM -0500, Andrew Dunstan wrote:
> On 12/27/2010 11:54 AM, Tom Lane wrote:
> >After a bit of experimentation, I can say that this is better than
> >Andrew's hack, but it's still a good distance shy of something that
> >should be automated or treated as a hard requirem
On 12/27/2010 11:54 AM, Tom Lane wrote:
After a bit of experimentation, I can say that this is better than
Andrew's hack, but it's still a good distance shy of something that
should be automated or treated as a hard requirement.
I'm always happy if someone produces something better than I did
Excerpts from Tom Lane's message of lun dic 27 13:54:56 -0300 2010:
> [ lightbulb ] ... although we could improve that quite a bit if we
> processed each .h file separately instead of insisting on smashing
> everything into one compilation. Let me go try that.
FWIW I have this patch lingering ab
Peter Eisentraut writes:
> src/tools/pginclude/cpluspluscheck
Ah, I'd forgotten that.
> What's missing is to automate this, but it's unclear in what context,
> and perhaps also to what extend this should be a hard requirement.
After a bit of experimentation, I can say that this is better than
A
Hi everyone,
about two weeks ago I've started a thread about cross-column stats. One
of the proposed solutions is based on number of distinct values, and the
truth is the current distinct estimator has some problems.
I've done some small research - I have read about 20 papers on this, and
I'd lik
Excerpts from Peter Eisentraut's message of lun dic 27 12:54:16 -0300 2010:
> On sön, 2010-12-26 at 12:31 -0500, Tom Lane wrote:
> > We did clean up C++ keyword uses in the header files in 9.0, but your
> > report shows it's already gotten broken again. I'm disinclined to fix
> > it unless someone
On Mon, 2010-12-27 at 10:41 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Dec 27, 2010 at 6:42 AM, Simon Riggs wrote:
> >> Idea is to reduce lock level of ADD/DROP COLUMN from AccessExclusiveLock
> >> down to ShareRowExclusiveLock.
> >>
> >> To make it work, we need to recognise that
On Mon, Dec 27, 2010 at 16:45, Simon Riggs wrote:
> On Mon, 2010-12-27 at 14:54 +0100, Magnus Hagander wrote:
>
>> You will certainly be able to log into the standby with a superuser
>> account, nobody is preventing that. This is about protecting the
>> *master*. For example, from modifications ma
On sön, 2010-12-26 at 12:31 -0500, Tom Lane wrote:
> We did clean up C++ keyword uses in the header files in 9.0, but your
> report shows it's already gotten broken again. I'm disinclined to fix
> it unless someone steps up to create an automated test that will get
> run reasonably often. We had
On Mon, 2010-12-27 at 10:24 -0500, Robert Haas wrote:
> On Mon, Dec 27, 2010 at 6:42 AM, Simon Riggs wrote:
> > Idea is to reduce lock level of ADD/DROP COLUMN from AccessExclusiveLock
> > down to ShareRowExclusiveLock.
> >
> > To make it work, we need to recognise that we are adding a column
> >
On Mon, 2010-12-27 at 14:54 +0100, Magnus Hagander wrote:
> You will certainly be able to log into the standby with a superuser
> account, nobody is preventing that. This is about protecting the
> *master*. For example, from modifications made by a user who hacked
> the standby.
The users for ma
Robert Haas writes:
> On Mon, Dec 27, 2010 at 6:42 AM, Simon Riggs wrote:
>> Idea is to reduce lock level of ADD/DROP COLUMN from AccessExclusiveLock
>> down to ShareRowExclusiveLock.
>>
>> To make it work, we need to recognise that we are adding a column
>> without rewriting the table.
> Can y
On Mon, Dec 27, 2010 at 16:33, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Dec 27, 2010 at 10:53, Magnus Hagander wrote:
>>> We could quite easily make a replication role *never* be able to
>>> connect to a non-walsender backend. That would mean that if you set
>>> your role to WITH REP
Magnus Hagander writes:
> On Mon, Dec 27, 2010 at 10:53, Magnus Hagander wrote:
>> We could quite easily make a replication role *never* be able to
>> connect to a non-walsender backend. That would mean that if you set
>> your role to WITH REPLICATION, it can *only* be used for replication
>> and
On Mon, Dec 27, 2010 at 6:42 AM, Simon Riggs wrote:
> Idea is to reduce lock level of ADD/DROP COLUMN from AccessExclusiveLock
> down to ShareRowExclusiveLock.
>
> To make it work, we need to recognise that we are adding a column
> without rewriting the table.
Can you elaborate on why you think t
Robert Haas writes:
> or if we go with the some-assembly required version, perhaps:
> "tables do not support %s"
> "views do not support %s"
> "indexes do not support %s"
+1 for that way. Although personally I'd reverse the phrasing:
/* translator: %s is the name of a SQL command */
Dne 24.12.2010 13:37, Florian Pflug napsal(a):
> On Dec24, 2010, at 11:23 , Nicolas Barbier wrote:
>
>> 2010/12/24 Florian Pflug :
>>
>>> On Dec23, 2010, at 20:39 , Tomas Vondra wrote:
>>>
I guess we could use the highest possible value (equal to the number
of tuples) - according to
On Mon, Dec 27, 2010 at 14:51, Simon Riggs wrote:
> On Mon, 2010-12-27 at 14:41 +0100, Magnus Hagander wrote:
>> >> >
>> >> > Where does pg_start_backup()/stop fit?
>> >>
>> >> Good question :)
>> >>
>> >> Given that the integrated-base-backup would call it for you, that one
>> >> would definitely
On Mon, 2010-12-27 at 14:41 +0100, Magnus Hagander wrote:
> >> >
> >> > Where does pg_start_backup()/stop fit?
> >>
> >> Good question :)
> >>
> >> Given that the integrated-base-backup would call it for you, that one
> >> would definitely get it automatically.
> >>
> >> Given that the latest disci
On Mon, Dec 27, 2010 at 14:25, Simon Riggs wrote:
> On Mon, 2010-12-27 at 12:00 +0100, Magnus Hagander wrote:
>> On Mon, Dec 27, 2010 at 11:34, Simon Riggs wrote:
>> > On Mon, 2010-12-27 at 10:36 +0100, Magnus Hagander wrote:
>> >> > Is backup part of this new privilege, or not?
>> >>
>> >> The "
On Thu, Dec 23, 2010 at 13:09, Magnus Hagander wrote:
> This patch adds counters and views to monitor hot standby generated
> recovery conflicts. It extends the pg_stat_database view with one
> column with the total number of conflicts, and also creates a new view
> pg_stat_database_conflicts that
On Mon, 2010-12-27 at 12:00 +0100, Magnus Hagander wrote:
> On Mon, Dec 27, 2010 at 11:34, Simon Riggs wrote:
> > On Mon, 2010-12-27 at 10:36 +0100, Magnus Hagander wrote:
> >> > Is backup part of this new privilege, or not?
> >>
> >> The "integrated base backup", once we have that, that's based o
2010/12/27 Itagaki Takahiro :
> On Mon, Dec 27, 2010 at 20:15, Pavel Stehule wrote:
>> * trim_array - you use a deconstruct_array. It unpack all fields and
>> it could not be effective. Can we limit a unpacked array?
>
> Sure, I'll optimize it.
>
>> I searched on net. This function has a little b
On Mon, Dec 27, 2010 at 20:15, Pavel Stehule wrote:
> * trim_array - you use a deconstruct_array. It unpack all fields and
> it could not be effective. Can we limit a unpacked array?
Sure, I'll optimize it.
> I searched on net. This function has a little bit unconptual name -
> DB2 use a synony
Idea is to reduce lock level of ADD/DROP COLUMN from AccessExclusiveLock
down to ShareRowExclusiveLock.
To make it work, we need to recognise that we are adding a column
without rewriting the table. That's a simple test at post parse analysis
stage, but what I can't do is work out whether the col
On Dec27, 2010, at 12:15 , Magnus Hagander wrote:
> Actually, having implemented that and tested it, I realize that's a
> pretty bad idea. For one thing, it broke my own pg_streamrecv program,
> since it requires the ability to connect to the master and select a
> pg_current_xlog_location().
I'm s
Hello
some quick notes:
* trim_array - you use a deconstruct_array. It unpack all fields and
it could not be effective. Can we limit a unpacked array?
I searched on net. This function has a little bit unconptual name -
DB2 use a synonym for this function array_trim. Can we use this
synonym too?
On Mon, Dec 27, 2010 at 10:53, Magnus Hagander wrote:
> On Fri, Dec 24, 2010 at 05:46, Stephen Frost wrote:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>>> I think I agree with Florian about the confusing-ness of the proposed
>>> semantics. Aren't you saying you want NOLOGIN mean "not allowe
On Mon, Dec 27, 2010 at 3:22 AM, Simon Riggs wrote:
> Not sure from reading the docs whether unlogged indexes are supported on
> logged tables? Could you clarify (or clarify more often)? Does this
> solve the hash index situation?
They are not. The only place you'll see that the grammar has been
On Mon, Dec 27, 2010 at 11:34, Simon Riggs wrote:
> On Mon, 2010-12-27 at 10:36 +0100, Magnus Hagander wrote:
>> > Is backup part of this new privilege, or not?
>>
>> The "integrated base backup", once we have that, that's based on the
>> walsender protocol? yes.
>> pg_dump style backups? No.
>
>
On Mon, 2010-12-27 at 10:36 +0100, Magnus Hagander wrote:
> > Is backup part of this new privilege, or not?
>
> The "integrated base backup", once we have that, that's based on the
> walsender protocol? yes.
> pg_dump style backups? No.
Where does pg_start_backup()/stop fit?
--
Simon Riggs
On Fri, Dec 24, 2010 at 05:46, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> I think I agree with Florian about the confusing-ness of the proposed
>> semantics. Aren't you saying you want NOLOGIN mean "not allowed to
>> log in for the purposes of issuing SQL commands, but
On Mon, Dec 27, 2010 at 9:36 AM, Magnus Hagander wrote:
> Seeing logged SQL isn't - but being able to filter the logfiles on
> that requires a *lot* more than just defining a security privilege. If
> we mean "arbitrary log file reading", the easiest way to fix that
> would be to stop checking for
On Mon, Dec 27, 2010 at 09:32, Simon Riggs wrote:
> On Thu, 2010-12-23 at 10:53 +0100, Magnus Hagander wrote:
>
>> Here's a patch that changes walsender to require a special privilege
>> for replication instead of relying on superuser permissions. We
>> discussed this back before 9.0 was finalized
I got following error when try your advice.
uuid-ossp.c:29:2: ошибка: #error OSSP uuid.h not found
uuid-ossp.c:35:2: ошибка: #error UUID length mismatch
uuid-ossp.c:68:27: ошибка: expected ')' before 'rc'
uuid-ossp.c:83:22: предупреждение: type defaults to 'int' in declaration of
'uuid_t'
uuid-oss
On Fri, 2010-12-24 at 00:27 -0500, Jie Li wrote:
> I doubt the cost of comparing two integers is the issue here;
> rather
> it's more likely one of how many merge passes were needed.
> You could
> find out instead of just speculating by turning on trace_sor
On Fri, 2010-12-24 at 11:53 +0900, KaiGai Kohei wrote:
> The attached patch is the modular version of SE-PostgreSQL.
Looks interesting.
Couple of thoughts...
Docs don't mention row-level security. If we don't have it, I think we
should say that clearly.
I think we need a "Guide to Security Lab
On Thu, 2010-12-23 at 10:53 +0100, Magnus Hagander wrote:
> Here's a patch that changes walsender to require a special privilege
> for replication instead of relying on superuser permissions. We
> discussed this back before 9.0 was finalized, but IIRC we ran out of
> time. The motivation being tha
On Fri, 2010-12-24 at 23:36 -0500, Robert Haas wrote:
> Here's an updated patch for unlogged tables, incorporating the
> following changes since v4:
Looks good
> 5. Support unlogged GIN indexes.
Not sure from reading the docs whether unlogged indexes are supported on
logged tables? Could you cla
On Mon, 2010-12-27 at 10:36 +0900, Itagaki Takahiro wrote:
> On Mon, Dec 27, 2010 at 02:09, Pavel Stehule wrote:
> > I have a free time and I can do a review of your patch. Please, can
> > send a last version and can send a links on documentation that you
> > used?
>
> Thanks! The latest patch at
94 matches
Mail list logo
