> 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 (pgsql-hackers@postgr
Tatsuo Ishii 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 do "make cle
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
Japanese
Robert Haas writes:
> On Tue, May 29, 2012 at 11:21 PM, Jeff Janes 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 if we lose it anywhere else.
Not
Tomas Vondra 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 the
> re
On Tue, May 29, 2012 at 11:21 PM, Jeff Janes wrote:
> On Tue, May 29, 2012 at 5:19 PM, Robert Haas 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
On Tue, May 29, 2012 at 5:19 PM, Robert Haas 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. I got roughly 104,
On 29 May 2012 17:58, Robert Haas wrote:
> On Tue, May 29, 2012 at 12:47 PM, Peter Geoghegan
> 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
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) (i
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 _hash_f
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 *a
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 e
On 28.5.2012 23:20, Tom Lane wrote:
> Tomas Vondra 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 attr_needed on
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 statical
Jeff Davis 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 in CREATE EXTEN
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
On Mon, 2012-05-28 at 16:06 -0400, Robert Haas wrote:
> On Sun, May 27, 2012 at 11:31 AM, 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.
>
> Well, you need pg_upgrade to preserve the O
Mark Dilger 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 a person
> could
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 p
Andrew Dunstan writes:
>>> Martin Pitt 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 the upgraded
da
On Tue, May 29, 2012 at 05:35:18PM -0400, Tom Lane wrote:
> Bruce Momjian 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 doe
Bruce Momjian 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 shared library n
Mark Dilger 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 version of ReadD
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 o
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 direct
On Wed, May 30, 2012 at 12:25 AM, Tom Lane wrote:
> Alexander Korotkov writes:
> > On Tue, May 29, 2012 at 11:42 PM, Tom Lane wrote:
> >> While I'm looking at this, is the first test involving
> >> effective_cache_size bulletproof either? In particular, is
> >> avgIndexTuplesPerPage clamped to
On Tue, May 29, 2012 at 8:51 PM, Fujii Masao wrote:
> On Wed, May 30, 2012 at 2:03 AM, Robert Haas wrote:
>> On Mon, May 28, 2012 at 4:38 PM, Magnus Hagander wrote:
>>> On Mon, May 28, 2012 at 10:11 PM, Peter Eisentraut wrote:
In 9.1, the pg_basebackup option --xlog takes no argument. In
Alexander Korotkov writes:
> On Tue, May 29, 2012 at 11:42 PM, Tom Lane 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 statis
On Tue, May 29, 2012 at 11:42 PM, Tom Lane 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 inserted tuple
Bruce Momjian 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 pursue, but
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 it
Heikki Linnakangas 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) < effective_cache_size / 4
>> &&
>> /* each
On Tue, May 29, 2012 at 02:38:03PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, May 29, 2012 at 01:46:28PM -0400, Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> In fact, can we identify right now if a function is used only by an
> >>> extension?
>
> >> ITYM is the function define
On 24 May 2012 21:11, Robert Haas wrote:
> On Thu, May 24, 2012 at 2:52 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Wed, May 23, 2012 at 2:28 PM, Fujii Masao wrote:
Is there plan to implement such external functions before 9.2 release?
If not, keepalive protocol seems to be almo
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 (fillfact
Peter Eisentraut 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 leave it alo
On Fri, May 25, 2012 at 4:06 PM, Jeff Janes 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 condition, shouldn't it u
On Wed, May 30, 2012 at 2:03 AM, Robert Haas wrote:
> On Mon, May 28, 2012 at 4:38 PM, Magnus Hagander wrote:
>> On Mon, May 28, 2012 at 10:11 PM, Peter Eisentraut wrote:
>>> In 9.1, the pg_basebackup option --xlog takes no argument. In 9.2, it
>>> takes a required argument. I think such compa
Hi,
On Monday, May 28, 2012 07:11:53 PM Tom Lane wrote:
> Andres Freund 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 a critical se
Bruce Momjian writes:
> On Tue, May 29, 2012 at 01:46:28PM -0400, Tom Lane wrote:
>> Bruce Momjian 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 in pg_depend".
>
Robert Haas writes:
> On Tue, May 29, 2012 at 9:04 AM, Johann 'Myrkraverk' Oskarsson
> 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
> question is: why is MinGW doing that?
On Tue, May 29, 2012 at 01:46:28PM -0400, Tom Lane wrote:
> Bruce Momjian 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 s
Bruce Momjian 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 file being prese
Robert Haas 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 definitions of the i
On Mon, May 28, 2012 at 4:38 PM, Magnus Hagander wrote:
> On Mon, May 28, 2012 at 10:11 PM, Peter Eisentraut 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
>> avoided, especially in client
On Tue, May 29, 2012 at 12:47 PM, Peter Geoghegan 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 acquire the
lock and then
On Tue, May 29, 2012 at 12:35 PM, Tom Lane wrote:
> Robert Haas 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
>> execut
On 29 May 2012 17:10, Robert Haas 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 commit-delay sleep is permis
On Tue, May 29, 2012 at 9:04 AM, Johann 'Myrkraverk' Oskarsson
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 not directly rel
Robert Haas 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 (correctly) we then proc
On Mon, May 28, 2012 at 6:37 PM, Tom Lane wrote:
> Marti Raudsepp writes:
>> On Mon, May 28, 2012 at 11:23 PM, Tom Lane wrote:
>>> However, the error in your original example is far too large to be
>>> explained by that, so I think it was tripping over something different.
>
>> Good point. But I
On Mon, May 28, 2012 at 9:18 PM, 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.
This is a clever idea, but I think it needs some fi
On Mon, May 28, 2012 at 8:15 AM, Waldecir Faria 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 suggested me
> to take a
On May29, 2012, at 16:57 , Kohei KaiGai wrote:
> 2012/5/29 Robert Haas :
>> 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 b
On Tue, May 29, 2012 at 10:57 AM, Kohei KaiGai wrote:
> 2012/5/29 Robert Haas :
>> 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
>
On Fri, May 25, 2012 at 5:08 PM, Kohei KaiGai 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 random war
2012/5/29 Robert Haas :
> 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 not what we really
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 (proba
On Tue, May 29, 2012 at 9:12 AM, Florian Pflug wrote:
> On May29, 2012, at 13:37 , Kohei KaiGai wrote:
>> 2012/5/27 Alastair Turner :
>>> Excerpts from Kohei KaiGai 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
2012/5/29 Florian Pflug :
> On May29, 2012, at 13:37 , Kohei KaiGai wrote:
>> 2012/5/27 Alastair Turner :
>>> Excerpts from Kohei KaiGai 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()
alw
On Sun, May 27, 2012 at 02:32:52PM -0400, Tom Lane wrote:
> Andrew Dunstan 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 exactly what wil
On May29, 2012, at 16:13 , Kohei KaiGai wrote:
> 2012/5/29 Florian Pflug :
>> 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 it i
On Sun, May 27, 2012 at 02:39:28PM -0400, Tom Lane wrote:
> Bruce Momjian 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.
>
> > U
2012/5/29 Florian Pflug :
> On May29, 2012, at 13:59 , Kohei KaiGai wrote:
>> 2012/5/28 Florian Pflug :
>>> 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
On May29, 2012, at 13:37 , Kohei KaiGai wrote:
> 2012/5/27 Alastair Turner :
>> Excerpts from Kohei KaiGai 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 unpriv
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:59 , Kohei KaiGai wrote:
> 2012/5/28 Florian Pflug :
>> 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 compatib
On 29 May 2012 07:16, Heikki Linnakangas
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 of course mean a commit_dela
2012/5/28 Florian Pflug :
> 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
>>> SQL-le
2012/5/27 Alastair Turner :
> Excerpts from Kohei KaiGai 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
>> execution of queries.
>> Isn
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
Tom Lane 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 search path.
It s
On Tue, May 29, 2012 at 1:37 AM, Tom Lane 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 your subscription:
73 matches
Mail list logo
