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
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
On Thu, Dec 23, 2010 at 04:08, Jan Urbański wulc...@wulczer.org 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
On 23/12/10 12:16, Marti Raudsepp wrote:
On Thu, Dec 23, 2010 at 04:08, Jan Urbański wulc...@wulczer.org 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
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.
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,
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:
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:
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 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
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 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
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
List of
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:
On Thu, Dec 23, 2010 at 09:33, Jie Li jay23j...@gmail.com 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
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
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;
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:
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:
On Thu, Dec 23, 2010 at 10:42:26PM +0800, Li Jie wrote:
- Original Message -
From: Kenneth Marshall k...@rice.edu
To: Li Jie jay23j...@gmail.com
Cc: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Thursday, December 23, 2010 10:30 PM
Subject: Re: [HACKERS] Why is sorting on two
Magnus Hagander mag...@hagander.net 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
On Wed, 22 Dec 2010 21:02:35 -0500 (EST)
Bruce Momjian br...@momjian.us 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 alvhe...@commandprompt.com wrote:
I think the way
Kenneth Marshall k...@rice.edu 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
On Thu, Dec 23, 2010 at 10:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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,
Robert Haas robertmh...@gmail.com 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
On Thu, Dec 23, 2010 at 10:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Wed, Dec 22, 2010 at 7:35 PM, Srini Raghavan sixersr...@yahoo.com 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
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 in the
2010/12/23 Tomas Vondra t...@fuzzy.cz:
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
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 in
Dne 23.12.2010 20:09, Robert Haas napsal(a):
2010/12/23 Tomas Vondra t...@fuzzy.cz:
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%
On Thu, Dec 23, 2010 at 16:15, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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
On Thu, Dec 23, 2010 at 16:57, Robert Haas robertmh...@gmail.com wrote:
On Thu, Dec 23, 2010 at 10:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I haven't looked at the patch yet, but I think we should continue to
allow superuser-ness to be *sufficient*
- Original Message -
From: Kenneth Marshall k...@rice.edu
To: Li Jie jay23j...@gmail.com
Cc: pgsql-hackers pgsql-hackers@postgresql.org
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,
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
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
Magnus Hagander mag...@hagander.net writes:
On Thu, Dec 23, 2010 at 16:15, Tom Lane t...@sss.pgh.pa.us 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
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 mag...@hagander.net writes:
On Thu, Dec 23, 2010 at 16:57, Robert Haas robertmh...@gmail.com wrote:
On Thu, Dec 23, 2010 at 10:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't particularly mind breaking that. If we leave it as-is, we'll
be encouraging people to use superuser
On 12/23/2010 08:59 PM, Magnus Hagander wrote:
On Thu, Dec 23, 2010 at 16:57, Robert Haasrobertmh...@gmail.com wrote:
On Thu, Dec 23, 2010 at 10:54 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haasrobertmh...@gmail.com writes:
I haven't looked at the patch yet, but I think we should
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 Thu, Dec 23, 2010 at 22:09, Peter Eisentraut pete...@gmx.net 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.
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 a
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
Andres Freund and...@anarazel.de 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
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
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 think
Josh Berkus j...@agliodbs.com 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.
On 12/23/10 2:21 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
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:
Josh Berkus j...@agliodbs.com 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
* 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 more secure.
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 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
* 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 'for'
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.
--
* 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
On Thu, Dec 23, 2010 at 23:44, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com 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
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
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
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
On Thu, Dec 23, 2010 at 5:59 PM, Josh Berkus j...@agliodbs.com 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
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
On Tue, Dec 21, 2010 at 21:32, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Tue, Dec 21, 2010 at 20:14, Shigeru HANADA han...@metrosystems.co.jp
wrote:
Attached is the revised version of file_fdw patch. This patch is
based on Itagaki-san's copy_export-20101220.diff patch.
#1.
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 surprise
Florian Pflug f...@phlo.org 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
On Dec24, 2010, at 04:16 , Tom Lane wrote:
Florian Pflug f...@phlo.org 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
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 at an
Florian Pflug f...@phlo.org 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
On Thu, Dec 23, 2010 at 11:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org 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
Back in 2006, we have this commit:
commit 2b25e1169f44368c120931787628d51731b5cc8c
Author: Peter Eisentraut pete...@gmx.net
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
* 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
(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't
On Friday 24 December 2010 05:35:26 Robert Haas wrote:
Back in 2006, we have this commit:
commit 2b25e1169f44368c120931787628d51731b5cc8c
Author: Peter Eisentraut pete...@gmx.net
Date: Sat Oct 7 20:59:05 2006 +
The -X option in pg_dump was supposed to be a workaround for the
74 matches
Mail list logo
