Re: [HACKERS] [PATCH] SE-PgSQL/tiny rev.2193

On Monday 20 July 2009 17:52:44 Joshua Brindle wrote: > That is your (and the communities) prerogative. Linus wasn't very > supportive of SELinux in the kernel either but it is the only way Linux got > an EAL4+ LSPP evaluation for use in certain government systems. I > personally would love to see

Re: [HACKERS] Non-blocking communication between a frontend and a backend (pqcomm)

Hi, On Wed, Jul 22, 2009 at 2:20 AM, Robert Haas wrote: > Fujii Masao, > > Are you planning to update this patch based on Martin's review? Sure. Attached is an updated patch. > On Fri, Jul 17, 2009 at 5:26 PM, Martin Pihlak wrote: >> Here's my initial review of the non-blocking pqcomm patch. The

Re: [HACKERS] [PATCH] SE-PgSQL/tiny rev.2193

Peter Eisentraut wrote: > On Monday 20 July 2009 17:52:44 Joshua Brindle wrote: >> That is your (and the communities) prerogative. Linus wasn't very >> supportive of SELinux in the kernel either but it is the only way Linux got >> an EAL4+ LSPP evaluation for use in certain government systems. I >>

Re: [HACKERS] Higher TOAST compression.

My 1st applied patch is the safest and simpliest : in pg_lzcompress.c : static const PGLZ_Strategy strategy_default_data = { 256,/* Data chunks less than 256 are not compressed */ 256,/* force compression on data chunks on record >= 256bytes */ 1, /* compressio

Re: [HACKERS] [PATCH] user mapping extension to pg_ident.conf

On Tue, Jul 21, 2009 at 16:06, Tom Lane wrote: > Magnus Hagander writes: >> On Tue, Jul 21, 2009 at 15:58, Tom Lane wrote: >>> Are you not describing a behavior that you yourself removed in 8.4, >>> ie the libpq code that looked aside at Kerberos for a username? > >> Yes, partially I am :-) > >> B

Re: [HACKERS] psql - small fix in \du

ANdreas Wenk schrieb: Hi, attached you can find a very small patch for the help in psql (\?). It's possible to use \du also as \du+ . The [+] was missing in help. I was asking about this at the general list and Peter E. was asking me to provide a patch. I sent the patch there but realized no

Re: [HACKERS] WIP: Deferrable unique constraints

2009/7/22 Dean Rasheed : > OK, here's an updated patch. > In case it's not obvious, I've opted for backend/commands for the new file.  - Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hack

Re: [HACKERS] Upgrading our minimum required flex version for 8.5

On Tue, Jul 14, 2009 at 05:10, Andrew Dunstan wrote: > Tom Lane wrote: >>> Maybe for the time being we need to think about keeping scan.c in CVS. >>> It's not like scan.l gets updated all that often. >>> >> >> We could if we had to, though it amounts to saying that Windows-based >> developers don'

Re: [HACKERS] Upgrading our minimum required flex version for 8.5

On Wed, Jul 22, 2009 at 12:42 PM, Magnus Hagander wrote: > FWIW, it seems the version that Andrew put up doesn't work in one of > my test environments, and also not in at last one of Dave's. I will > test it in my second test environment later today to be sure. It doesn't work in any of my bf ani

Re: [HACKERS] Upgrading our minimum required flex version for 8.5

Dave Page wrote: On Wed, Jul 22, 2009 at 12:42 PM, Magnus Hagander wrote: FWIW, it seems the version that Andrew put up doesn't work in one of my test environments, and also not in at last one of Dave's. I will test it in my second test environment later today to be sure. It doesn't

Re: [HACKERS] [PATCH] user mapping extension to pg_ident.conf

Magnus Hagander writes: >> Yup, you would need a protocol change that would allow the client to >> change its mind about what the username was after it got the auth >> challenge.  And then what effects does that have on username-sensitive >> pg_hba.conf decisions?  We go back and change our minds

Re: [HACKERS] [PATCH] user mapping extension to pg_ident.conf

On Wed, Jul 22, 2009 at 14:53, Tom Lane wrote: > Magnus Hagander writes: >>> Yup, you would need a protocol change that would allow the client to >>> change its mind about what the username was after it got the auth >>> challenge.  And then what effects does that have on username-sensitive >>> pg_

Re: [HACKERS] Upgrading our minimum required flex version for 8.5

Dave Page writes: > It doesn't work in any of my bf animals, or build machines :-( ?? narwhal seems to have gone green. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.or

Re: [HACKERS] psql - small fix in \du

Andreas Wenk writes: > I am not sure when the function shobj_description(oid, name) is giving a > result. That retrieves the comment for the object (the role, in this case). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Upgrading our minimum required flex version for 8.5

On Wed, Jul 22, 2009 at 2:16 PM, Tom Lane wrote: > Dave Page writes: >> It doesn't work in any of my bf animals, or build machines :-( > > ?? narwhal seems to have gone green. Narwhal is mingw/msys. The misbehaving flex is the one provided by Andrew for use with VC++ (where the aim is to avoid ha

Re: [HACKERS] Upgrading our minimum required flex version for 8.5

Tom Lane wrote: Dave Page writes: It doesn't work in any of my bf animals, or build machines :-( ?? narwhal seems to have gone green. Yeah, the problem is with MSVC, Narwal is a Mingw box. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) T

Re: [HACKERS] Higher TOAST compression.

Tom Lane wrote: > "Kevin Grittner" writes: >> It seems like it might be reasonable to have a separate threshold >> for compression from that for out-of-line storage. Since I've been >> in that code recently, I would be pretty comfortable doing >> something about that; but, as is so often the cas

Re: [HACKERS] [PATCH] "could not reattach to shared memory" on Windows

On Tue, Jul 21, 2009 at 14:06, Magnus Hagander wrote: > On Wed, Jul 15, 2009 at 11:20, Tsutomu Yamada wrote: >> Hello, >> >> Alvaro Herrera wrote: >>  > Tsutomu Yamada wrote: >>  > >>  > > This patch using VirtualAlloc()/VirtualFree() to avoid failing in >>  > > reattach to shared memory. >>  > >

Re: [HACKERS] Higher TOAST compression.

I wrote: > If we want to allow a compression target > external storage target, > I guess we would have to allow the smaller target to go first Scratch that part -- even with a compression target > the external storage target, it would make sense use the same sequence of steps. -Kevin -- Sent

Re: [HACKERS] Higher TOAST compression.

Sorry I responded that quickly this early. I keep having additional thoughts "Kevin Grittner" wrote: > Tom Lane wrote: >> And especially, how could you have per-column targets? > Yeah, this would have to be done by table, not by column. If we had an optional two targets by column, w

Re: [HACKERS] revised hstore patch

> "Tom" == Tom Lane writes: >> I'm prepared to give slightly more consideration to option #3: >> make the new code read the old format as well as the new one. Tom> If you think you can make that work, it would solve the problem. I was hoping to do it without changing the new format, but

Re: [HACKERS] revised hstore patch

On Jul 22, 2009, at 8:55 AM, Andrew Gierth wrote: The other option would be to fix the wasted-space bug in the existing hstore, and document that stored data must be updated at least once subsequent to that fix before doing a binary migrate to 8.5. Given this… (The pathological case is _very

Re: [HACKERS] change do_tup_output to take Datum arguments rather than cstring

Robert Haas writes: > On Mon, Jun 15, 2009 at 1:20 PM, Tom Lane wrote: >> Robert Haas writes: >>> it looks like I can probably rip that member out of TupOutputState >>> altogether. >> >> Yeah, that's exactly what I was thinking. > Excellent. Revised patch attached. Applied with minor editoria

Re: [HACKERS] revised hstore patch

Hi, Le 22 juil. 09 à 02:56, Robert Haas a écrit : On Tue, Jul 21, 2009 at 7:25 PM, Tom Lane wrote: Or maybe we should think about having two versions of hstore. This is all tied up in the problem of having a decent module infrastructure (which I hope somebody is working on for 8.5). I ind

Re: [HACKERS] revised hstore patch

On Wed, Jul 22, 2009 at 1:40 PM, Dimitri Fontaine wrote: > Hi, > > Le 22 juil. 09 à 02:56, Robert Haas a écrit : >> >> On Tue, Jul 21, 2009 at 7:25 PM, Tom Lane wrote: >>> >>> Or maybe we should think about having two versions of hstore.  This >>> is all tied up in the problem of having a decent mo

Re: [HACKERS] revised hstore patch

> "David" == "David E Wheeler" writes: >> The other option would be to fix the wasted-space bug in the >> existing hstore, and document that stored data must be updated at >> least once subsequent to that fix before doing a binary migrate to >> 8.5. [...] David> Could it be that only

[HACKERS] Extension Facility

Hi, The same mail as before in a new thread, per Robert comment. Including the body rather than an archive link for various reasons, including making it easy to comment here rather than there. Le 22 juil. 09 à 02:56, Robert Haas a écrit : On Tue, Jul 21, 2009 at 7:25 PM, Tom Lane wrote: O

[HACKERS] SRPMs?

Where are the SRPMs to go with the binary RPMs on our download sites (or for that matter on yum.pgsqlrpms.org). ISTM we should not be publishing binary RPMs without simultaneously publishing the corresponding SRPMs. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgre

Re: [HACKERS] psql - small fix in \du

Tom Lane wrote: Andreas Wenk writes: I am not sure when the function shobj_description(oid, name) is giving a result. That retrieves the comment for the object (the role, in this case). regards, tom lane Tom, thank you. I will provide an updated patch tomorrow. Che

Re: [HACKERS] GEQO vs join order restrictions

Hi Tom, Robert, Hi all, nks, On Sunday 19 July 2009 19:23:18 Tom Lane wrote: > Andres Freund writes: > > On Saturday 18 July 2009 17:48:14 Tom Lane wrote: > >> I'm inclined to address this by rewriting gimme_tree so that it *always* > >> finds a valid join order based on the given tour. This woul

Re: [HACKERS] extension facility (was: revised hstore patch)

On Tue, Jul 21, 2009 at 8:56 PM, Robert Haas wrote: > A decent module infrastructure is probably not going to fix this > problem unless it links with -ldwiw. There are really only two > options here: > > - Keep the old version around for compatibility and add a new version > that isn't compatible,

[HACKERS] Aggregate-function space leakage

I looked into Chris Spotts' recent report of massive memory leakage in 8.4, in a case involving array_agg() executed in a GROUP BY query: http://archives.postgresql.org/pgsql-general/2009-07/msg00858.php The reason for that turns out to be that we deliberately lobotomized array_agg that way, just l

Re: [HACKERS] Aggregate-function space leakage

On Wed, 2009-07-22 at 17:14 -0400, Tom Lane wrote: > One possibility is to have nodeAgg.c reset the "aggcontext" between > groups when in group mode. I think this would be more than a one-liner > fix because it probably has pointers to transvalues that are in that > context, but it's surely doable

Re: [HACKERS] Aggregate-function space leakage

Jeff Davis writes: > On Wed, 2009-07-22 at 17:14 -0400, Tom Lane wrote: >> One possibility is to have nodeAgg.c reset the "aggcontext" between >> groups when in group mode. I think this would be more than a one-liner >> fix because it probably has pointers to transvalues that are in that >> conte

Re: [HACKERS] Aggregate-function space leakage

On Wed, Jul 22, 2009 at 10:14 PM, Tom Lane wrote: > The reason for that turns out to be that we deliberately lobotomized > array_agg that way, just last month: > http://archives.postgresql.org/pgsql-committers/2009-06/msg00259.php > in response to this problem: > http://archives.postgresql.org/pgsq

Re: [HACKERS] Determining client_encoding from client locale

On Mon, Jul 6, 2009 at 10:00 AM, Heikki Linnakangas wrote: > Here's my first attempt at setting client_encoding automatically from > locale. > > It adds a new conninfo parameter to libpq, "client_encoding". If set to > "auto", libpq uses the encoding as returned by > pg_get_encoding_from_locale().

[HACKERS] join regression failure on cygwin

My Cygwin buildfarm member started failing (hanging, in fact) recently. It seems to hang consistently in join.sql and the only way I can get it to complete is to kill the backend fairly violently. See It lo

Re: [HACKERS] Determining client_encoding from client locale

Jaime Casanova wrote: > this little test compiles fine until i applied your patch :( > > postg...@casanova1:~/pg_releases/pgtests$ gcc -o test-libpq > test-libpq.o -L/usr/local/pgsql/head/lib -lpq > /usr/local/pgsql/head/lib/libpq.so: undefined reference to > `pg_get_encoding_from_locale' Do you

Re: [HACKERS] [PATCH] DefaultACLs

On Fri, Jul 17, 2009 at 9:46 PM, Joshua Tolley wrote: > On Tue, Jul 14, 2009 at 11:10:00PM +0200, Petr Jelinek wrote: >> Hello, >> >> this is first public version of our DefaultACLs patch as described on >> http://wiki.postgresql.org/wiki/DefaultACL . > > Ok, here's my first crack at a comprehensiv

Re: [HACKERS] [PATCH 1/2 v3] [libpq] rework sigpipe-handling macros

On Mon, Jul 20, 2009 at 3:14 AM, Jeremy Kerr wrote: >> That code is not broken as it stands, and doesn't appear to really >> gain anything from the proposed change.  Why should we risk any >> portability questions when the code isn't going to get either simpler >> or shorter? > > OK, after attempt

Re: [HACKERS] [PATCH] Psql List Languages

On Sun, Jul 19, 2009 at 4:00 AM, Peter Eisentraut wrote: > Please submit an updated patch. Fernando, If you would like to have this change committed during this CommitFest, please submit an updated patch ASAP. Otherwise, you can resubmit for the next CommitFest in September. Thanks, ...Robert

Re: [HACKERS] [PATCH] Psql List Languages

On Thu, Jul 23, 2009 at 2:23 AM, Robert Haas wrote: > If you would like to have this change committed during this > CommitFest, please submit an updated patch ASAP.  Otherwise, you can > resubmit for the next CommitFest in September. You know, I don't think we have any rules against people respon

Re: [HACKERS] [PATCH] Psql List Languages

On Wed, Jul 22, 2009 at 9:35 PM, Greg Stark wrote: > On Thu, Jul 23, 2009 at 2:23 AM, Robert Haas wrote: >> If you would like to have this change committed during this >> CommitFest, please submit an updated patch ASAP.  Otherwise, you can >> resubmit for the next CommitFest in September. > > You k

Re: [HACKERS] Upgrading our minimum required flex version for 8.5

I got bit by this tonight as part of testing a patch on CentOS 5, which like RHEL 5 still ships flex 2.5.4. I just wrote a little guide on how to grab a source RPM from a Fedora version and install it to work around that problem: http://notemagnet.blogspot.com/2009/07/upgrading-flex-from-sourc

Re: [HACKERS] join regression failure on cygwin

I wrote: My Cygwin buildfarm member started failing (hanging, in fact) recently. It seems to hang consistently in join.sql and the only way I can get it to complete is to kill the backend fairly violently. See

Re: [HACKERS] [PATCH] Psql List Languages

On Wed, Jul 22, 2009 at 9:43 PM, Robert Haas wrote: > On Wed, Jul 22, 2009 at 9:35 PM, Greg Stark wrote: >> On Thu, Jul 23, 2009 at 2:23 AM, Robert Haas wrote: >>> If you would like to have this change committed during this >>> CommitFest, please submit an updated patch ASAP.  Otherwise, you can >>

Re: [HACKERS] multi-threaded pgbench

I just took multi-threaded pgbench for an initial spin, looks good overall with only a couple of small rough edges. The latest code works differently depending on whether you compiled with --enable-thread-safety or not, it defines some structures based on fork if it's not enabled: #elif defi

Re: [HACKERS] [PATCH] Psql List Languages

On Thu, Jul 23, 2009 at 3:11 AM, Robert Haas wrote: > > If my email struck you as rude, I certainly apologize for that.  I'm > trying really hard to be efficient about this without stepping on > anyone's feelings, but that's a fine line to walk and I'm not sure > I'll always be on the right side of

Re: [HACKERS] Determining client_encoding from client locale

On Wed, Jul 22, 2009 at 7:30 PM, Alvaro Herrera wrote: > Jaime Casanova wrote: > >> this little test compiles fine until i applied your patch :( >> >> postg...@casanova1:~/pg_releases/pgtests$ gcc -o test-libpq >> test-libpq.o -L/usr/local/pgsql/head/lib -lpq >> /usr/local/pgsql/head/lib/libpq.so:

Re: [HACKERS] generic explain options v3

On Tue, Jul 21, 2009 at 10:29 PM, Robert Haas wrote: > On Tue, Jul 21, 2009 at 10:05 PM, Tom Lane wrote: >> Robert Haas writes: >>> On Tue, Jul 21, 2009 at 7:47 PM, Tom Lane wrote: Also, I'd suggest changing the ExplainStmt struct to have a list of DefElem options instead of hard-wiring

Re: [HACKERS] [PATCH] DefaultACLs

On Wed, Jul 22, 2009 at 08:54:19PM -0400, Robert Haas wrote: > I am gathering that this patch is still a bit of a WIP. I don't consider it a WIP. Petr posted a patch a couple of days ago, but I've not been able to verify its changes or perform some additional testing I had in mind, because of my

Re: [HACKERS] multi-threaded pgbench

Greg Smith wrote: > That second code path, when --enable-thread-safety is turned off, crashes > and burns on my Linux system: It comes from confliction of identifiers. Renaming identifiers with #define can solve the errors: #define pthread_t pg_pthread_t #define

Re: [HACKERS] [PATCH] DefaultACLs

Robert Haas wrote: So are these warts fixed in the latest revision of this patch? http://archives.postgresql.org/pgsql-hackers/2009-07/msg01216.php I am gathering that this patch is still a bit of a WIP. I think it might be best to mark it returned with feedback and let Petr resubmit for the n

Re: [HACKERS] [PATCH] DefaultACLs

On Wed, Jul 22, 2009 at 11:21 PM, Joshua Tolley wrote: > On Wed, Jul 22, 2009 at 08:54:19PM -0400, Robert Haas wrote: >> I am gathering that this patch is still a bit of a WIP. > > I don't consider it a WIP. Petr posted a patch a couple of days ago, but I've > not been able to verify its changes or

Re: [HACKERS] [PATCH] DefaultACLs

On Wed, Jul 22, 2009 at 11:26 PM, Petr Jelinek wrote: > Robert Haas wrote: >> >> So are these warts fixed in the latest revision of this patch? >> >> http://archives.postgresql.org/pgsql-hackers/2009-07/msg01216.php >> >> I am gathering that this patch is still a bit of a WIP.  I think it >> might

Re: [HACKERS] [PATCH] DefaultACLs

* Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jul 22, 2009 at 11:26 PM, Petr Jelinek wrote: > > The docs are not complete but that's up to Stephen, otherwise the patch > > should be finished. But I am not the reviewer :) > > Well, perhaps we had better prod Stephen then, since complete do

Re: [HACKERS] Determining client_encoding from client locale

On Wed, Jul 22, 2009 at 9:58 PM, Jaime Casanova wrote: > On Wed, Jul 22, 2009 at 7:30 PM, Alvaro > Herrera wrote: >> Jaime Casanova wrote: >> >>> this little test compiles fine until i applied your patch :( >>> >>> postg...@casanova1:~/pg_releases/pgtests$ gcc -o test-libpq >>> test-libpq.o -L/usr/

Re: [HACKERS] join regression failure on cygwin

Andrew Dunstan writes: >> My Cygwin buildfarm member started failing (hanging, in fact) >> recently. It seems to hang consistently in join.sql and the only way I >> can get it to complete is to kill the backend fairly violently. See >>

Re: [HACKERS] [PATCH] "could not reattach to shared memory" on Windows

Hello, Thank you for correcting patch. However, I think the following block have to use VirualFree*Ex*(). (yes, this should never happen, maybe there is actually no problem. but for logical correctness) >+ if (address != UsedShmemSegAddr) >+ { >+ /* >+ * Sho

Re: [HACKERS] revised hstore patch

On Jul 22, 2009, at 11:17 AM, Andrew Gierth wrote: To me (A) is looking like the obvious choice (the people smart enough to be using hstore-new from CVS already can handle the minor pain of updating the on-disk format). Unless I hear any objections I will proceed accordingly... Yes, that seem

Re: [HACKERS] extension facility (was: revised hstore patch)

On Jul 22, 2009, at 1:11 PM, Robert Haas wrote: If you keep an old and a new version of the datatype, you can't upgrade a tuple at a time, but you can at least upgrade one column at a time, which is still better than a kick in the head. And as long as you're willing to deprecate how far back y

Re: [HACKERS] Extension Facility

On Jul 22, 2009, at 11:46 AM, Dimitri Fontaine wrote: Here are from memory the problems we don't have a solution for yet: - how to give user the ability to install the extension's objects in another schema than the pg_extension default one Was that not a part of your original proposal, or th

Re: [HACKERS] [PATCH] DefaultACLs

Hi, > >> Anyway, while this patch might not necessary get commited in this commit >> fest, I'd still like to have opinion from one of the commiters on "the VIEW >> problem" which also affects grant on all patch ( see >> http://archives.postgresql.org/pgsql-hackers/2009-07/msg00957.php ) and I >> f