Andrew Dunstan wrote:
>
>
> Alvaro Herrera wrote:
> > Andrew Dunstan wrote:
> >
> >> I'm confused. There is a Cygwin member of buildfarm, working quite
> >> happily. Can you point me to the exact patch in question, please? I
> >> thought we resolved the matter of stat() ages ago.
> >>
Tom Lane wrote:
> KaiGai Kohei writes:
>> Bruce Momjian wrote:
>>> 1034 and 25 are the oids for 'acllist' and 'text' and they are being
>>> added to system tables. Are you saying system tables don't use
>>> pg_security but other tables do?
>
>> It means users can refer the "security_acl" and "se
On Mon, Dec 8, 2008 at 4:34 PM, Tom Lane wrote:
> "Mark Wong" writes:
>> On Tue, Dec 2, 2008 at 2:25 AM, Tom Lane wrote:
>>> Are any of the queries complicated enough to trigger GEQO planning?
>
>> Is there a debug option that we could use to see?
>
> Well, you could set geqo=off and see if the
On Thu, Dec 18, 2008 at 11:54 PM, Tom Lane wrote:
> "Rushabh Lathia" writes:
> > Another issue found on CVS head
> > ...
> > postgres=> select f_test(10);
> > ERROR: cache lookup failed for type 2139062142
>
> I had some difficulty reproducing this locally. Would you check it's
> fixed by
Alvaro Herrera wrote:
Andrew Dunstan wrote:
I'm confused. There is a Cygwin member of buildfarm, working quite
happily. Can you point me to the exact patch in question, please? I
thought we resolved the matter of stat() ages ago.
http://archives.postgresql.org/message-id/4865F707.
Andrew Dunstan wrote:
>
> I'm confused. There is a Cygwin member of buildfarm, working quite
> happily. Can you point me to the exact patch in question, please? I
> thought we resolved the matter of stat() ages ago.
http://archives.postgresql.org/message-id/4865F707.6010702%40x-ray.at
--
Alv
I'm confused. There is a Cygwin member of buildfarm, working quite
happily. Can you point me to the exact patch in question, please? I
thought we resolved the matter of stat() ages ago.
cheers
andrew
Bruce Momjian wrote:
If we have no plan to apply this patch, do we need to remove Cygwin a
If we have no plan to apply this patch, do we need to remove Cygwin as a
supported platform?
---
Bruce Momjian wrote:
>
> Where are we on this? The patch was not acceptable for several reasons;
> for one:
>
> > And finall
KaiGai Kohei writes:
> Bruce Momjian wrote:
>> 1034 and 25 are the oids for 'acllist' and 'text' and they are being
>> added to system tables. Are you saying system tables don't use
>> pg_security but other tables do?
> It means users can refer the "security_acl" and "security_label",
> as if th
Hi,
On Thu, Dec 18, 2008 at 6:35 PM, Simon Riggs wrote:
>
> On Thu, 2008-12-18 at 12:08 +0900, Fujii Masao wrote:
>
>> >> Agreed, I also think that hard code is better. But I'm nervous that "off"
>> >> keeps us waiting for replication in cases other than DDL, e.g. flush
>> >> buffer, truncate clo
Wow, you are really shooting out a lot of good stuff today!
---
Simon Riggs wrote:
>
> Latest version of rmgr hooks patch for later review in current
> commitfest.
>
> (Minor update to CVS HEAD).
>
> --
> Simon Riggs
Ah, very interesting. Thanks.
---
KaiGai Kohei wrote:
> > 1034 and 25 are the oids for 'acllist' and 'text' and they are being
> > added to system tables. Are you saying system tables don't use
> > pg_security but other ta
Tom Lane wrote:
> So to summarize what I think we agreed to yesterday:
>
> * CREATE OR REPLACE FUNCTION has to prevent reducing the pronargdefaults
> value of an existing function (ie, you can add more defaults but not
> remove any). This ensures a function that matched a given call before
> will
Bruce Momjian wrote:
KaiGai Kohei wrote:
Bruce Momjian wrote:
KaiGai Kohei wrote:
- Two new system columns ("security_acl" and "security_label") are added.
The first one is for the Row-level ACLs, and the other is for the guest
of PGACE security framework which is chosen by user.
This is
KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > KaiGai Kohei wrote:
> >> - Two new system columns ("security_acl" and "security_label") are added.
> >> The first one is for the Row-level ACLs, and the other is for the guest
> >> of PGACE security framework which is chosen by user.
> >
> > This
>>> Gregory Stark wrote:
> Grzegorz Jaskiewicz writes:
>
>> all I know, is that the same query will work on 8.3 in reasonably
> acceptable
>> time frame.
>>
>
> Because I see the exact same plan -- in fact with the exact same
cost:
>
>
> Welcome to psql 8.3.3, the PostgreSQL interactive te
Bruce Momjian wrote:
KaiGai Kohei wrote:
- Two new system columns ("security_acl" and "security_label") are added.
The first one is for the Row-level ACLs, and the other is for the guest
of PGACE security framework which is chosen by user.
This is certainly an impressive patch. I see you
Grzegorz Jaskiewicz writes:
> all I know, is that the same query will work on 8.3 in reasonably acceptable
> time frame.
>
Because I see the exact same plan -- in fact with the exact same cost:
Welcome to psql 8.3.3, the PostgreSQL interactive terminal.
Type: \copyright for distribution ter
Kevin Grittner wrote:
> >>> Bruce Momjian wrote:
> > Kevin Grittner wrote:
> >> Did you mean to say that journaled file systems are *not*
> necessary?
> >
> > Yes, not needed for database reliablity. The patch text was
> attached;
> > was it unclear?
>
> I think you accidentally left out the
>>> Bruce Momjian wrote:
> Kevin Grittner wrote:
>> Did you mean to say that journaled file systems are *not*
necessary?
>
> Yes, not needed for database reliablity. The patch text was
attached;
> was it unclear?
I think you accidentally left out the word "not".
-Kevin
--
Sent via pgsql-h
Kevin Grittner wrote:
> >>> Bruce Momjian wrote:
> > Tatsuo Ishii wrote:
> >> In your document change which one can be placed on non-journalling
> >> file system? data? wal? or both?
> >
> > Both. I have updated the docs to mention this, patch attached.
>
> Did you mean to say that journaled f
Grzegorz Jaskiewicz writes:
> all I know, is that the same query will work on 8.3 in reasonably acceptable
> time frame.
What plan do you get in 8.3?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!
--
Sent via p
>>> Bruce Momjian wrote:
> Tatsuo Ishii wrote:
>> In your document change which one can be placed on non-journalling
>> file system? data? wal? or both?
>
> Both. I have updated the docs to mention this, patch attached.
Did you mean to say that journaled file systems are *not* necessary?
-Ke
Tatsuo Ishii wrote:
> Bruce,
>
> In your document change which one can be placed on non-journalling
> file system? data? wal? or both?
Both. I have updated the docs to mention this, patch attached.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://e
all I know, is that the same query will work on 8.3 in reasonably
acceptable time frame.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, 2008-12-17 at 19:03 -0800, Unicron wrote:
> I created a function for testing the patch, but when i run following
> command, the function always raise an exception
>
> select test_in_params('first');
> ERROR: plpython: function "test_in_params" failed
> DETAIL: exceptions.NameError: glob
Oops, forgot to cc my reply to hackers:
On Thu, 2008-12-18 at 01:49 +0200, Marko Kreen wrote:
> On 12/16/08, Bruce Momjian wrote:
> > Would someone who understand pgcrypto please review this?
>
> > Marc Munro wrote:
> > > I am attaching a patch to eliminate duplicate b64_encode and decode
> >
Alvaro Herrera writes:
> Tom Lane escribió:
>> This is actually in direct contradiction to the original intent of the
>> plugins/ subdirectory, which was that it only contain libraries that the
>> local administrator had decided to consider safe and put there manually.
> I think this is fantasy -
Tom Lane escribió:
> AFAICT, the idea of this patch is to make shared libraries that
> automatically install in $libdir/plugins/ rather than $libdir/.
>
> This is actually in direct contradiction to the original intent of the
> plugins/ subdirectory, which was that it only contain libraries that
>
> This is fixed in my recent commit --- the ambiguous-function error won't
> occur unless the ambiguous functions represent the best match to the
> actual arguments.
>
>regards, tom lane
>
I did some fast test, and now, it is well, so thank you
regards
Pavel Stehule
> -
MUHAMMAD ASIF writes:
> Purpose of this Plugins change is to add support in postgresql source
> to build plugin and install in (install dir)/lib/plugins. We made
> these changes for a plugin module i.e. pldebugger and we found this a
> useful feature that can help postgresql in adding plugins easi
Gregory Stark writes:
> Tom Lane writes:
>> Yeah. NOT IN does not have the right semantics to become an antijoin.
> If we noticed that the columns in the subquery are all guaranteed to be not
> null could we do it then?
I think you'd also have to know that the outer-query value isn't null,
plu
"Anupama Aherrao" writes:
> Following INSERT..SELECT with GENERATE_SERIES for bulk insertion returns
> error on 8.4 cvs head. It looks like an issue.
Yeah, looks like I broke this here:
http://archives.postgresql.org/pgsql-committers/2008-10/msg00295.php
Fixed, thanks for the report!
Tom Lane writes:
> Gregory Stark writes:
>> I think Postgres can't do better because there could be a NULL in the
>> subquery. If there's a NULL in the subquery then no record would match.
>
> Yeah. NOT IN does not have the right semantics to become an antijoin.
If we noticed that the columns
Gregory Stark writes:
> I think Postgres can't do better because there could be a NULL in the
> subquery. If there's a NULL in the subquery then no record would match.
Yeah. NOT IN does not have the right semantics to become an antijoin.
FWIW, you can use a NOT EXISTS:
select a.a from a where
On Tue, 2008-11-18 at 15:04 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > heap_inplace_fetch takes as input "tuple" which is a palloc'd tuple,
> > extracts from it the tid of the tuple, reads the buffer, locks it, then
> > releases the original tuple. It then returns a copy of the on-block
> >
"Rushabh Lathia" writes:
> Another issue found on CVS head
> ...
> postgres=> select f_test(10);
> ERROR: cache lookup failed for type 2139062142
I had some difficulty reproducing this locally. Would you check it's
fixed by latest commit?
regards, tom lane
--
Sen
"Rushabh Lathia" writes:
>CREATE OR REPLACE FUNCTION f007( a INTEGER,
> b INTEGER DEFAULT 10 ) RETURNS INTEGER
>AS $$
>select 10;
>$$ language sql;
>CREATE OR REPLACE FUNCTION f007( a INTEGER DEFAULT 10,
> b INTEGER DEFAULT 10,
> c INTEG
On Wed, 2008-12-17 at 15:21 +, Simon Riggs wrote:
> http://wiki.postgresql.org/wiki/Hot_Standby
>
> now contains a link to latest version of this patch. This is still at
> "v5", just brought forward to CVS HEAD.
>
> I will be doing further work on the patch from here and will reply to
> this
Grzegorz Jaskiewicz writes:
> gj=# explain select a.a from a where a not in (select a from b);
>QUERY PLAN
> -
> Seq Scan on a (cost=99035.00..257874197565.00 rows=300 width=4)
>Filte
KaiGai Kohei wrote:
> - Two new system columns ("security_acl" and "security_label") are added.
> The first one is for the Row-level ACLs, and the other is for the guest
> of PGACE security framework which is chosen by user.
This is certainly an impressive patch. I see you went with storing t
create table a(a int not null);
insert into a(a) select generate_series(1,600);
create table b as select * from a where a%10 <> 0;
create index fooa on a(a);
alter table b alter column a set not null;
create index foob on b(a);
vacuum analyze verbose;
gj=# explain select a.a from a where a
On Thu, 2008-12-18 at 15:13 +0200, Heikki Linnakangas wrote:
> Can't we use the existing backendid in place of the slot id?
>
> (sorry if this has been discussed already; can't remember)
Exactly the sort of question we need, but unfortunately I'm a little
hazy, but I just woke up some maybe som
> "Andrew" == Andrew Gierth writes:
Andrew> I get a segfault too if I force misc/ossp-uuid to build with
Andrew> -fPIC:
[...]
Andrew> I can try this on another box with a debug-enabled pg build
Andrew> later.
The problem, unsurprisingly, is that the call to uuid_create in
contrib/uuid-o
Peter Eisentraut writes:
> Greg Stark wrote:
>> It would be perfectly reasonable to add an amisrecoverable like Simon
>> described. It could automatically set indisvalid to false after a crash
>> and treat the index as if indisvalid is false during recovery. That
>> would be a lot smoother and
Greg Stark wrote:
It would be perfectly reasonable to add an amisrecoverable like Simon
described. It could automatically set indisvalid to false after a crash
and treat the index as if indisvalid is false during recovery. That
would be a lot smoother and safer than what we have now.
It might
Peter Eisentraut writes:
> Tom Lane wrote:
>> This case *must* work:
>>
>> create function foo (f1 int)
>> create function foo (f1 int, f2 int = 42)
>>
>> select foo(10)
> I tried out C++, and it rejects this case:
> ...
> So, I'd rather reject the foo(10) call. The least-defaults rule doesn't
"Fujii Masao" writes:
> On Thu, Dec 18, 2008 at 4:49 AM, Robert Lor wrote:
>> My understanding is that we only want to track the XLogWrite when advancing
>> to the next buffer page, and if there is unwritten data in the new buffer
>> page, that indicates no more empty WAL buffer pages available,
Hi all,
I did not find the option to remove the page so I just left the links
section. Feel free to remove the page so that there is no trace left of
this in the history. I don't think it is worth keeping anything since no
one found value in it anyway.
Until I figure out a way to come up with
It would be perfectly reasonable to add an amisrecoverable like Simon
described. It could automatically set indisvalid to false after a
crash and treat the index as if indisvalid is false during recovery.
That would be a lot smoother and safer than what we have now.
It might even be possibl
> "Peter" == Peter Eisentraut writes:
> Andrew Gierth wrote:
>> Has anyone ever managed to get uuid generation working on FreeBSD?
>> There seems to be no way to build contrib/uuid-ossp successfully,
>> and no apparent agreement anywhere as to whether this is problem
>> with pg or with t
Can't we use the existing backendid in place of the slot id?
(sorry if this has been discussed already; can't remember)
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
Pavan Deolasee wrote:
BTW, if there is no proven case where hash index works significantly
better than btree (that's what the doc says), why not just completely
abandon it ?
That has been considered many times, see archives. I believe the changes
done in 8.4 actually made it faster for some ca
On Thu, Dec 18, 2008 at 6:02 PM, Heikki Linnakangas
wrote:
>
> In short, don't use hash index, unless you're prepared to run REINDEX
> manually after every crash.
>
I think that should be mentioned in *bold* letters in the
documentation. The doc currently has the following: "so hash indexes
migh
Pavan Deolasee wrote:
Just curious, how do we handle the case of corrupted hash index today?
We don't.
If we can detect that the index is corrupt because of bad page
headers etc, then its still OK; we can throw an error. But what if the
hash index is used after recovery and it returns wrong t
On Thu, Dec 18, 2008 at 11:59 AM, Heikki Linnakangas
wrote:
>
> Right, this is certainly not a new problem. It's not even a new problem in
> the context of replication or hot standby, because we already have the
> problem with PITR and file-based log shipping.
>
> Also, it's not just a problem *d
On Thu, 2008-12-18 at 13:52 +0200, Peter Eisentraut wrote:
> Simon Riggs wrote:
> >> I think we should just leave it alone for 8.4, and fix it properly in a
> >> future relase by implementing WAL-logging for hash indexes.
> >
> > You really think we should just leave it alone? That gives me less
On Thu, Dec 18, 2008 at 5:14 PM, Anupama Aherrao <
anupama.aher...@enterprisedb.com> wrote:
> Hi All,
>
> Following INSERT..SELECT with GENERATE_SERIES for bulk insertion returns
> error on 8.4 cvs head. It looks like an issue.
>
> Tested on : *8.4 CVS Head*
>
> CREATE TABLE t1 ( x int, y char(4
Simon Riggs wrote:
I think we should just leave it alone for 8.4, and fix it properly in a
future relase by implementing WAL-logging for hash indexes.
You really think we should just leave it alone? That gives me less work,
so I will accept that if you think so. Gives me the shivers though.
A
Hi All,
Following INSERT..SELECT with GENERATE_SERIES for bulk insertion returns
error on 8.4 cvs head. It looks like an issue.
Tested on : *8.4 CVS Head*
CREATE TABLE t1 ( x int, y char(4));
INSERT INTO t1 VALUES ( 1, 'edb');
INSERT INTO t1 SELECT 10 + GENERATE_SERIES(50,60), y FROM t1 WHE
> Approximately 50% of the Wiki entry is *exactly* the same as the
> document I wrote. Yes, the Wiki may one day become a collective work,
> but currently the following Wiki entry is fairly obviously not a
> collective work.
> http://wiki.postgresql.org/wiki/Table_partitioning
[...]
> Your attitude
>> I am not a fan of the proposed syntax. It is conceptually similar to
>> what we already do with constraints, but invents a whole new syntax to
>> no obvious benefit that I can see.
>
> Actually I did not invent a new syntax but tried to map the Oracle syntax
> which seems to be a requirement th
Peter Eisentraut wrote:
Heikki Linnakangas wrote:
I think we need a threshold similar to autovacuum_freeze_max_age for
manual vacuums as well: vacuum_freeze_max_age. If you run VACUUM, and
relfrozenxid is older than vacuum_freeze_max_age, the visibility map
is ignored and all pages are scanned
Heikki Linnakangas wrote:
I think we need a threshold similar to autovacuum_freeze_max_age for
manual vacuums as well: vacuum_freeze_max_age. If you run VACUUM, and
relfrozenxid is older than vacuum_freeze_max_age, the visibility map is
ignored and all pages are scanned.
Would one parameter t
Andrew Gierth wrote:
Has anyone ever managed to get uuid generation working on FreeBSD?
There seems to be no way to build contrib/uuid-ossp successfully,
and no apparent agreement anywhere as to whether this is problem
with pg or with the misc/ossp-uuid port.
So what's the problem? Error messa
Gregory Stark wrote:
Well honestly I don't see a terribly compelling use case for default arguments
altogether. Obviously they're just a programmer convenience and don't really
let anyone do anything they couldn't do without them.
The real payoff comes with name-based paramter lists (the name =
Tom Lane wrote:
This case *must* work:
create function foo (f1 int)
create function foo (f1 int, f2 int = 42)
select foo(10)
and it seems like just an arbitrary exception if you don't have a rule
about preferring fewer defaults over more.
I tried out C++, and it rejec
Tom Lane wrote:
Yeah, I don't like putting extra restrictions on the polymorphic case
either. Also, see my nearby note about how letting fewer defaults win
over more defaults might be unsafe. Consider
foo (f1 int)
foo (f1 int, f2 variadic int[])
If the system allows f2 to be d
On Thu, 2008-12-18 at 08:29 +0200, Heikki Linnakangas wrote:
> Right, this is certainly not a new problem. It's not even a new problem
> in the context of replication or hot standby, because we already have
> the problem with PITR and file-based log shipping.
>
> Also, it's not just a problem
On Thu, 2008-12-18 at 12:08 +0900, Fujii Masao wrote:
> >> Agreed, I also think that hard code is better. But I'm nervous that "off"
> >> keeps us waiting for replication in cases other than DDL, e.g. flush
> >> buffer, truncate clog, checkpoint.. etc. synchronous_replication = off
> >> is quite
On Thu, 2008-12-18 at 14:30 +0900, ITAGAKI Takahiro wrote:
> Simon Riggs wrote:
>
> > Latest version of rmgr hooks patch for later review in current
> > commitfest.
> > (Minor update to CVS HEAD).
>
> It doesn't work on Window (EXEC_BACKEND platform) because
> shared_preload_libraries are not l
On Thu, 2008-12-18 at 00:00 -0500, Emmanuel Cecchet wrote:
> > At the moment, all you've done is show examples of how Oracle does
> > partitioning and restate my requirements document, significant chunks
> > completely verbatim. If you do that I think it fair to ask for a
> > specific credit on t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 18 déc. 08 à 00:56, Tom Lane a écrit :
"Pavel Stehule" writes:
do you remember on request for using "default" keyword in funccall?
This should be solution. In view, you don't store select foo(11), but
you have to store select foo(11, defau
73 matches
Mail list logo
