Hi,
On Wednesday 15 July 2009 04:14:16 Robert Haas wrote:
On Tue, Jul 14, 2009 at 6:34 PM, Andres Freundand...@anarazel.de wrote:
---
doc/src/sgml/config.sgml | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/doc/src/sgml/config.sgml
Jeff Davis pg...@j-davis.com writes:
So, should we proceed assuming an index AM API change, or try to avoid
it? If we should change the AM API, is Dean's API change acceptable?
There is no reason at all to avoid an index AM API change if one is
useful. If you look at the history, we tend to
On Wednesday 15 July 2009 03:18:03 Robert Haas wrote:
The time is now Wed Jul 15 00:18:00 UTC 2009 and CommitFest 2009-07 is
now closed.
I don't know about others, but I find this terminology confusing. The
progression should be:
(Not accepting submissions) - Accepting submissions - In
Before i duplicate work does anyone have a MySQL.whynot or Postgres
versus MySQL comparison table?
--
greg
http://mit.edu/~gsstark/resume.pdf
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Wed, Jul 15, 2009 at 10:03:20AM +0300, Peter Eisentraut wrote:
On Wednesday 15 July 2009 03:18:03 Robert Haas wrote:
The time is now Wed Jul 15 00:18:00 UTC 2009 and CommitFest 2009-07 is
now closed.
I don't know about others, but I find this terminology confusing. The
progression
On Wed, 2009-07-15 at 08:20 +0100, Greg Stark wrote:
Before i duplicate work does anyone have a MySQL.whynot or Postgres
versus MySQL comparison table?
http://wiki.postgresql.org/wiki/Why_PostgreSQL_Instead_of_MySQL_2009
That isn't exactly a table, but it may be helpful.
Regards,
Greg Stark wrote:
Before i duplicate work does anyone have a MySQL.whynot or Postgres
versus MySQL comparison table?
Like f.ex
http://wiki.postgresql.org/wiki/Why_PostgreSQL_Instead_of_MySQL_2009 ?
--
Tommy Gildseth
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Greg Stark wrote:
Before i duplicate work does anyone have a MySQL.whynot or Postgres
versus MySQL comparison table?
http://sql-info.de/
not so up-to-date still it contanins some kind
of comparisons... between mysql and postgresql
andrea
--
Sent via pgsql-hackers mailing list
Hello,
Alvaro Herrera alvhe...@commandprompt.com wrote:
Tsutomu Yamada wrote:
This patch using VirtualAlloc()/VirtualFree() to avoid failing in
reattach to shared memory.
Can this be added to CommitFest ?
Since this fixes a very annoying bug present in older versions, I
On Wednesday 15 July 2009 02:27:32 Richard Huxton wrote:
Andrew Dunstan wrote:
Richard Huxton wrote:
Andrew Dunstan wrote:
Yes, really. What you suggest here is just not adequate, IMNSHO. I
don't want to have to scroll to the top or bottom of the page to get
navigation, and I want to be
On Jul 15, 2009, at 3:11 AM, Kristian Larsson
krist...@spritelink.net wrote:
On Wed, Jul 15, 2009 at 10:03:20AM +0300, Peter Eisentraut wrote:
On Wednesday 15 July 2009 03:18:03 Robert Haas wrote:
The time is now Wed Jul 15 00:18:00 UTC 2009 and CommitFest
2009-07 is
now closed.
I don't
On Wed, Jul 15, 2009 at 12:32 AM, Fujii Masaomasao.fu...@gmail.com wrote:
If the above is OK, should I update the patch ASAP? or
suspend that update until many other comments arrive?
I'm concerned that frequent small updating interferes with
a review.
I decided (perhaps foolishly), to assign
Oleg Bartunov wrote:
Hi,
we'd like to introduce filtering dictionaries support for text search
and new contrib module unaccent, which provides useful example of
filtering dictionary. It finally solves the known problem of incorrect
generation of headlines of text with accents.
I'm
All,
For a very long time I have thought that it would be useful to have some
sort of navigation menu for the docs
Oh yes, pretty please :)
Navigating the docs requires far too much use of the back button and up
links, IMNSHO. A menu frame would make them far more usable.
No, please, no
On Wednesday 15 July 2009 10:50:03 Andrea Suisani wrote:
Greg Stark wrote:
Before i duplicate work does anyone have a MySQL.whynot or Postgres
versus MySQL comparison table?
http://sql-info.de/
not so up-to-date still it contanins some kind
of comparisons... between mysql and postgresql
Hello,
I did some test - median via window function - I found probably some
bad optimised code. I found two methods - Celko and Itzik Ben-Gan.
Ben-Gan methoud should to be faster - there is one sort less, but in
practice - it is 2 times slower.
create table x(a integer);
insert into x select
--On 15. Juli 2009 08:06:48 +0200 Andres Freund and...@anarazel.de wrote:
It should not create multiple threads I think as all messages were a
response the first mail?
It does (at least my MUA understood that correctly), but since many people
are reading in a backlog-style manner, i have
Andrew Dunstan wrote:
Wasn't that a big part of the point of the parallel pg_restore feature?
Well, yes, it's some of it, and in theory Tom's late addition of a queue
that gets all the dependencies of a table as soon as the table data is
restored should make that work better. But
Bruce Momjian br...@momjian.us writes:
Well, TODO has:
Allow multiple indexes to be created concurrently, ideally via a
single heap scan, and have pg_restore use it
Isn't this already largely done by parallel pg_restore work?
so we have to decide if we still want
Today on IRC, someone was wondering what the preferred method of
exporting data in a specific encoding via COPY was. They reply was
wrapping the COPY command in set client_encoding='foo';, which made
me wonder how hard it would be to add an additional WITH parameter to
the actual COPY statement to
Dne 14.07.09 04:37, Bruce Momjian napsal(a):
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tilmann Singer wrote:
However, all of the sequences were at the initial values and not
bumped up to the last used value as I would have expected. The first
nextval call on any
David Blewett da...@dawninglight.net writes:
Today on IRC, someone was wondering what the preferred method of
exporting data in a specific encoding via COPY was. They reply was
wrapping the COPY command in set client_encoding='foo';, which made
me wonder how hard it would be to add an
Zdenek Kotala zdenek.kot...@sun.com writes:
I think you don't need transfer sequence table, because pg_dump should
create DDL command (CREATE SEQUENCE) which should create new nice
sequence relation.
Yeah, but pg_dump is doing a schema-only dump so it doesn't transfer the
current state of
On Wed, Jul 15, 2009 at 12:04 PM, Tom Lanet...@sss.pgh.pa.us wrote:
What is the point? You'd generally have client_encoding set correctly
for your usage anyway, and if you did not, the data could confuse your
client-side code terribly. Offering an option to let the backend send
data in the
David Blewett da...@dawninglight.net writes:
On Wed, Jul 15, 2009 at 12:04 PM, Tom Lanet...@sss.pgh.pa.us wrote:
What is the point? You'd generally have client_encoding set correctly
for your usage anyway, and if you did not, the data could confuse your
client-side code terribly. Offering an
Tom Lane wrote:
Zdenek Kotala zdenek.kot...@sun.com writes:
I think you don't need transfer sequence table, because pg_dump should
create DDL command (CREATE SEQUENCE) which should create new nice
sequence relation.
Yeah, but pg_dump is doing a schema-only dump so it doesn't transfer
On Tue, 2009-07-14 at 21:12 -0400, Robert Haas wrote:
1. Downloaded norecoveryprocs-1.patch from
http://archives.postgresql.org/message-id/49a64d73.6090...@enterprisedb.com
http://archives.postgresql.org/message-id/4a4dbf8f.8040...@enterprisedb.com
I have to confess that I had no idea that
Jamie Fox wrote:
Hi -
REINDEX INDEX pg_largeobject_loid_pn_index;
This seems to have fixed the problem, lo_open of lob data is working again -
now to see how vacuumlo likes it.
So did it work?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL
On Wed, 15 Jul 2009, Greg Stark wrote:
Before i duplicate work does anyone have a MySQL.whynot or Postgres
versus MySQL comparison table?
http://dcdbappl1.cern.ch:8080/dcdb/archive/ttraczyk/db_compare/db_compare.html
http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL
On Wed, Jul 15, 2009 at 10:13 AM, Bernd Helmlemaili...@oopsware.de wrote:
--On 15. Juli 2009 08:06:48 +0200 Andres Freund and...@anarazel.de wrote:
It should not create multiple threads I think as all messages were a
response the first mail?
It does (at least my MUA understood that
On Wednesday 15 July 2009 19:01:05 Robert Haas wrote:
On Wed, Jul 15, 2009 at 10:13 AM, Bernd Helmlemaili...@oopsware.de wrote:
--On 15. Juli 2009 08:06:48 +0200 Andres Freund and...@anarazel.de
wrote:
It should not create multiple threads I think as all messages were a
response the first
David Blewett wrote:
Today on IRC, someone was wondering what the preferred method of
exporting data in a specific encoding via COPY was. They reply was
wrapping the COPY command in set client_encoding='foo';, which made
me wonder how hard it would be to add an additional WITH parameter to
the
Apologies to Tom for the duplicate...
On Wed, Jul 15, 2009 at 12:17 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Well, it might make sense to allow an ENCODING option attached to a COPY
with a file source/destination. I remain of the opinion that overriding
client_encoding on a transfer to/from the
--On 15. Juli 2009 19:59:56 +0300 Nagy Karoly Gabriel
nagy.kar...@expert-erp.net wrote:
I think that I was the one who wondered about that. Our use case is
related to moving data between different servers which have different
encodings. Ofcourse the encoding should be an option only when
David Blewett wrote:
On Wed, Jul 15, 2009 at 12:17 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Well, it might make sense to allow an ENCODING option attached to a COPY
with a file source/destination. I remain of the opinion that overriding
client_encoding on a transfer to/from the client is a
Hi all,
I'm new to the postgresql codebase, working on a patch to 8.3.7 to
allow enums to accept variable length values for David Andersen (see
http://archives.postgresql.org/pgsql-performance/2008-07/msg00226.php
for more details). The code I wrote compiles, but breaks in a few
places. For
Mike Wilson wrote:
Hi all,
I'm new to the postgresql codebase, working on a patch to 8.3.7 to
allow enums to accept variable length values for David Andersen (see
http://archives.postgresql.org/pgsql-performance/2008-07/msg00226.php
for more details). The code I wrote compiles, but breaks in
Looks like David is generating his database from CSVs nightly also he
is paying me to write this patch partly because he can't/doesn't want
to learn how to compile code. That being said thx for the suggestion,
I'll pass it along to him.
On Wed, Jul 15, 2009 at 12:56 PM, Andrew
I recently got a complaint from an OpenSuSE user, which had problems using
PostgreSQL 8.4 installed by a broken RPM from build service. The init
script used initdb --auth=ident sameuser accidentally, to initialize the
cluster (this seems to be the practice in older versions before, too). This
Hi,
Le 15 juil. 09 à 02:01, Glen Parker a écrit :
Sounds to me like another reason to separate index definition from
creation. If an index can be defined but not yet created or valid,
then you could imagine syntax like:
DEFINE INDEX blahblah1 ON mytable (some fields);
DEFINE INDEX
Hi!
Thanks for your answer. Here is my general reasoning: I was thinking
about a way to use the profiler to determine the resource profile even
of (maybe even short time) business transactions. I would like to leave
the technical focus (high CPU usage, high I/O rate, too many disk sorts,
...)
David Blewett da...@dawninglight.net writes:
On Wed, Jul 15, 2009 at 12:17 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Well, it might make sense to allow an ENCODING option attached to a COPY
with a file source/destination. I remain of the opinion that overriding
client_encoding on a transfer
On Wed, Jul 15, 2009 at 4:07 PM, Tom Lanet...@sss.pgh.pa.us wrote:
David Blewett da...@dawninglight.net writes:
On Wed, Jul 15, 2009 at 12:17 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Well, it might make sense to allow an ENCODING option attached to a COPY
with a file source/destination. I remain
Nagy Karoly Gabriel wrote:
David Blewett wrote:
Today on IRC, someone was wondering what the preferred method of
exporting data in a specific encoding via COPY was. They reply was
wrapping the COPY command in set client_encoding='foo';, which made
me wonder how hard it would be to add an
Fujii Masao wrote:
Hi,
On Wed, Jul 15, 2009 at 8:15 PM, Robert Haasrobertmh...@gmail.com wrote:
So I think you should update ASAP in this case.
I updated the patch as described in
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00865.php
All the other parts are still the same.
Worked great, vacuumlo finished, a vacuum -full finished amazingly quickly,
very exciting. We're pointing qa apps at it now for testing.
For some reason though, that index has to be rebuilt after running
pg_migrator.
I'll be testing on our 100GB+ prod copy shortly and will let you know if you
Em Thu, 02 Jul 2009 15:27:33 -0400
Tom Lane t...@sss.pgh.pa.us escreveu:
Peter Eisentraut pete...@gmx.net writes:
Looks good, but needs documentation and tab-complete.c updates, it
seems. And you should revisit this patch to make it consistent
with the S flag that was added to most \d
Le 15 juil. 09 à 23:03, Heikki Linnakangas a écrit :
2. The primary should have no business reading back from the archive.
The standby can read from the archive, as it can today.
Sorry to insist, but I'm not sold on your consensus here, yet:
I've spent the past several days working on the project I suggested here:
http://archives.postgresql.org/message-id/18653.1239741...@sss.pgh.pa.us
of getting rid of plpgsql's private lexer and having it use the core
lexer instead. I've run out of time for that and need to go focus on
commitfest
Bernd Helmle be...@oopsware.de writes:
I recently got a complaint from an OpenSuSE user, which had problems using
PostgreSQL 8.4 installed by a broken RPM from build service. The init
script used initdb --auth=ident sameuser accidentally, to initialize the
cluster (this seems to be the
Tom Lane wrote:
Another pretty serious issue is that the current plpgsql lexer treats
various sorts of qualified names as single tokens. I had thought this
could be worked around in the interface layer by doing more lookahead.
You can do that, and it mostly works, but it's mighty tedious.
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
... I spent a fair amount of time trying to work around that
by eliminating uses of yytext in plpgsql, and mostly succeeded, but
there are still some left. (Some of the remaining regression failures are
error messages that
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
The most effective solution might be to revert the change in pg_migrator
and instead have pg_dump interpret --binary-upgrade --schema-only to
include the data for sequences. It seems ugly as sin though :-(
It seems cleaner to
2009/7/14 KaiGai Kohei kai...@ak.jp.nec.com:
On the other hand, db_schema class was designed as an analogy to
directoty in filesystems. SELinux defines several permissions on
dir object class, such as add_name, remove_name and search.
I think that's a bad analogy and you need to make the
Robert Haas wrote:
2009/7/14 KaiGai Kohei kai...@ak.jp.nec.com:
On the other hand, db_schema class was designed as an analogy to
directoty in filesystems. SELinux defines several permissions on
dir object class, such as add_name, remove_name and search.
I think that's a bad analogy and you
The following patch is the tiny version of SE-PostgreSQL:
http://sepgsql.googlecode.com/files/sepgsql-01-tiny-8.5devel-r2193.patch.gz
In this version, all the security hooks (to make decision) invoked from
outside of the pg_xxx_aclcheck() and superuser_arg() were separated.
So, SE-PgSQL/tiny
2009/7/15 KaiGai Kohei kai...@ak.jp.nec.com:
Robert Haas wrote:
2009/7/14 KaiGai Kohei kai...@ak.jp.nec.com:
On the other hand, db_schema class was designed as an analogy to
directoty in filesystems. SELinux defines several permissions on
dir object class, such as add_name, remove_name and
Robert Haas wrote:
2009/7/15 KaiGai Kohei kai...@ak.jp.nec.com:
Robert Haas wrote:
2009/7/14 KaiGai Kohei kai...@ak.jp.nec.com:
On the other hand, db_schema class was designed as an analogy to
directoty in filesystems. SELinux defines several permissions on
dir object class, such as
On Mon, Dec 8, 2008 at 06:56, Pavan Deolaseepavan.deola...@gmail.com wrote:
Here is a patch which implements this. The PD_ALL_VISIBLE flag is set if all
tuples in the page are visible to all transactions and there are no DEAD
line pointers in the page. The second check is required so that
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
The most effective solution might be to revert the change in pg_migrator
and instead have pg_dump interpret --binary-upgrade --schema-only to
include the data for sequences. It seems ugly as sin though :-(
A larger question is what do we do with pg_migrator now. I am
embarrassed I didn't find these errors before, but now that they are
known, and will probably need an 8.4.1 to fix, should I remove the
pg_migrator 8.4 source code from pgfoundry?
Updated SE-PgSQL patch is here:
http://sepgsql.googlecode.com/files/sepgsql-01-tiny-8.5devel-r2196.patch.gz
Unused definitions of SELinux's permissions are ripped out from
the permission table.
KaiGai Kohei wrote:
The following patch is the tiny version of SE-PostgreSQL:
Bruce Momjian wrote:
A larger question is what do we do with pg_migrator now. I am
embarrassed I didn't find these errors before, but now that they are
known, and will probably need an 8.4.1 to fix, should I remove the
pg_migrator 8.4 source code from pgfoundry?
FYI, I am at EnterpriseDB
Tom Lane wrote:
Zdenek Kotala zdenek.kot...@sun.com writes:
I think you don't need transfer sequence table, because pg_dump should
create DDL command (CREATE SEQUENCE) which should create new nice
sequence relation.
Yeah, but pg_dump is doing a schema-only dump so it doesn't transfer
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
The most effective solution might be to revert the change in pg_migrator
and instead have pg_dump interpret --binary-upgrade --schema-only to
include the data for sequences. It seems ugly as sin though :-(
Uh, how is this going to
On Jul 15, 2009, at 11:41 PM, KaiGai Kohei kai...@ak.jp.nec.com wrote:
Robert Haas wrote:
2009/7/15 KaiGai Kohei kai...@ak.jp.nec.com:
Robert Haas wrote:
2009/7/14 KaiGai Kohei kai...@ak.jp.nec.com:
On the other hand, db_schema class was designed as an analogy to
directoty in filesystems.
Bruce Momjian br...@momjian.us writes:
A larger question is what do we do with pg_migrator now. I am
embarrassed I didn't find these errors before, but now that they are
known, and will probably need an 8.4.1 to fix, should I remove the
pg_migrator 8.4 source code from pgfoundry?
Well, we'd
Robert Haas wrote:
On Jul 15, 2009, at 11:41 PM, KaiGai Kohei kai...@ak.jp.nec.com wrote:
Robert Haas wrote:
2009/7/15 KaiGai Kohei kai...@ak.jp.nec.com:
Robert Haas wrote:
2009/7/14 KaiGai Kohei kai...@ak.jp.nec.com:
On the other hand, db_schema class was designed as an analogy to
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
The most effective solution might be to revert the change in pg_migrator
and instead have pg_dump interpret --binary-upgrade --schema-only to
include the data for sequences. It seems ugly as sin though :-(
Uh, how
Joshua,
I found your name as a reviewer at the commitfest.postgresql.org.
However, I don't think the initial proposal of the largeobject
security is now on the state to be reviewed seriously.
In my preference, it should be reworked based on the TOASTing
approach as discussed in this thread
2009/7/15 Jeff Davis pg...@j-davis.com:
Updated patch attached.
Changes:
* Added syntax support:
CREATE INDEX foo_idx ON foo ... (a CONSTRAINT =, b CONSTRAINT );
* More aggressively clear the shared memory entries to avoid
unnecessary checks
* Code cleanup
TODO:
* When adding
71 matches
Mail list logo
