On 29.05.2012 04:18, Peter Geoghegan wrote:
The attached very simple patch moves the commit_delay +
commit_siblings sleep into XLogFlush, where the leader alone sleeps.
This appears to be a much more effective site for a delay.
Benchmark results, with and without a delay of 3000ms
On Tue, May 29, 2012 at 1:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
So, nothing to see here ... 8.4 is just not very good with this type
of problem.
Fair enough, thanks for your time. :)
Regards,
Marti
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Tom Lane t...@sss.pgh.pa.us writes:
is not going to happen. Putting shared libraries into a
postgres-writable directory will be seen (correctly) as a security hole
of the first magnitude, not to mention that in many systems it'd require
root privilege anyway to adjust the dynamic linker's
On May25, 2012, at 23:32 , Kohei KaiGai wrote:
However, it should not be applied on triggers being set on PK tables,
because it allows to modify or delete primary-key being referenced by
invisible foreign-key from the viewpoint of operators.
I think, it makes sense to have exceptional cases;
2012/5/27 Alastair Turner b...@ctrlf5.co.za:
Excerpts from Kohei KaiGai kai...@kaigai.gr.jp wrote on Fri, May 25,
2012 at 11:08 PM:
If we assume RLS is applied when user has
no privileges on tables, the current ExecCheckRTEPerms()
always raises an error towards unprivileged users, prior to
2012/5/28 Florian Pflug f...@phlo.org:
On May28, 2012, at 02:46 , Noah Misch wrote:
On Thu, May 24, 2012 at 07:31:37PM +0200, Florian Pflug wrote:
Since the security barrier flag carries a potentially hefty performance
penalty, I think it should be optional. Application which don't allow
On 29 May 2012 07:16, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 29.05.2012 04:18, Peter Geoghegan wrote:
Benchmark results, with and without a delay of 3000ms (commit_siblings
is 0 in both cases) are available from:
http://leadercommitdelay.staticloud.com
Sorry, I do
On May29, 2012, at 13:59 , Kohei KaiGai wrote:
2012/5/28 Florian Pflug f...@phlo.org:
Concept B is handled adequately by the LEAKPROOF flag. Concept C is handled
by the security_barrier flag. However, as you pointed out, it's a bit of a
dubious concept and only really necessary for backwards
Hi all,
I am using MingW W64 from SVN, version 3.0 beta-ish.
There are few issues when compiling Postgres with MingW W64. There was
a patch submitted to this list in July 2011 but it does not address
these issues (that I can tell). The following applies to both 32 and 64
bit builds.
On May29, 2012, at 13:37 , Kohei KaiGai wrote:
2012/5/27 Alastair Turner b...@ctrlf5.co.za:
Excerpts from Kohei KaiGai kai...@kaigai.gr.jp wrote on Fri, May 25,
2012 at 11:08 PM:
If we assume RLS is applied when user has
no privileges on tables, the current ExecCheckRTEPerms()
always raises
2012/5/29 Florian Pflug f...@phlo.org:
On May29, 2012, at 13:59 , Kohei KaiGai wrote:
2012/5/28 Florian Pflug f...@phlo.org:
Concept B is handled adequately by the LEAKPROOF flag. Concept C is handled
by the security_barrier flag. However, as you pointed out, it's a bit of a
dubious concept
On Sun, May 27, 2012 at 02:39:28PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Sun, May 27, 2012 at 11:31:12AM -0400, Tom Lane wrote:
I don't recall exactly what problems drove us to make pg_upgrade do
what it does with extensions, but we need a different fix for them.
On May29, 2012, at 16:13 , Kohei KaiGai wrote:
2012/5/29 Florian Pflug f...@phlo.org:
My motivation for suggesting that flag was to prevent people who want RLS,
yet aren't concerned about leaks, from having to pay the performance penalty
associated with not pushing down predicates.
I think
On Sun, May 27, 2012 at 02:32:52PM -0400, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
AIUI, for Tom's scheme to work pg_upgrade would need not to check
libraries that belonged to extension functions. Currently it simply
assumes that what is present in the old cluster is
2012/5/29 Florian Pflug f...@phlo.org:
On May29, 2012, at 13:37 , Kohei KaiGai wrote:
2012/5/27 Alastair Turner b...@ctrlf5.co.za:
Excerpts from Kohei KaiGai kai...@kaigai.gr.jp wrote on Fri, May 25,
2012 at 11:08 PM:
If we assume RLS is applied when user has
no privileges on tables, the
On Tue, May 29, 2012 at 9:12 AM, Florian Pflug f...@phlo.org wrote:
On May29, 2012, at 13:37 , Kohei KaiGai wrote:
2012/5/27 Alastair Turner b...@ctrlf5.co.za:
Excerpts from Kohei KaiGai kai...@kaigai.gr.jp wrote on Fri, May 25,
2012 at 11:08 PM:
If we assume RLS is applied when user has
no
On May29, 2012, at 16:34 , Robert Haas wrote:
One idea might be to have a grantable permission that permits the RLS
policy to be bypassed. So, if a user has only SELECT permission, they
can select from the table, but the RLS policy will apply. If they
have both SELECT and RLSBYPASS (probably
2012/5/29 Robert Haas robertmh...@gmail.com:
One idea might be to have a grantable permission that permits the RLS
policy to be bypassed. So, if a user has only SELECT permission, they
can select from the table, but the RLS policy will apply. If they
have both SELECT and RLSBYPASS (probably
On Fri, May 25, 2012 at 5:08 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I think it is a good idea not to apply RLS when current user has
superuser privilege from perspective of security model consistency,
but it is inconsistent to check privileges underlying tables.
Seems like a somewhat
On Tue, May 29, 2012 at 10:57 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/5/29 Robert Haas robertmh...@gmail.com:
One idea might be to have a grantable permission that permits the RLS
policy to be bypassed. So, if a user has only SELECT permission, they
can select from the table, but the
On May29, 2012, at 16:57 , Kohei KaiGai wrote:
2012/5/29 Robert Haas robertmh...@gmail.com:
One idea might be to have a grantable permission that permits the RLS
policy to be bypassed. So, if a user has only SELECT permission, they
can select from the table, but the RLS policy will apply. If
On Mon, May 28, 2012 at 8:15 AM, Waldecir Faria fighter2...@hotmail.com wrote:
Good morning, I am doing a study about buffer management to improve the
performance of one program that does heavy I/O operations. After looking and
reading from different softwares' source codes/texts one friend
On Mon, May 28, 2012 at 9:18 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
The attached very simple patch moves the commit_delay +
commit_siblings sleep into XLogFlush, where the leader alone sleeps.
This appears to be a much more effective site for a delay.
This is a clever idea, but I
On Mon, May 28, 2012 at 6:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Marti Raudsepp ma...@juffo.org writes:
On Mon, May 28, 2012 at 11:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, the error in your original example is far too large to be
explained by that, so I think it was tripping over
Robert Haas robertmh...@gmail.com writes:
Hmm, but isn't this a case of the left hand not knowing what the right
hand is doing? I mean, somehow we have enough information to estimate
that the index scans on b{1,2,3} are going to produce 2 rows per
execution, but having figured that out
On Tue, May 29, 2012 at 9:04 AM, Johann 'Myrkraverk' Oskarsson
joh...@2ndquadrant.com wrote:
The header file crtdefs.h in MinGW typedefs errcode which conflicts with
Postgres' elog.h.
#ifndef __ERRCODE_DEFINED_MS
#define __ERRCODE_DEFINED_MS
typedef int errcode;
#endif
Eep. Maybe this is
On 29 May 2012 17:10, Robert Haas robertmh...@gmail.com wrote:
This is a clever idea,
Thanks.
but I think it needs some fine-tuning: as
written, this will sleep for any flush, not just a flush of a commit
record. One idea might be to add a flag to XLogFlush indicating
whether a
On Tue, May 29, 2012 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Hmm, but isn't this a case of the left hand not knowing what the right
hand is doing? I mean, somehow we have enough information to estimate
that the index scans on b{1,2,3} are
On Tue, May 29, 2012 at 12:47 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
Why do you think that doing this for all XLogFlush() callsites might
be problematic?
Well, consider the one in the background writer, for example. That's
just a periodic flush, so I see no benefit in having it
On Mon, May 28, 2012 at 4:38 PM, Magnus Hagander mag...@hagander.net wrote:
On Mon, May 28, 2012 at 10:11 PM, Peter Eisentraut pete...@gmx.net wrote:
In 9.1, the pg_basebackup option --xlog takes no argument. In 9.2, it
takes a required argument. I think such compatibility breaks should be
Robert Haas robertmh...@gmail.com writes:
Well, I do not understand this code in depth (can you tell?) but it
seems to me that we are effectively computing the size of the inner
relation in two different ways in two different parts of the code.
That's because we are considering two different
Bruce Momjian br...@momjian.us writes:
I assumed I could just have pg_upgrade create and drop the extension in
the new database to make sure it works. In the JSON backpatch case, the
extension file would just do nothing, as has already been suggested.
It seems like checking for the control
On Tue, May 29, 2012 at 01:46:28PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I assumed I could just have pg_upgrade create and drop the extension in
the new database to make sure it works. In the JSON backpatch case, the
extension file would just do nothing, as has
Robert Haas robertmh...@gmail.com writes:
On Tue, May 29, 2012 at 9:04 AM, Johann 'Myrkraverk' Oskarsson
joh...@2ndquadrant.com wrote:
The header file crtdefs.h in MinGW typedefs errcode which conflicts with
Postgres' elog.h.
Eep. Maybe this is not directly relevant, but I guess my first
Bruce Momjian br...@momjian.us writes:
On Tue, May 29, 2012 at 01:46:28PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
In fact, can we identify right now if a function is used only by an
extension?
ITYM is the function defined by an extension, and the answer to that is
look
Hi,
On Monday, May 28, 2012 07:11:53 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Does anybody have a better idea than to either call WalSndWakeup() at
essentially the wrong places or calling it inside a critical section?
Tom, what danger do you see from calling it in
On Wed, May 30, 2012 at 2:03 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, May 28, 2012 at 4:38 PM, Magnus Hagander mag...@hagander.net wrote:
On Mon, May 28, 2012 at 10:11 PM, Peter Eisentraut pete...@gmx.net wrote:
In 9.1, the pg_basebackup option --xlog takes no argument. In 9.2, it
On Fri, May 25, 2012 at 4:06 PM, Jeff Janes jeff.ja...@gmail.com wrote:
If I invoke vacuum manually and do so with VacuumCostDelay == 0, I
have basically declared my intentions to get this pain over with as
fast as possible even if it might interfere with other processes.
Under that
Peter Eisentraut pete...@gmx.net writes:
On mån, 2012-05-14 at 15:11 -0400, Tom Lane wrote:
(In any case, my primary beef at the moment is not with whether it's a
good idea to change age()'s behavior going forward, but rather with
having back-patched such a change.)
Certainly we should
I just noticed a little bug in the way the levelStep parameter is
calculated when we switch to buffering build:
set client_min_messages='debug2';
This works:
postgres=# set maintenance_work_mem='1GB';
SET
postgres=# create index i_gisttest on gisttest using gist (t collate
C) WITH
On 24 May 2012 21:11, Robert Haas robertmh...@gmail.com wrote:
On Thu, May 24, 2012 at 2:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 23, 2012 at 2:28 PM, Fujii Masao masao.fu...@gmail.com wrote:
Is there plan to implement such external
On Tue, May 29, 2012 at 02:38:03PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Tue, May 29, 2012 at 01:46:28PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
In fact, can we identify right now if a function is used only by an
extension?
ITYM is the
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
This is because of this rather complex calculation here:
while (
/* subtree must fit in cache (with safety factor of 4) */
(1 - pow(avgIndexTuplesPerPage, (double) (levelStep + 1))) / (1 -
avgIndexTuplesPerPage)
How easy would it be to implement a fake async rep target?
Perhaps even as something that a server could allow a connection to
request? (ie a suitably permissioned connection could convert itself to
receive n async replication stream, rather than being statically
configured?)
I know that
Bruce Momjian br...@momjian.us writes:
On Tue, May 29, 2012 at 02:38:03PM -0400, Tom Lane wrote:
Well, it'd eliminate the kluges for plpython, as well as possibly fixing
Andrew's JSON backport issue, and going forward there are going to be
more things like that. So I think it's something to
On Tue, May 29, 2012 at 11:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
While I'm looking at this, is the first test involving
effective_cache_size bulletproof either? In particular, is
avgIndexTuplesPerPage clamped to be strictly greater than 1?
It's based on collected statistics on already
Alexander Korotkov aekorot...@gmail.com writes:
On Tue, May 29, 2012 at 11:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
While I'm looking at this, is the first test involving
effective_cache_size bulletproof either? In particular, is
avgIndexTuplesPerPage clamped to be strictly greater than 1?
On Tue, May 29, 2012 at 8:51 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, May 30, 2012 at 2:03 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, May 28, 2012 at 4:38 PM, Magnus Hagander mag...@hagander.net wrote:
On Mon, May 28, 2012 at 10:11 PM, Peter Eisentraut pete...@gmx.net
On Wed, May 30, 2012 at 12:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com writes:
On Tue, May 29, 2012 at 11:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
While I'm looking at this, is the first test involving
effective_cache_size bulletproof either? In
This is a patch against src/backend/storage/file/fd.c
taken from 9.2beta1.
This patch is submitted for review and comments, not
for application to the code base. *WIP*
This patch addresses a performance problem stemming
from the use of FindFirstFile() and FindNextFile() to
iterate over a
On Tue, May 29, 2012 at 04:10:41PM -0400, Tom Lane wrote:
Hmmm ... that is a good point; right now, there are probably still an
awful lot of installations that have PL languages installed bare
rather than wrapped in an extension, including all the ones where the
plpython library has the old
Mark Dilger markdil...@yahoo.com writes:
4) Other places in the PostgreSQL sources where directory
iteration is needed should probably use a pattern if possible
when running on Windows. Thus, it might make more
sense to have a version of ReadDir that explicitly takes a
pattern, and use that
Bruce Momjian br...@momjian.us writes:
The bottom line is that already needed function shared objects checking,
so we just wrapped languages into that as well.
Well, that'd be fine if it actually *worked*, but as per this
discussion, it doesn't work; you have to kluge around the fact that
the
On Tue, May 29, 2012 at 05:35:18PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
The bottom line is that already needed function shared objects checking,
so we just wrapped languages into that as well.
Well, that'd be fine if it actually *worked*, but as per this
Andrew Dunstan and...@dunslane.net writes:
Martin Pitt mp...@debian.org mailto:mp...@debian.org writes:
while packaging 9.2 beta 1 for Debian/Ubuntu the postgresql-common
test suite noticed a regression: It seems that pg_restore --data-only
now skips the current value of sequences, so that in
I am hesitant to write a function like AllocateDirWithFilePattern
if the pattern is simply ignored on non-Windows. In my patch,
the pattern underspecified the files, and the ad-hoc matching code
applied to all the returned files tightened that up. But a person
could just as well overspecify the
Mark Dilger markdil...@yahoo.com writes:
I am hesitant to write a function like AllocateDirWithFilePattern
if the pattern is simply ignored on non-Windows. In my patch,
the pattern underspecified the files, and the ad-hoc matching code
applied to all the returned files tightened that up. But
On Mon, 2012-05-28 at 16:06 -0400, Robert Haas wrote:
On Sun, May 27, 2012 at 11:31 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't recall exactly what problems drove us to make pg_upgrade do
what it does with extensions, but we need a different fix for them.
Well, you need pg_upgrade to
I was imagining that this would be a trap for linux developers
who saw nothing wrong with their code until it made it to the
build/test farm. That's pretty far down the development
process. Of course, it is also a trap in the other direction, for
Windows developers who use the pattern but do not
Jeff Davis pg...@j-davis.com writes:
Also, I think it needs to force the extension version to match the old
cluster. Otherwise, we could be dealing with on-disk format changes, or
other complexities.
Yeah, I was thinking we might want --binary-upgrade to specify a
particular extension version
On 5/29/12 2:46 PM, james wrote:
How easy would it be to implement a fake async rep target?
Perhaps even as something that a server could allow a connection to request?
(ie a suitably permissioned connection could convert itself to receive n async
replication stream, rather than being
On 28.5.2012 23:20, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
I'm writing my first FDW, and I need to get the list of columns I
actually need to fetch when planning the query. I do want to fetch only
the columns that are actually needed, not all of them.
reltargetlist and
On Tue, 2012-05-22 at 10:24 -0700, Jeff Janes wrote:
Now that there are index only scans, there is a use case for having a
composite index which has the primary key or a unique key as the
prefix column(s) but with extra columns after that. Currently you
would also need another index with
On 5/18/12 2:06 AM, Miroslav Šimulčík wrote:
- no data redundancy - in my extension current versions of entries are stored
only once in original table (in table_log - entries are inserted to both
original and log table)
That's not necessarily a benefit... it makes querying for both history
I ran a SELECT-only pgbench test today on the IBM POWER7 box with 64
concurrent clients and got roughly 305,000 tps. Then, I created a
hash index on pgbench_accounts (aid), dropped the primary key, and
reran the test. I got roughly 104,000 tps. 'perf -g -e cs' suggested
lock contention in
Hello,
I was running some tests on PG9.2beta where I'm creating and dropping
large number of tables (~ 2).
And I noticed that table dropping was extremely slow -- e.g. like half a
second per table.
I tried to move the table dropping into bigger transactions (100 per one
transaction)
On 29 May 2012 17:58, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 29, 2012 at 12:47 PM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
Why do you think that doing this for all XLogFlush() callsites might
be problematic?
Well, consider the one in the background writer, for example.
On Tue, May 29, 2012 at 5:19 PM, Robert Haas robertmh...@gmail.com wrote:
I ran a SELECT-only pgbench test today on the IBM POWER7 box with 64
concurrent clients and got roughly 305,000 tps. Then, I created a
hash index on pgbench_accounts (aid), dropped the primary key, and
reran the test.
On Tue, May 29, 2012 at 11:21 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Tue, May 29, 2012 at 5:19 PM, Robert Haas robertmh...@gmail.com wrote:
I ran a SELECT-only pgbench test today on the IBM POWER7 box with 64
concurrent clients and got roughly 305,000 tps. Then, I created a
hash index
Tomas Vondra t...@fuzzy.cz writes:
Do I need to return only the data in rel-reltargetlist, or should I
return all the columns (including those in rel-baserestrictinfo)?
Because AFAIK PostgreSQL will recheck the conditions on the data
returned from FDW and if I only return the attributes from
Robert Haas robertmh...@gmail.com writes:
On Tue, May 29, 2012 at 11:21 PM, Jeff Janes jeff.ja...@gmail.com wrote:
2) Only support bitmap scans and not ordinary tid scans (the way gin
indexes already do).
-1 on losing amgettuple. I regret that we lost that for GIN and I
shall regret it more
I have seen this with git master head:
$ pg_dump test
:
:
:
COPY insert_lock (reloid) FROM stdin;
pg_dump: [archiver] internal error -- WriteData cannot be called outside the
context of a DataDumper routine
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Tatsuo Ishii is...@postgresql.org writes:
I have seen this with git master head:
$ pg_dump test
:
:
:
COPY insert_lock (reloid) FROM stdin;
pg_dump: [archiver] internal error -- WriteData cannot be called outside the
context of a DataDumper routine
hm, it works for me. You might need to
hm, it works for me. You might need to do make clean all in
src/bin/pg_dump?
Sorry for noise. It worked. Thanks!
--
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
74 matches
Mail list logo
