> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> "Etsuro Fujita" writes:
> > As described in the reference manual for COPY, we should to check file's
path
> > format not to allow relative path. Please find attached a patch.
>
> The argument for disallowing writing to a relative path is to make it
I hope it's not too late for another reviewer to pitch in :) I have let
some time pass between previous reviews so that I can give this patch a
fresh look, and not be tainted by what the other reviews said, so I may be
repeating a few things already covered by other reviewers. I haven't
performed a
Hello
I can reassign it again
Regards
Pavel
2012/8/16 Bruce Momjian :
>
> What ever happened to this patch? I don't see it on any of the
> commit-fests, though someone was asked for it to be added:
>
> http://archives.postgresql.org/pgsql-hackers/2011-10/msg00381.php
>
> --
What ever happened to this patch? I don't see it on any of the
commit-fests, though someone was asked for it to be added:
http://archives.postgresql.org/pgsql-hackers/2011-10/msg00381.php
---
On Tue, Oct 4, 2011 a
On Mon, Nov 14, 2011 at 04:19:30PM -0600, Ross Reedstrom wrote:
> On Wed, Sep 28, 2011 at 11:47:51AM -0700, David Fetter wrote:
> > On Wed, Sep 28, 2011 at 02:25:44PM -0400, Gurjeet Singh wrote:
> > > On Wed, Sep 28, 2011 at 1:51 PM, Kevin Grittner
> > > > > > wrote:
> > >
> > > > Alvaro Herrera
On Wed, Sep 14, 2011 at 02:40:15AM +0100, Thom Brown wrote:
> On 13 September 2011 15:17, Tom Lane wrote:
> > Thom Brown writes:
> >> There appears to be a problem with starting Postgres if the SSL key
> >> has a passphrase on it.
> >
> > It's documented that that's unsupported. Given the number
On Tue, Sep 13, 2011 at 10:32:01AM -0400, Aidan Van Dyk wrote:
> On Tue, Sep 13, 2011 at 10:14 AM, Florian Pflug wrote:
>
> >> Personally, I'ld think that's ripe for bugs. If the contract is that
> >> ret != amount is the "error" case, then don't return -1 for an error
> >> *sometimes*.
> >
> >
Are there any TODO items here?
---
On Mon, Sep 12, 2011 at 09:36:02PM +0300, Peter Eisentraut wrote:
> Isn't the naming of the xlog files slightly bogus?
>
> We have the following sequence:
>
> 000108D000FD
> 0
Merlin Moncure writes:
> If you create an index like this:
> create index on foo(a,b,v) where d = some_constant;
> there is no way to get an IOS on the index: you have to supply a the
> partial index exclusionary value to get the value of the index and
> that fools the IOS chooser because it doesn
On Wed, Aug 15, 2012 at 06:42:51PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > [ moved to hackers]
>
> > Would someone review this report for me? I think there are few
> > reasonable changes in here, but I am not familiar enough with all the
> > code areas.
>
> >> ===
Bruce Momjian writes:
> [ moved to hackers]
> Would someone review this report for me? I think there are few
> reasonable changes in here, but I am not familiar enough with all the
> code areas.
I see one place where we forgot to sync a comment, but otherwise this
all looks OK. Details below .
On Wed, Sep 7, 2011 at 01:20:17AM +0300, Ants Aasma wrote:
> On Tue, Sep 6, 2011 at 10:18 PM, Alvaro Herrera
> wrote:
> > I wonder what happens if files in the same subdir are grouped in a
> > subgraph. Is that possible?
>
> Possible, and done. Also added possivility to add .c files to the grap
If you create an index like this:
create index on foo(a,b,v) where d = some_constant;
there is no way to get an IOS on the index: you have to supply a the
partial index exclusionary value to get the value of the index and
that fools the IOS chooser because it doesn't see the value in the
explicit
Has this been addressed? A TODO?
---
On Tue, Sep 6, 2011 at 09:49:39AM -0400, Robert Haas wrote:
> On Tue, Sep 6, 2011 at 9:45 AM, Heikki Linnakangas
> wrote:
> >> Do you really need to hold the page locks for all that ti
[ moved to hackers]
Would someone review this report for me? I think there are few
reasonable changes in here, but I am not familiar enough with all the
code areas.
---
On Tue, Aug 30, 2011 at 07:15:19AM +, Ding Yuan w
I assume we want to apply this patch based on discussion that we should
allow a wider range of date/time formats.
---
On Mon, Aug 29, 2011 at 06:40:07PM +0100, Dean Rasheed wrote:
> On 29 August 2011 15:40, Andrew Dunstan w
On Wed, Aug 15, 2012 at 4:48 PM, Tom Lane wrote:
> Marko Kreen writes:
>> On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian wrote:
>>> Is there a TODO here?
>
>> There is still open ToDecide here: [snip]
>
> The argument against moving crypto code into core remains the same as it
> was, ie export r
On Aug 15, 2012, at 11:31 AM, Fabrízio de Royes Mello wrote:
>> Is there any reason not to add $subject? Would it be difficult?
>
> Looking to the source code I think this feature isn't hard to implement...
> I'm writing a little path to do that and I'll send soon...
Cool, thanks!
David
--
I looked into the misbehavior reported by Adam Mackler in
http://archives.postgresql.org/pgsql-bugs/2012-08/msg00073.php
What it seems to boil down to is a design error in ExecReScanCteScan.
Given the query
WITH RECURSIVE
tab(id_key,link) AS ( VALUES (1,17), (2,17), (3,17), (4,17), (6,17), (5,17)
2012/8/15 David E. Wheeler
> Hackers,
>
> Is there any reason not to add $subject? Would it be difficult?
Looking to the source code I think this feature isn't hard to implement...
I'm writing a little path to do that and I'll send soon...
> Would save me having to write a DO statement every
Hackers,
Is there any reason not to add $subject? Would it be difficult? Would save me
having to write a DO statement every time I needed it (which in migration
scripts is fairly often).
Thanks,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
I will do the profiling and present the results.
On Wed, 2012-08-15 at 12:45 -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Is this a TODO?
>
> AFAIR nothing's been done about the speed issue, so yes. I didn't
> like the idea of creating a user-visible knob when the speed issue
> might be f
Bruce Momjian writes:
> Is this a TODO?
AFAIR nothing's been done about the speed issue, so yes. I didn't
like the idea of creating a user-visible knob when the speed issue
might be fixable with internal algorithm improvements, but we never
followed up on this in either fashion.
Alexander Korotkov writes:
> Ok, we've to decide if we need "standard" histogram. In some cases it can
> be used for more accurate estimation of < and > operators.
> But I think it is not so important. So, we can replace "standard" histogram
> with histograms of lower and upper bounds?
You should
This might indicate that the hlCover() item is resolved.
---
On Wed, Aug 24, 2011 at 10:08:11AM +0530, Sushant Sinha wrote:
>
>
> Actually, this code seems probably flat-out wrong: won't every
> successful call of
On Wed, Aug 15, 2012 at 09:18:48AM -0700, Joe Conway wrote:
> The final problem as you stated is weak passwords and some kind of
> dictionary attack against a stolen set of tokens and HMACs. Didn't we
> add a hook some time ago for user provided password checker?
Yes, contrib/passwordcheck:
Is this a TODO?
---
On Tue, Aug 23, 2011 at 10:31:42PM -0400, Tom Lane wrote:
> Sushant Sinha writes:
> >> Doesn't this force the headline to be taken from the first N words of
> >> the document, independent of where the ma
On 08/15/2012 08:49 AM, Merlin Moncure wrote:
> 1) allow use hmac as you suggest (but this forces user to maintain
> additional password or some token)
Not really. You would store a token and the HMAC of the token using the
user password on the server side. You would need access to the hash
functi
On 08/15/2012 11:48 AM, Bruce Momjian wrote:
On Wed, Aug 15, 2012 at 11:37:04AM -0400, Andrew Dunstan wrote:
On 08/15/2012 11:22 AM, Joe Conway wrote:
On 08/15/2012 06:48 AM, Tom Lane wrote:
On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian wrote:
Is there a TODO here?
If anybody's concerned
Peter Geoghegan writes:
> I'm not quite comfortable recommending a switch to milliseconds if
> that implies a loss of sub-millisecond granularity. I know that
> someone is going to point out that in some particularly benchmark,
> they can get another relatively modest increase in throughput (perha
On Wed, Aug 15, 2012 at 10:22 AM, Joe Conway wrote:
> On 08/15/2012 06:48 AM, Tom Lane wrote:
>>> On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian wrote:
Is there a TODO here?
>>
>> If anybody's concerned about the security of our password storage,
>> they'd be much better off working on impro
On Wed, Aug 15, 2012 at 11:37:04AM -0400, Andrew Dunstan wrote:
>
> On 08/15/2012 11:22 AM, Joe Conway wrote:
> >On 08/15/2012 06:48 AM, Tom Lane wrote:
> >>>On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian wrote:
> Is there a TODO here?
> >>If anybody's concerned about the security of our pass
On 08/15/2012 11:22 AM, Joe Conway wrote:
On 08/15/2012 06:48 AM, Tom Lane wrote:
On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian wrote:
Is there a TODO here?
If anybody's concerned about the security of our password storage,
they'd be much better off working on improving the length and rando
On 15 August 2012 14:39, Tom Lane wrote:
> If you wanted to re-implement all the guc.c logic for supporting
> unit-ified values such that it would also work with floats, we could
> do that. It seems like way more mechanism than the problem is worth
> however.
Fair enough.
I'm not quite comforta
On Mon, Aug 15, 2011 at 01:03:35PM +0200, Magnus Hagander wrote:
> The pg_stat_replication view exposes all the fields in
> StandbyReplyMessage *except* for the timestamp when the message was
> generated. On an active system this is not all that interesting, but
> on a mostly idle system that allow
On 08/15/2012 06:48 AM, Tom Lane wrote:
>> On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian wrote:
>>> Is there a TODO here?
>
> If anybody's concerned about the security of our password storage,
> they'd be much better off working on improving the length and randomness
> of the salt string than re
"Etsuro Fujita" writes:
> As described in the reference manual for COPY, we should to check file's path
> format not to allow relative path. Please find attached a patch.
The argument for disallowing writing to a relative path is to make it
harder to accidentally overwrite a database file. That
Marko Kreen writes:
> On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian wrote:
>> Is there a TODO here?
> There is still open ToDecide here: [snip]
The argument against moving crypto code into core remains the same as it
was, ie export regulations. I don't see that that situation has changed
at a
Peter Geoghegan writes:
> Why does commit_delay have to be an integer? Can't we devise a way of
> manipulating it in units of milliseconds, but have the internal
> representation be a double, as with pg_stat_statements' total_time
> column?
If you wanted to re-implement all the guc.c logic for su
On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian wrote:
> Is there a TODO here?
There is still open ToDecide here:
1) Status quo - md5() in core, everything else in pgcrypto
2) Start moving other hashes as separate functions into core: eg. sha1()
Problems:
- sha1 will be obsolete soon, like md5
-
On 15 August 2012 05:15, Tom Lane wrote:
> Peter Geoghegan writes:
>> On 14 August 2012 21:26, Bruce Momjian wrote:
>>> Revert "commit_delay" change; just add comment that we don't have
>>> a microsecond specification.
>
>> I think that if we eventually decide to change the name of
>> commit_del
As described in the reference manual for COPY, we should to check file's path
format not to allow relative path. Please find attached a patch.
Thanks,
Best regards,
Etsuro Fujita
copy_from_pathcheck.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On Wed, Aug 15, 2012 at 12:14 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> Histogram of upper bounds would be both more
>> accurate and natural for some operators. However, it requires collecting
>> additional statistics while AFAICS it doesn't liberate us from having
>>
On 15.08.2012 10:38, Alexander Korotkov wrote:
On Tue, Aug 14, 2012 at 7:46 PM, Heikki Linnakangas<
heikki.linnakan...@enterprisedb.com> wrote:
It would be quite easy to provide reasonable estimates for those
operators, if we had a separate histogram of upper bounds. I also note that
the estim
On Tue, Aug 14, 2012 at 7:46 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> On 14.08.2012 09:45, Alexander Korotkov wrote:
>
>> After fixing few more bugs, I've a version with much more reasonable
>> accuracy.
>>
>
> Great! One little thing just occurred to me:
>
> You're r
45 matches
Mail list logo
