On Friday 24 December 2010 05:35:26 Robert Haas wrote:
> Back in 2006, we have this commit:
>
> commit 2b25e1169f44368c120931787628d51731b5cc8c
> Author: Peter Eisentraut
> Date: Sat Oct 7 20:59:05 2006 +
>
> The -X option in pg_dump was supposed to be a workaround for the lack
> of po
(2010/12/24 11:53), KaiGai Kohei wrote:
> There is one another issue to be discussed.
> We need a special form of regression test. Because SE-PostgreSQL
> makes access control decision based on security label of the peer
> process, we need to switch psql process during regression test.
> (So, I don
* 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 allowed to log in
> for replication"? Uggh.
I like the
Back in 2006, we have this commit:
commit 2b25e1169f44368c120931787628d51731b5cc8c
Author: Peter Eisentraut
Date: Sat Oct 7 20:59:05 2006 +
The -X option in pg_dump was supposed to be a workaround for the lack of
portable long options. But we have had portable long options for a l
On Thu, Dec 23, 2010 at 11:00 PM, Tom Lane wrote:
> Florian Pflug writes:
>> The problem here is that you suggest NOLOGIN should mean "Not allowed
>> to issue SQL commands", which really isn't what the name "NOLOGIN"
>> conveys.
>
> No, it means "not allowed to connect". It's possible now to iss
Florian Pflug writes:
> The problem here is that you suggest NOLOGIN should mean "Not allowed
> to issue SQL commands", which really isn't what the name "NOLOGIN"
> conveys.
No, it means "not allowed to connect". It's possible now to issue
commands as a NOLOGIN user, you just have to use SET ROL
On Dec23, 2010, at 20:39 , Tomas Vondra wrote:
> Dne 21.12.2010 16:54, Florian Pflug napsal(a):
>> I think that maybe it'd be acceptable to scan a large portion of the
>> table to estimate dist(A,B), *if* we must only do so only once in a while.
>> But even with
>> a full scan, how would we arrive
On Dec24, 2010, at 04:16 , Tom Lane wrote:
> Florian Pflug writes:
>> On Dec23, 2010, at 16:54 , Tom Lane wrote:
>>> BTW, is it possible to set things up so that a REPLICATION account
>>> can be NOLOGIN, thereby making it really hard to abuse for other
>>> purposes? Or does the login privilege ch
Florian Pflug writes:
> On Dec23, 2010, at 16:54 , Tom Lane wrote:
>> BTW, is it possible to set things up so that a REPLICATION account
>> can be NOLOGIN, thereby making it really hard to abuse for other
>> purposes? Or does the login privilege check come too soon?
> Please don't. This violates
On Dec23, 2010, at 16:54 , Tom Lane wrote:
> BTW, is it possible to set things up so that a REPLICATION account
> can be NOLOGIN, thereby making it really hard to abuse for other
> purposes? Or does the login privilege check come too soon?
Please don't. This violates the principle of least surpri
On Tue, Dec 21, 2010 at 21:32, Itagaki Takahiro
wrote:
> On Tue, Dec 21, 2010 at 20:14, Shigeru HANADA
> wrote:
>> Attached is the revised version of file_fdw patch. This patch is
>> based on Itagaki-san's copy_export-20101220.diff patch.
>
> #1. Don't you have per-tuple memory leak? I added Ge
> If the user exists but is disabled by default, I'm not sure that
> really provides any advantage over not having it at all. And it
> certainly can't be enabled by default.
I was presuming that NOLOGIN wouldn't prevent a replication connections
via the replication user. So the user would be "e
On Thu, Dec 23, 2010 at 5:59 PM, Josh Berkus wrote:
>
>> I'm not entirely sure about this one.. I'm not against it but I'm also
>> not really 'for' it. :)
>
> 2 reasons: (a) if users need to CREATE USER, that *does* add an extra
> step and they're more likely to just choose to grant to postgres
>
Greg, All:
Results for Solaris 10u8, on ZFS on a 7-drive attached storage array:
bash-3.00# ./test_fsync -f /dbdata/pgdata/test.out
Loops = 1
Simple write:
8k write 59988.002/second
Compare file sync methods using one write:
open_datasync 8k write
Thank you, that is a great point.
Based on your suggesstion, I wrote the following query:
select * from pg_class where relisshared=true order by relname
The above query returns 27 rows. I evaluated the impact on the following:
pg_auth_members - We create roles and memberships on each deplo
> I'm not entirely sure about this one.. I'm not against it but I'm also
> not really 'for' it. :)
2 reasons: (a) if users need to CREATE USER, that *does* add an extra
step and they're more likely to just choose to grant to postgres
instead, (b) having a standard installed user (just like the u
On Thu, Dec 23, 2010 at 23:44, Tom Lane wrote:
> Josh Berkus writes:
>> On 12/23/10 2:33 PM, Stephen Frost wrote:
>>> A better alternative, imv, would be to just have a & d, and mention in
>>> the release notes that users *should* create a dedicated replication
>>> role which is *not* a superuser
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> However, it'd be a real good idea for that role to be NOLOGIN if it's
> there by default.
Definitely. I'd also suggest we WARN if someone creates a situation
where a role has both replication and login, and maybe prevent it
altogether, it's just a bad idea
> Which means if we just export the macros, we would still not have caught
> this. I would like to share all the defines --- I am just saying it
> isn't trivial.
I just called all the define variables manually rather than relying on
the macros. Seemed to work fine.
--
* Josh Berkus (j...@agliodbs.com) wrote:
> 1) have a replication permission
Right, that's what this patch is about.
> 2) *by default* create a replication user with the replication
> permission when we initdb.
I'm not entirely sure about this one.. I'm not against it but I'm also
not really 'fo
Josh Berkus writes:
> On 12/23/10 2:33 PM, Stephen Frost wrote:
>> A better alternative, imv, would be to just have a & d, and mention in
>> the release notes that users *should* create a dedicated replication
>> role which is *not* a superuser but *does* have the replication grant,
>> but if they
On 12/23/10 2:33 PM, Stephen Frost wrote:
> A better alternative, imv, would be to just have a & d, and mention in
> the release notes that users *should* create a dedicated replication
> role which is *not* a superuser but *does* have the replication grant,
> but if they don't want to change their
* Josh Berkus (j...@agliodbs.com) wrote:
> On 12/23/10 2:21 PM, Tom Lane wrote:
> > Well, that's one laudable goal here, but "secure by default" is another
> > one that ought to be taken into consideration.
>
> I don't see how *not* granting the superuser replication permissions
> makes things mor
Josh Berkus writes:
> On 12/23/10 2:21 PM, Tom Lane wrote:
>> Well, that's one laudable goal here, but "secure by default" is another
>> one that ought to be taken into consideration.
> I don't see how *not* granting the superuser replication permissions
> makes things more secure. The superuser
On 12/23/2010 07:11 AM, Pavel Golub wrote:
Hello, Pgsql-bugs.
Tried to use MinGw under windows to build client libraries at least.
However failed on "./configure --withou-zlib" stage.
Please find attached log file, stdout and stderr outputs.
The main problem here I suppose is
"configure: WAR
On 12/23/10 2:21 PM, Tom Lane wrote:
> Josh Berkus writes:
>> If we still make it possible for "postgres" to replicate, then we don't
>> add any complexity to the simplest setup.
>
> Well, that's one laudable goal here, but "secure by default" is another
> one that ought to be taken into consider
Josh Berkus writes:
> If we still make it possible for "postgres" to replicate, then we don't
> add any complexity to the simplest setup.
Well, that's one laudable goal here, but "secure by default" is another
one that ought to be taken into consideration.
regards, tom la
Excerpts from Srini Raghavan's message of jue dic 23 18:55:20 -0300 2010:
> Please let me know if you or anyone think of any other potential issues.
> Thanks
> again for reviewing.
I think anything in the shared catalogs could be an issue (look for
tables with pg_class.relisshared=true). I thi
On 12/23/10 7:49 AM, Robert Haas wrote:
> I haven't looked at the patch yet, but I think we should continue to
> allow superuser-ness to be *sufficient* for replication - i.e.
> superusers will automatically have the replication privilege just as
> they do any other - and merely allow this as an op
Andres Freund wrote:
> I will try to read the thread and make a proposal for a more
> carefull implementation - just not today... I think the results
> would be interesting...
FWIW, the SSI patch that Dan and I are working on can't have a
guarantee that it is immediately safe to retry a transa
Thank you very much for reviewing, appreciate the feedback. As pointed out by
you, it is always best to test it out with the latest version, so, I tested the
same approach with postgres 9.0.2 on windows just now, and it works!
I forgot to mention earlier that in addition to setting vacuum_fre
Dne 21.12.2010 19:03, Tomas Vondra napsal(a):
> My plan for the near future (a few weeks) is to build a simple 'module'
> with the ability to estimate the number of rows for a given condition.
> This could actually be quite useful as a stand-alone contrib module, as
> the users often ask how to get
On Thu, Dec 23, 2010 at 22:09, Peter Eisentraut wrote:
> Somehow I fantasized that log_hostname would also turn
> pg_stat_activity.client_addr into names instead of IP addresses. It
> doesn't, but perhaps it should? It would be nice to be able to
> configure an IP-address free setup. Or would i
Somehow I fantasized that log_hostname would also turn
pg_stat_activity.client_addr into names instead of IP addresses. It
doesn't, but perhaps it should? It would be nice to be able to
configure an IP-address free setup. Or would it be worth having a
separate configuration parameter for that?
On 12/23/2010 08:59 PM, Magnus Hagander wrote:
On Thu, Dec 23, 2010 at 16:57, Robert Haas wrote:
On Thu, Dec 23, 2010 at 10:54 AM, Tom Lane wrote:
Robert Haas writes:
I haven't looked at the patch yet, but I think we should continue to
allow superuser-ness to be *sufficient* for replication
Magnus Hagander writes:
> On Thu, Dec 23, 2010 at 16:57, Robert Haas wrote:
>> On Thu, Dec 23, 2010 at 10:54 AM, Tom Lane wrote:
>>> I don't particularly mind breaking that. If we leave it as-is, we'll
>>> be encouraging people to use superuser accounts for things that don't
>>> need that, whic
Hello
attached patch contains a implementation of iteration over a array:
Regards
Pavel Stehule
*** ./doc/src/sgml/plpgsql.sgml.orig 2010-12-09 08:20:08.0 +0100
--- ./doc/src/sgml/plpgsql.sgml 2010-12-23 21:05:51.459678695 +0100
***
*** 2238,2243
--- 2238,2268
Magnus Hagander writes:
> On Thu, Dec 23, 2010 at 16:15, Tom Lane wrote:
>> I think only superusers should be allowed to change the flag.
> That was certainly not intentional - and doesn't work that way for me
> at least, unless I broke it right before I submitted it.
> oh hang on.. Yeah, it's
Hi Ken,
Thanks for your tips! Yes it is the case, and I run another query sorting on
the second column whose values are random.
postgres=# explain analyze select * from big_wf order by id;
QUERY PLAN
Hi Marti,
Thanks for your help! I guess I understand what you mean, a clustered index
will make sorting as cheap as a seq scan, right?
But what I meant is, is there any potential optimization for the backend
implementation? Intuitively, if sorting on one column or two columns will incur
the sa
- Original Message -
From: "Kenneth Marshall"
To: "Li Jie"
Cc: "pgsql-hackers"
Sent: Thursday, December 23, 2010 10:30 PM
Subject: Re: [HACKERS] Why is sorting on two columns so slower thansortingon
one column?
> On Thu, Dec 23, 2010 at 10:19:46PM +0800, Li Jie wrote:
>> Hi Ken,
>>
On Thu, Dec 23, 2010 at 16:57, Robert Haas wrote:
> On Thu, Dec 23, 2010 at 10:54 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> I haven't looked at the patch yet, but I think we should continue to
>>> allow superuser-ness to be *sufficient* for replication - i.e.
>>> superusers will automatical
On Thu, Dec 23, 2010 at 16:15, Tom Lane wrote:
> Magnus Hagander writes:
>> 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
Dne 23.12.2010 20:09, Robert Haas napsal(a):
> 2010/12/23 Tomas Vondra :
>> Dne 20.12.2010 00:03, Tom Lane napsal(a):
>>> I wrote:
That is not the number of interest. The number of interest is that it's
8 bytes added onto a struct that currently contains 11 of 'em; in other
words a
Dne 21.12.2010 16:54, Florian Pflug napsal(a):
> I think that maybe it'd be acceptable to scan a large portion of the
> table to estimate dist(A,B), *if* we must only do so only once in a while.
> But even with
> a full scan, how would we arrive at an estimate for dist(A,B)? Keeping all
> values
2010/12/23 Tomas Vondra :
> Dne 20.12.2010 00:03, Tom Lane napsal(a):
>> I wrote:
>>> That is not the number of interest. The number of interest is that it's
>>> 8 bytes added onto a struct that currently contains 11 of 'em; in other
>>> words a 9% increase in the size of the stats file, and conse
Dne 20.12.2010 00:03, Tom Lane napsal(a):
> I wrote:
>> That is not the number of interest. The number of interest is that it's
>> 8 bytes added onto a struct that currently contains 11 of 'em; in other
>> words a 9% increase in the size of the stats file, and consequently
>> about a 9% increase i
On Wed, Dec 22, 2010 at 7:35 PM, Srini Raghavan wrote:
> I have tested this and it works, and I am continuing to test it more. I
> would like for validation of this idea from the experts and the community to
> make sure I haven't overlooked something obvious that might cause issues.
Interesting i
On Thu, Dec 23, 2010 at 10:54 AM, Tom Lane wrote:
> Robert Haas writes:
>> I haven't looked at the patch yet, but I think we should continue to
>> allow superuser-ness to be *sufficient* for replication - i.e.
>> superusers will automatically have the replication privilege just as
>> they do any
Robert Haas writes:
> I haven't looked at the patch yet, but I think we should continue to
> allow superuser-ness to be *sufficient* for replication - i.e.
> superusers will automatically have the replication privilege just as
> they do any other - and merely allow this as an option for when you
>
On Thu, Dec 23, 2010 at 10:15 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> 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. T
Kenneth Marshall writes:
> On Thu, Dec 23, 2010 at 10:42:26PM +0800, Li Jie wrote:
>> But in the last query that sorts on "id", since the query selects all the
>> columns for output, the actual sorted size is the same, and the only
>> difference is the comparison cost. The query sorting on two
On Wed, 22 Dec 2010 21:02:35 -0500 (EST)
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Excerpts from Quan Zongliang's message of mar dic 21 18:36:11 -0300 2010:
> > > On Mon, 29 Nov 2010 10:29:17 -0300
> > > Alvaro Herrera wrote:
> > >
> >
> > > > I think the way this should work is that yo
Magnus Hagander writes:
> 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 that you really want to use superuser
On Thu, Dec 23, 2010 at 10:42:26PM +0800, Li Jie wrote:
> - Original Message -
> From: "Kenneth Marshall"
> To: "Li Jie"
> Cc: "pgsql-hackers"
> Sent: Thursday, December 23, 2010 10:30 PM
> Subject: Re: [HACKERS] Why is sorting on two columns so slower thansortingon
> one column?
>
>
Here's a patch implementing custom Python exceptions for SPI errors
mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the explicit-subxacts patch sent eariler.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/cust
Here's a patch implementing explicitly starting subtransactions mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the spi-in-subxacts patch sent eariler.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/explicit-s
On Thu, Dec 23, 2010 at 10:19:46PM +0800, Li Jie wrote:
> Hi Ken,
>
> Thanks for your tips! Yes it is the case, and I run another query sorting on
> the second column whose values are random.
>
> postgres=# explain analyze select * from big_wf order by id;
>
On 21.12.2010 20:00, Heikki Linnakangas wrote:
One final version, with a bug fix wrt. root page split and some cleanup.
I'm planning to commit this before Christmas. It's a big patch, so
review would be much appreciated.
Committed. Phew! Review & testing is of course still appreciated, given
h
On Thu, Dec 23, 2010 at 09:33, Jie Li wrote:
> While the first sorting takes
> about only 6 seconds, the second one takes over 30 seconds, Is this too
> much than expected? Is there any possible optimization ?
If you're doing these queries often, you should:
CREATE INDEX ix_big_wf_age_id ON big_
Here's a patch implementing custom parsers for data types mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/custom-parsers
On Thu, Dec 23, 2010 at 02:33:12AM -0500, Jie Li wrote:
> Hi,
>
> Here is the test table,
>
> postgres=# \d big_wf
> Table "public.big_wf"
> Column | Type | Modifiers
> +-+---
> age| integer |
> id | integer |
>
> postgres=# \dt+ big_wf
>
Here's a patch implementing table functions mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/table-functions.
This allow
Here's a patch implementing traceback support for PL/Python mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/tracebacks.
Here's a patch implementing properly invalidating functions that have
composite type arguments after the type changes, as mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Git branch for thi
Hi,
Here is the test table,
postgres=# \d big_wf
Table "public.big_wf"
Column | Type | Modifiers
+-+---
age| integer |
id | integer |
postgres=# \dt+ big_wf
List of relations
Schema | Name | Type | Owner | Size | Description
Here's a patch implementing a executing SPI in an subtransaction
mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/spi-in-
On 23/12/10 14:41, Jan Urbański wrote:
> Here's a patch implementing a validator functoin mentioned in
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
> an incremental patch on top of the plpython-refactor patch sent eariler.
>
> Git branch for this patch:
> https://githu
Here's a patch implementing a validator functoin mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/validator.
Cheers,
Jan
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 contains a breakdown of exactly what
caused the conflicts.
Do
On 23/12/10 12:16, Marti Raudsepp wrote:
> On Thu, Dec 23, 2010 at 04:08, Jan Urbański wrote:
>> * providing custom exceptions for SPI errors, so you can catch only
>> UniqueViolations and not have to muck around with SQLCODE
>
> py-postgresql already has a mapping from error codes to Python
> e
On Thu, Dec 23, 2010 at 04:08, Jan Urbański wrote:
> * providing custom exceptions for SPI errors, so you can catch only
> UniqueViolations and not have to muck around with SQLCODE
py-postgresql already has a mapping from error codes to Python
exceptions. I think it makes sense to re-use that, i
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 that you really want to use superuser as
little as possible - and sinc
Hello
I reread a discus to this topic. It's look like we can to find a
agreement on following syntax:
FOREACH var [,var [..]] [SLICE number] IN expr
LOOP
END LOOP;
In default mode, without keyword SLICE, it will iterate over every
field like "unnest" does. With SLICE keyword, it iterate over nes
74 matches
Mail list logo
