On Friday 05 December 2008 11:13:37 Kurt Harriman wrote:
> 1. c++reserved
I have applied (an extended version of) this patch.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jul 16, 2009 at 01:49:14PM +0900, KaiGai Kohei wrote:
> 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 shoul
Dimitri Fontaine wrote:
> 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:
> http://archives.
2009/7/15 Jeff Davis :
> 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 const
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 previ
Tom Lane wrote:
> Bruce Momjian 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 i
Robert Haas wrote:
> On Jul 15, 2009, at 11:41 PM, KaiGai Kohei wrote:
>
>> Robert Haas wrote:
>>> 2009/7/15 KaiGai Kohei :
Robert Haas wrote:
> 2009/7/14 KaiGai Kohei :
>> On the other hand, db_schema class was designed as an analogy to
>> directoty in filesystems. SELinux defin
Bruce Momjian 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 still like pe
On Jul 15, 2009, at 11:41 PM, KaiGai Kohei wrote:
Robert Haas wrote:
2009/7/15 KaiGai Kohei :
Robert Haas wrote:
2009/7/14 KaiGai Kohei :
On the other hand, db_schema class was designed as an analogy to
directoty in filesystems. SELinux defines several permissions on
"dir" object class, suc
Bruce Momjian 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 behave in 8.5?
Tom Lane wrote:
> Zdenek Kotala 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
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 Enterprise
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:
>
> http://sepgsq
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?
--
Tom Lane wrote:
> Alvaro Herrera 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
On Mon, Dec 8, 2008 at 06:56, Pavan Deolasee 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 VACUUM takes
> up the page.
Robert Haas wrote:
> 2009/7/15 KaiGai Kohei :
>> Robert Haas wrote:
>>> 2009/7/14 KaiGai Kohei :
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
2009/7/15 KaiGai Kohei :
> Robert Haas wrote:
>> 2009/7/14 KaiGai Kohei :
>>> 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 t
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 on
Robert Haas wrote:
> 2009/7/14 KaiGai Kohei :
>> 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
2009/7/14 KaiGai Kohei :
> 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 permission name
Alvaro Herrera 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 have a pg_dump --d
Alvaro Herrera 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 point at the wrong
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.
Bernd Helmle 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 practice in olde
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 re
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:
http://archives.postgresql.org/pgsql-hackers/2009-0
Em Thu, 02 Jul 2009 15:27:33 -0400
Tom Lane escreveu:
> Peter Eisentraut 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 commands. For example,
> > \d
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
wan
Fujii Masao wrote:
> Hi,
>
> On Wed, Jul 15, 2009 at 8:15 PM, Robert Haas 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.
>
>> As so
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 add
On Wed, Jul 15, 2009 at 4:07 PM, Tom Lane wrote:
> David Blewett writes:
>> On Wed, Jul 15, 2009 at 12:17 PM, Tom Lane 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_encodin
David Blewett writes:
> On Wed, Jul 15, 2009 at 12:17 PM, Tom Lane 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 bad idea.
> I
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,
...) to
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 blahblah
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
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 Dunstan wrote:
>
>
>
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 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 exampl
David Blewett wrote:
> On Wed, Jul 15, 2009 at 12:17 PM, Tom Lane 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 bad idea.
>
--On 15. Juli 2009 19:59:56 +0300 Nagy Karoly Gabriel
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 COPY
involves files.
I find
Apologies to Tom for the duplicate...
On Wed, Jul 15, 2009 at 12:17 PM, Tom Lane 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 bad
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
On Wednesday 15 July 2009 19:01:05 Robert Haas wrote:
> On Wed, Jul 15, 2009 at 10:13 AM, Bernd Helmle wrote:
> > --On 15. Juli 2009 08:06:48 +0200 Andres Freund
wrote:
> >> It should not create multiple threads I think as all messages were a
> >> response the first mail?
> > It does (at least m
On Wed, Jul 15, 2009 at 10:13 AM, Bernd Helmle wrote:
> --On 15. Juli 2009 08:06:48 +0200 Andres Freund 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
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
http://www.geocities.com/mails
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 PostgreS
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 tha
Tom Lane wrote:
> Zdenek Kotala 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
David Blewett writes:
> On Wed, Jul 15, 2009 at 12:04 PM, Tom Lane 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
>>
On Wed, Jul 15, 2009 at 12:04 PM, Tom Lane 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 "wrong" encoding
Zdenek Kotala 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 the sequence.
The mo
David Blewett 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 additional WITH parameter
Dne 14.07.09 04:37, Bruce Momjian napsal(a):
Tom Lane wrote:
Bruce Momjian 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 sequence in the mig
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 t
Bruce Momjian 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 that item. I t
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 be
--On 15. Juli 2009 08:06:48 +0200 Andres Freund 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 to agree with Rob
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 (ran
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 po
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.
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 cur
On Wed, Jul 15, 2009 at 12:32 AM, Fujii Masao 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 reviewers for the
On Jul 15, 2009, at 3:11 AM, Kristian Larsson
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 know about others, but
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,
Hello,
Alvaro Herrera 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 think
> this shou
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 (pgsql-hackers
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 m
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,
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
> progres
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:
http://www.postgresql.org/mailpref/pgsql-hack
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 pr
72 matches
Mail list logo
