Devrim GÜNDÜZ wrote:
> ! Ruby - http://pqxx.org/development/libpqxx/
I see no mention of Ruby on that page. Was that supposed to point
somewhere else?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Tom Lane wrote:
> > pgAdmin MD5's the passwords if you use the GUI to change them, or when
> > add a user. It doesn't make any attempt to parse the SQL if you enter
> > it yourself in the query tool though (nor is it going to).
>
> No, I wouldn't expect it to go that far. My point is just that
>
Jim Cox escribió:
> Attached s/b a patch for the 8.5 TODO "Add comments to output indicating
> version
> of pg_dump and of the database server" (pg_dump/pg_restore section, 9.2).
Hmm, what happens if you do a pg_dump -Fc? Is this info saved anywhere
in the dump? Surely if thi is useful in the
On Sunday 27 September 2009 19:03:33 Robert Haas wrote:
> On Sun, Sep 27, 2009 at 9:24 PM, Selena Deckelmann
>
> wrote:
> > Hi!
> >
> > On Wed, Sep 23, 2009 at 2:16 AM, Roger Leigh wrote:
> >> On Fri, Sep 18, 2009 at 11:30:05AM -0700, Selena Deckelmann wrote:
> >>> Brad says:
> >>>
> >>> T
* Robert Haas (robertmh...@gmail.com) wrote:
> > One potential trouble spot is that presumably the built-in default
> > privileges (eg, PUBLIC EXECUTE for functions) would *not* cumulate
> > with user-specified defaults.
>
> Why not?
How would you have a default that says "I *don't* want public e
On Mon, Sep 28, 2009 at 10:44 PM, Tom Lane wrote:
> Robert Haas writes:
>> I haven't read the patch, but it seems like one possible solution to
>> this problem would be to declare that any any DEFAULT PRIVILEGES you
>> set are cumulative. If you configure a global default, a per-schema
>> defaul
Euler Taveira de Oliveira writes:
> Itagaki Takahiro escreveu:
>> Thanks. Except choice of words, can I think the basic architecture of
>> the patch is ok? The codes to handle global variables like ReadBufferCount
>> and GlobalReadBufferCount could be rewrite in cleaner way if we could
>> drop sup
Robert Haas writes:
> I haven't read the patch, but it seems like one possible solution to
> this problem would be to declare that any any DEFAULT PRIVILEGES you
> set are cumulative. If you configure a global default, a per-schema
> default, a default for tables whose names begin with the letter
Itagaki Takahiro escreveu:
> Thanks. Except choice of words, can I think the basic architecture of
> the patch is ok? The codes to handle global variables like ReadBufferCount
> and GlobalReadBufferCount could be rewrite in cleaner way if we could
> drop supports of log_{parser|planner|executor|sta
On Mon, Sep 28, 2009 at 1:32 PM, Tom Lane wrote:
> The generic issue that the code doesn't even think about addressing
> is which default should apply when there's potentially more than one
> applicable default? As long as there's only global and per-schema
> defaults, it's not too hard to decide
Stephen Frost wrote:
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> BTW, I raised a few issues. Do you have any opinions?
>
> Certainly, though they're my opinions and I don't know if the committers
> will agree, but I suspect they will.
Thanks for your comments.
>> * deployment of the source
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> BTW, I raised a few issues. Do you have any opinions?
Certainly, though they're my opinions and I don't know if the committers
will agree, but I suspect they will.
> * deployment of the source code
>
> The current patch implements all the access con
Euler Taveira de Oliveira wrote:
> I'm reviewing your patch. Your patch is in good shape. It applies cleanly. All
> of the things are built as intended (including the two contrib modules). It
> doesn't include docs but I wrote it. Basically, I produced another patch (that
> are attached) correct
marcin mank writes:
>> The case that ENCRYPTED
>> protects against is database superusers finding out other users'
>> original passwords, which is a security issue to the extent that those
>> users have used the same/similar passwords for other systems.
> I just want to note that md5 is not much
On 9/28/09, Josh Berkus wrote
>
> > I already mentioned one case that there's longstanding demand for, which
> > is to instantiate the correct permissions on new partition child tables.
>
> Wouldn't that be handled by inheritance?
I wish, but no:
http://www.postgresql.org/docs/current/interactiv
Josh Berkus writes:
> I think trying to make this patch a panacea in the first iteration is
> liable to backfire.
I did not suggest any such thing --- the current scope of functionality
is fine by me for a first cut. What I *am* saying is that we had better
have some idea of how we are going to
Josh Berkus writes:
> Hmmm, that would be a useful, easy (I think) security feature: add a GUC
> for failed_logins_allowed.
And the counts would be tracked and enforced where?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
Jeff Davis wrote:
On Mon, 2009-09-28 at 15:52 -0700, Josh Berkus wrote:
It takes about 32 hours to brute force all passwords from [a-zA-Z0-9]
of up to 8 chars in length.
That would be a reason to limit the number of failed connection attempts
from a single source, then, rather than
On Mon, 2009-09-28 at 15:52 -0700, Josh Berkus wrote:
> > It takes about 32 hours to brute force all passwords from [a-zA-Z0-9]
> > of up to 8 chars in length.
>
> That would be a reason to limit the number of failed connection attempts
> from a single source, then, rather than a reason to change
Bernd Helmle escribió:
> Seems Alvaro forgot to include pg_db_role_setting.h, it doesn't
> compile anymore with this error:
Here they are.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
/*
* pg_db_role_setting.c
*
On Mon, 2009-09-28 at 15:52 -0700, Josh Berkus wrote:
> > It takes about 32 hours to brute force all passwords from [a-zA-Z0-9]
> > of up to 8 chars in length.
>
> That would be a reason to limit the number of failed connection attempts
> from a single source, then, rather than a reason to change
Bernd Helmle escribió:
> Seems Alvaro forgot to include pg_db_role_setting.h, it doesn't
> compile anymore with this error:
Huh, you're right, I did :-( Let me unpack the laptop ...
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command
> It takes about 32 hours to brute force all passwords from [a-zA-Z0-9]
> of up to 8 chars in length.
That would be a reason to limit the number of failed connection attempts
from a single source, then, rather than a reason to change the hash
function.
Hmmm, that would be a useful, easy (I think
On Sep 27, 2009, at 9:19 PM, Tom Lane wrote:
What we seem to be lacking in this case is a good tech-speak
option for the underlying catalog name. I'm still not happy
with having a catalog and a view that are exactly the same
except for "s", especially since as Alvaro notes that won't
lead to des
--On 27. September 2009 21:59:37 -0400 Robert Haas
wrote:
Bernd,
Can you review this new version and mark this as Ready for Committer
if it looks OK, or else respond with comments and set it back to
Waiting on Author?
Seems Alvaro forgot to include pg_db_role_setting.h, it doesn't compil
> The case that ENCRYPTED
> protects against is database superusers finding out other users'
> original passwords, which is a security issue to the extent that those
> users have used the same/similar passwords for other systems.
I just want to note that md5 is not much of a protection against thi
ht place for these counters. Maybe we should
put it in buf_init.c. Ideas?
> boolcosts; /* print costs */
> + boolbuffer; /* print buffer stats */
Rename it to "buffers".
> + /* Buffer usage */
> + long
Hi,
Attached is a small doc patch for README at top level, which updates
links for some projects. It could be backpatched, too.
Regards,
--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.or
Whoops I missed this email...
Robert Haas wrote:
> Rereading the thread, it seems that the main question is whether there
> are any platforms that we support that have neither getifaddrs or
> SIOCGIFCONF, or where they don't work properly.
As far as I can tell, there are no non-ancient mainstream
Tom,
> The owning-ROLE match is required, else you have issues with exactly
> what the ACL really means. What we're discussing is what other filters
> might exist to determine which objects are affected. The patch already
> tries to handle the cases of "all owned objects" and "all owned objects
Tom Lane wrote:
Andrew Dunstan writes:
Alvaro Herrera wrote:
syslog uses a nonblocking file descriptor without a retry loop to
implement their logic. I see no reason we couldn't do that ourselves.
Mixing it with regular blocking code could turn out to be nontrivial,
but I don't thin
Josh Berkus writes:
>> But more generally, this is a fairly large and complicated patch in
>> comparison to the reward, if the intention is that it will never support
>> anything more than the one case of "IN SCHEMA foo" filtering.
> I thought we were doing ROLEs?
The owning-ROLE match is requir
Tom,
>> I thought the idea was to simply avoid that situation. Maybe we want to
>> forget about global defaults if that's the case, and just do the ROLE
>> defaults.
>
> That seems like a pretty dead-end design.
Well, the whole purpose for DefaultACLs is to simplify administration
for the simpl
Andrew Dunstan writes:
> Alvaro Herrera wrote:
>> syslog uses a nonblocking file descriptor without a retry loop to
>> implement their logic. I see no reason we couldn't do that ourselves.
>> Mixing it with regular blocking code could turn out to be nontrivial,
>> but I don't think it's impossibl
Robert Haas wrote:
> So is this one Ready for Committer?
Here we go, I think this one is ready. In addition to previous patches,
it does:
* Use some techniques from postfix for getting interface addresses.
Couldn't use code outright, due to license incompatibilities.
* Tested on Solaris, Fre
Alvaro Herrera wrote:
Tom Lane escribió:
Alvaro Herrera writes:
Tom Lane escribió:
This is the same issue already raised with respect to syslog versus
syslogger, ie, some people would rather lose log data than have the
backends block waiting for it to be written.
Th
Josh Berkus writes:
>> This isn't just a matter of a few missed cases while coding, I think.
>> The generic issue that the code doesn't even think about addressing
>> is which default should apply when there's potentially more than one
>> applicable default?
> I thought the idea was to simply a
Tom Lane escribió:
> Alvaro Herrera writes:
> > Tom Lane escribió:
> >> This is the same issue already raised with respect to syslog versus
> >> syslogger, ie, some people would rather lose log data than have the
> >> backends block waiting for it to be written.
>
> > That could be made configura
Robert Haas wrote:
Can you at least take a stab at it? We can fix your grammar, but
guessing what's going on without documentation is hard.
With some help from David Fetter, I took another try at it. I hope
someone finds this helpful. I'm happy to answer any questions.
Regards,
Marko Tiikka
> There is another large problem, too. The patch seems to have
> only half-baked support for global defaults (those not tied to a
> specific schema) --- it looks like you can put them in, but half
> of the code will ignore them or else fail while trying to use them.
> This isn't just a matter of
2009/9/28 John Naylor :
> Pavel,
>
> It looks good. My last email didn't go to -hackers, since I wasn't
> subscribed. I had to resend to -hackers so there will be a link for
> the commitfest page. I think you might have to resend your latest
> patch to the list. Sorry!
nothing, patch attached
Pav
On Mon, Sep 28, 2009 at 2:00 PM, Marko Kreen wrote:
> So promoting the ENCRYPTED 'foo' as "secure" may lure users into
> false sense of security, and be lax against sniffing and logfile
> protection.
ENCRYPTED prevents the user's password from being stolen by a modified server.
...Robert
--
Se
Marko Kreen writes:
> So promoting the ENCRYPTED 'foo' as "secure" may lure users into
> false sense of security, and be lax against sniffing and logfile
> protection.
This argument is entirely irrelevant to the point. Yes, ENCRYPTED
doesn't fix everything, but it is still good practice to use i
On Mon, Sep 28, 2009 at 2:13 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Mon, Sep 28, 2009 at 1:07 PM, Alvaro Herrera
>> wrote:
>> > Tom Lane escribió:
>> >> [ please trim the quoted material a bit, folks ]
>> >>
>> >> Magnus Hagander writes:
>> >> > 2009/9/28 Robert Haas :
>> >> >>
Tom Lane wrote:
Petr Jelinek writes:
[ latest version of DefaultACLs patch ]
I started looking through this patch, but found that it's not nearly
ready to commit :-(. The big missing piece is that there's no pg_dump
support for default ACLs. That's a bigger chunk of code than I have
Robert Haas escribió:
> On Mon, Sep 28, 2009 at 1:07 PM, Alvaro Herrera
> wrote:
> > Tom Lane escribió:
> >> [ please trim the quoted material a bit, folks ]
> >>
> >> Magnus Hagander writes:
> >> > 2009/9/28 Robert Haas :
> >> >> The problem with having the syslogger send the data directly to an
Abhijit Menon-Sen wrote:
The fix is fairly small (see attached) although I need to check with
some perlguts guru to see if I need to decrement a refcounter here or
there.
Slightly simpler patch attached (and tested).
Thanks. Committed.
cheers
andrew
--
Sent via pgsql-hackers ma
On 9/28/09, Tom Lane wrote:
> Actually there's a much bigger problem with asking the backend to reject
> weak passwords: what ya gonna do with a pre-MD5'd string? Which is
> exactly what the backend is going to always get, in a security-conscious
> environment.
Hmm... Looking at the docs, I don
On Mon, 2009-09-28 at 19:26 +0200, Pavel Stehule wrote:
> > Also, you should consistently pass NIL when you mean an empty list, but
> > sometimes you pass NULL to FuncnameGetCandidates().
>
> It's bug, where is it?
In regproc.c.
Jeff
--
Sent via pgsql-hackers mailing list (pgsql-hacke
(resent to -hackers)
I just applied and tested the new patch. Everything works great.
The only thing I would change now is some of the comments.
1). On line 289, one of the regression test comments got copied:
+ move forward in c; --should be at '5'
change to:
+ move forwar
Alvaro Herrera writes:
> Tom Lane escribió:
>> This is the same issue already raised with respect to syslog versus
>> syslogger, ie, some people would rather lose log data than have the
>> backends block waiting for it to be written.
> That could be made configurable; i.e. let the user choose wh
Petr Jelinek writes:
> [ latest version of DefaultACLs patch ]
I started looking through this patch, but found that it's not nearly
ready to commit :-(. The big missing piece is that there's no pg_dump
support for default ACLs. That's a bigger chunk of code than I have
time/interest to write, a
2009/9/28 Jeff Davis :
> On Mon, 2009-09-28 at 18:23 +0200, Pavel Stehule wrote:
>> when I though about control, I found so syntax with mandatory VARIADIC
>> is difficult implementable. So probably the most feasible solution for
>> this moment is to discard a variadic functions from set of function
On Mon, Sep 28, 2009 at 1:07 PM, Alvaro Herrera
wrote:
> Tom Lane escribió:
>> [ please trim the quoted material a bit, folks ]
>>
>> Magnus Hagander writes:
>> > 2009/9/28 Robert Haas :
>> >> The problem with having the syslogger send the data directly to an
>> >> external process is that the ex
Tom Lane escribió:
> [ please trim the quoted material a bit, folks ]
>
> Magnus Hagander writes:
> > 2009/9/28 Robert Haas :
> >> The problem with having the syslogger send the data directly to an
> >> external process is that the external process might be unable to
> >> process the data as fast
pete...@gmx.net (Peter Eisentraut) writes:
> On Fri, 2009-09-25 at 16:59 -0400, Tom Lane wrote:
>> "shakahsha...@gmail.com" writes:
>> > From pg_dump/pg_restore section (9.2 of the Todo page on the
>> > PostgreSQL Wiki), is the following item
>> > "Add comments to output indicating version of pg
On Mon, 2009-09-28 at 18:23 +0200, Pavel Stehule wrote:
> when I though about control, I found so syntax with mandatory VARIADIC
> is difficult implementable. So probably the most feasible solution for
> this moment is to discard a variadic functions from set of functions
> that are callable with n
- Forwarded message from Robert Haas -
Date: Sun, 27 Sep 2009 12:52:35 -0400
From: Robert Haas
To: Boszormenyi Zoltan
Cc: Dan Colish , pgsql-rrreview...@postgresql.org,
Jeff Janes ,
Hans-Juergen Schoenig ,
Michael Meskes
Subject: Re: CF 2009-09: initial reviewin
2009/9/28 Jeff Davis :
> On Mon, 2009-09-28 at 11:50 +0200, Pavel Stehule wrote:
>> This is maybe too strict. I thing, so safe version is allow variadic
>> packed parameter with VARIADIC keyword as Jeff proposes.
>
> The combination of variadic parameters and named call notation is
> somewhat stran
On Mon, 2009-09-28 at 11:50 +0200, Pavel Stehule wrote:
> This is maybe too strict. I thing, so safe version is allow variadic
> packed parameter with VARIADIC keyword as Jeff proposes.
The combination of variadic parameters and named call notation is
somewhat strange, on second thought. Can you i
On Mon, Sep 28, 2009 at 11:31 AM, Marko Tiikkaja
wrote:
> Robert Haas wrote:
>>
>> So I think we should at a minimum ask the patch author to (1) fix the
>> explain bugs I found and (2) update the README, as well as (3) revert
>> needless whitespace changes - there are a couple in execMain.c, from
Tom Lane wrote:
> Actually there's a much bigger problem with asking the backend to reject
> weak passwords: what ya gonna do with a pre-MD5'd string? Which is
> exactly what the backend is going to always get, in a security-conscious
> environment.
You mean if the password is set with
CREATE/ALT
Dave Page writes:
> pgAdmin MD5's the passwords if you use the GUI to change them, or when
> add a user. It doesn't make any attempt to parse the SQL if you enter
> it yourself in the query tool though (nor is it going to).
No, I wouldn't expect it to go that far. My point is just that
pre-MD5'd
On Mon, Sep 28, 2009 at 4:38 PM, Tom Lane wrote:
> "Albe Laurenz" writes:
>> Tom Lane wrote:
>>> Actually there's a much bigger problem with asking the backend to reject
>>> weak passwords: what ya gonna do with a pre-MD5'd string? Which is
>>> exactly what the backend is going to always get, in
"Albe Laurenz" writes:
> Tom Lane wrote:
>> Actually there's a much bigger problem with asking the backend to reject
>> weak passwords: what ya gonna do with a pre-MD5'd string? Which is
>> exactly what the backend is going to always get, in a security-conscious
>> environment.
> I'm thinking of
Actually there's a much bigger problem with asking the backend to reject
weak passwords: what ya gonna do with a pre-MD5'd string? Which is
exactly what the backend is going to always get, in a security-conscious
environment.
regards, tom lane
--
Sent via pgsql-hackers m
On Sat, 2009-09-26 at 15:35 -0600, Joshua Tolley wrote:
> On Sat, Sep 26, 2009 at 11:43:46AM -0400, Tom Lane wrote:
> > complete but more complex solution. (dup2 works on Windows, no?)
>
> Unless I'm misreading syslogger.c, dup2() gets called on every platform.
>
> I've started the wiki page in
Andrew Dunstan writes:
> Albe Laurenz wrote:
>> 1) One could have a set of GUCs like min_password_length,
>> min_password_nonchars and similar that everybody
>> could configure. This is not extremely flexible though.
>> 2) Another idea would be a GUC that contains a regular
>> expression that a pa
[ please trim the quoted material a bit, folks ]
Magnus Hagander writes:
> 2009/9/28 Robert Haas :
>> The problem with having the syslogger send the data directly to an
>> external process is that the external process might be unable to
>> process the data as fast as syslogger is sending it. I'm
2009/9/28 Andrew Dunstan :
>
>
> Ing. Marcos L. Ortíz Valmaseda wrote:
>>>
>>> My vote is for #3, if anything.
>>>
>>>
>> You have to analyze all points before to do this. I vote too for the third
>> option, but you have to be clear that how do you ´ll check the weakness of
>> the password:
>> 1
Ing. Marcos L. Ortíz Valmaseda wrote:
My vote is for #3, if anything.
You have to analyze all points before to do this. I vote too for the
third option, but you have to be clear that how do you ´ll check the
weakness of the password:
1- For example: the length should be greater that 6 c
2009/9/28 Stephen Frost :
> * Magnus Hagander (mag...@hagander.net) wrote:
>>> Are there better ways?
>>
>> Isn't there some library we can link with and (conditionally) use? I
>> believe windows exposes api function(s) to let you verify password
>> complexity - I'm sure there is something similar
On Sun, Sep 27, 2009 at 11:31 PM, Jeff Davis wrote:
> On Sun, 2009-09-27 at 22:40 -0400, Robert Haas wrote:
>> Apparently, CommitFest
>> no longer means a time when people put aside their own patches to
>> review those of others; it seems now to mean a time when 87% of the
>> patch authors either
In response to "Ing. Marcos L. Ortíz Valmaseda" :
> Andrew Dunstan escribió:
> >
> > Albe Laurenz wrote:
> >> Dear hackers,
> >>
> >> I have been thinking about ways to have PostgreSQL reject
> >> weak passwords.
> >>
> >> I think the standard recommendation is "use PAM and LDAP",
> >> but that r
* Magnus Hagander (mag...@hagander.net) wrote:
>> Are there better ways?
>
> Isn't there some library we can link with and (conditionally) use? I
> believe windows exposes api function(s) to let you verify password
> complexity - I'm sure there is something similar available on unix,
> hopefu
Andrew Dunstan escribió:
Albe Laurenz wrote:
Dear hackers,
I have been thinking about ways to have PostgreSQL reject
weak passwords.
I think the standard recommendation is "use PAM and LDAP",
but that requires the user to change the password outside
of PostgreSQL. And who would want to setup
On Mon, Sep 28, 2009 at 6:51 AM, Magnus Hagander wrote:
>> I think it's better to spool the log messages to files, and then let
>> the external utility read the files. The external utility can still
>> fall behind, but even if it does the cluster will continue running.
>
> The difficulty there is
Albe Laurenz wrote:
Dear hackers,
I have been thinking about ways to have PostgreSQL reject
weak passwords.
I think the standard recommendation is "use PAM and LDAP",
but that requires the user to change the password outside
of PostgreSQL. And who would want to setup and maintain an
LDAP serv
2009/9/28 Robert Haas :
> On Mon, Sep 28, 2009 at 5:22 AM, Magnus Hagander wrote:
>> On Sun, Sep 27, 2009 at 23:03, Robert Haas wrote:
>>> On Sun, Sep 27, 2009 at 4:54 PM, Peter Eisentraut wrote:
On Sun, 2009-09-27 at 16:15 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > Then
On Mon, Sep 28, 2009 at 5:22 AM, Magnus Hagander wrote:
> On Sun, Sep 27, 2009 at 23:03, Robert Haas wrote:
>> On Sun, Sep 27, 2009 at 4:54 PM, Peter Eisentraut wrote:
>>> On Sun, 2009-09-27 at 16:15 -0400, Tom Lane wrote:
Peter Eisentraut writes:
> Then why not send everything to sys
At 2009-09-12 13:17:50 -0400, and...@dunslane.net wrote:
>
> I have just noticed, somewhat to my chagrin, that while in a plperl
> function that returns an array type you can return a perl arrayref,
> like this:
>
>return [qw(a b c)];
>
> if the function returns a setof an array type you cannot
On 28 sep 2009, at 11.54, "Albe Laurenz"
wrote:
Dear hackers,
I have been thinking about ways to have PostgreSQL reject
weak passwords.
I think the standard recommendation is "use PAM and LDAP",
but that requires the user to change the password outside
of PostgreSQL. And who would want to
I removed hunks by sql_help.c and fix a typo in documentation.
An updated patch attached.
Brendan Jurd wrote:
> With the sql_help.c changes removed, the patch applied fine and
> testing went well.
>
> I noticed only the following in the new documentation in CREATE TABLE:
> - INCLUDING DEFA
Dear hackers,
I have been thinking about ways to have PostgreSQL reject
weak passwords.
I think the standard recommendation is "use PAM and LDAP",
but that requires the user to change the password outside
of PostgreSQL. And who would want to setup and maintain an
LDAP server just for this?
Since
> Sorry, I'm having trouble understanding what you're driving at here.
> I think we should just not allow named notation to be combined with
> VARIADIC, at least for a first version of this feature, either when
> defining a function or when calling one. We can consider relaxing
> that restriction
On Sun, Sep 27, 2009 at 23:03, Robert Haas wrote:
> On Sun, Sep 27, 2009 at 4:54 PM, Peter Eisentraut wrote:
>> On Sun, 2009-09-27 at 16:15 -0400, Tom Lane wrote:
>>> Peter Eisentraut writes:
>>> > Then why not send everything to syslog and have syslog filter it to the
>>> > places you want to?
; git://git.postgresql.org/git/users/heikki/postgres.git.
Further fixes extracted from above repository attached..
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
hs-riggs-branch-20090928.tar.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list
Thanks for your comments.
Jaime Casanova wrote:
> 2009/9/24 KaiGai Kohei :
>> The attached patch is revised from the previous revision at the following
>> points:
>>
>> - The "largeobject_compat_acl" is renamed to "largeobject_check_acl".
>> Its default is on, and turning it off means the largeo
At 2009-09-27 12:54:48 -0400, robertmh...@gmail.com wrote:
>
> If this patch looks good now, can you mark it Ready for Committer in
> the CommitFest app?
Done.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
On Sat, Aug 8, 2009 at 7:47 PM, Mark Kirkwood wrote:
>>>
>>>
>> Patch with max(wait time).
>>
>> Still TODO
>>
>> - amalgamate individual transaction lock waits
>> - redo (rather ugly) temporary pg_stat_lock_waits in a form more like
>> pg_locks
>>
> This version has the individual transaction loc
90 matches
Mail list logo
