Services are started with the system privileges. If somebody is able to
place that .exe in the specified directory, then it will be executed on
service start. So, yes, I too agree with Asif that it is an important issue
and should be fixed in the code at the earliest.
On Thu, Oct 31, 2013 at 11:1
On Thu, Oct 31, 2013 at 10:17 AM, Amit Kapila wrote:
> On Tue, Oct 29, 2013 at 12:46 PM, Naoya Anzai
> wrote:
> > Hi Sandeep
> >
> >> I think, you should change the subject line to "Unquoted service path
> containing space is vulnerable and can be exploited on Windows" to get the
> attention..
On Tue, Oct 29, 2013 at 12:46 PM, Naoya Anzai
wrote:
> Hi Sandeep
>
>> I think, you should change the subject line to "Unquoted service path
>> containing space is vulnerable and can be exploited on Windows" to get the
>> attention.. :)
> Thank you for advice!
> I'll try to post to pgsql-bugs
On Wed, Oct 16, 2013 at 1:44 AM, Amit Kapila wrote:
> On Tue, Oct 15, 2013 at 6:28 PM, Magnus Hagander wrote:
>> On Tue, Oct 15, 2013 at 2:55 PM, Robert Haas wrote:
>>> On Mon, Oct 14, 2013 at 1:30 PM, Tom Lane wrote:
> Well, that sucks. So it's a Windows bug.
>>
>> I agree we'll probably
On Wed, Oct 30, 2013 at 12:12 PM, Alvaro Herrera
wrote:
> Andres Freund escribió:
>> On 2013-10-30 10:52:05 -0300, Alvaro Herrera wrote:
>> > Robert Haas escribió:
>> > > On Wed, Oct 30, 2013 at 4:51 AM, David Rowley
>> > > wrote:
>> > > > I've attached a re-based version of this.
>> > >
>> > >
On Wed, Oct 30, 2013 at 9:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Oct 30, 2013 at 9:49 AM, Tom Lane wrote:
>>> If it *isn't* about the main memory segment, what the hell are we doing
>>> creating random addon segments during bootstrap? None of the DSM code
>>> should even get co
Robert Haas writes:
> On Wed, Oct 30, 2013 at 9:49 AM, Tom Lane wrote:
>> If it *isn't* about the main memory segment, what the hell are we doing
>> creating random addon segments during bootstrap? None of the DSM code
>> should even get control at this point, IMO.
> Here's a short summary of w
"MauMau" writes:
> From: "Tom Lane"
>> Yeah, but what shall we replace it with? And can we preserve the
>> API contrib/uuid-ossp offers? (Maybe we shouldn't even try, but
>> just deprecate that module and start fresh.)
> Would it be welcomed in this community if a patch for built-in UUID
> ge
On Wed, Oct 30, 2013 at 12:51 PM, Sergey Konoplev wrote:
> On Wed, Oct 30, 2013 at 12:17 PM, Alvaro Herrera
> wrote:
>>> > I wasn't talking about a built-in support. It was about an ability (a
>>> > way) to back sh_buf with hugepages.
>>>
>>> Then what you need is to set
>>> dynamic_shared_memory
Just a small patch; hopefully useful.
Best regards,
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterpriseDB Inc.
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index ccb8b86..48dc7af 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postma
From: "Tom Lane"
Alvaro Herrera writes:
At this point, I think we need to consider ossp-uuid as dead code.
Yeah, but what shall we replace it with? And can we preserve the
API contrib/uuid-ossp offers? (Maybe we shouldn't even try, but
just deprecate that module and start fresh.)
Would i
From: "Hiroshi Saito"
it my bug patch applied to ver 1.6.2sorry..
then, I made the next patch is there, please see,
http://winpg.jp/~saito/pg_work/OSSP_win32/
I will be adjusted and Ralf-san again.
Thanks. Yes, I wrote the wrong URL and meant this one. Is this patch
(uuid-1.6.2_win32_p
On Wed, Oct 30, 2013 at 12:17 PM, Alvaro Herrera
wrote:
>> > I wasn't talking about a built-in support. It was about an ability (a
>> > way) to back sh_buf with hugepages.
>>
>> Then what you need is to set
>> dynamic_shared_memory_type = sysv
>> in postgresql.conf.
>
> The above is mistaken -- th
Alvaro Herrera escribió:
> Sergey Konoplev escribió:
> > I wasn't talking about a built-in support. It was about an ability (a
> > way) to back sh_buf with hugepages.
>
> Then what you need is to set
> dynamic_shared_memory_type = sysv
> in postgresql.conf.
The above is mistaken -- there's no w
On Wed, Oct 30, 2013 at 11:50 AM, Alvaro Herrera
wrote:
>> >> There were an ability to back shared memory with hugepages when using
>> >> <=9.2. I use it on ~30 servers for several years and it brings 8-17%
>> >> of performance depending on the memory size. Here you will find
>> >> several paragra
Sergey Konoplev escribió:
> On Wed, Oct 30, 2013 at 8:11 AM, Tom Lane wrote:
> > Sergey Konoplev writes:
> >> There were an ability to back shared memory with hugepages when using
> >> <=9.2. I use it on ~30 servers for several years and it brings 8-17%
> >> of performance depending on the memor
On Wed, Oct 30, 2013 at 10:53 AM, Simon Riggs wrote:
> LSM-tree also covers the goal of maintaining just 2 sub-trees and a
> concurrent process of merging sub-trees. That sounds like it would
> take a lot of additional time to get right and would need some
> off-line process to perform the merge.
On 31/10/13 06:46, Jeff Janes wrote:
On Wed, Oct 30, 2013 at 9:54 AM, Leonardo Francalanci
mailto:m_li...@yahoo.it>> wrote:
Jeff Janes wrote
> The index insertions should be fast until the size of the active
part of
> the indexes being inserted into exceeds shared_buffers by som
On Wed, Oct 30, 2013 at 9:54 AM, Leonardo Francalanci wrote:
> Jeff Janes wrote
> > The index insertions should be fast until the size of the active part of
> > the indexes being inserted into exceeds shared_buffers by some amount
> > (what
> > that amount is would depend on how much dirty data th
On Wed, Oct 30, 2013 at 8:11 AM, Tom Lane wrote:
> Sergey Konoplev writes:
>> On Tue, Oct 29, 2013 at 9:31 PM, Tom Lane wrote:
>>> Say what? There's never been any hugepages support in Postgres.
>
>> There were an ability to back shared memory with hugepages when using
>> <=9.2. I use it on ~30
On 2013-10-30 22:39:20 +0530, Abhijit Menon-Sen wrote:
> At 2013-10-30 11:04:36 -0400, t...@sss.pgh.pa.us wrote:
> >
> > > As a compromise, perhaps we can unconditionally round the size up to be
> > > a multiple of 2MB? […]
> >
> > That sounds reasonably painless to me.
>
> Here's a patch that d
At 2013-10-30 11:04:36 -0400, t...@sss.pgh.pa.us wrote:
>
> > As a compromise, perhaps we can unconditionally round the size up to be
> > a multiple of 2MB? […]
>
> That sounds reasonably painless to me.
Here's a patch that does that and adds a DEBUG1 log message when we try
with MAP_HUGETLB and
Jeff Janes wrote
> You could periodically merge older partitions into larger tables, index
> those aggregated tables, then transactionally disinherit the old
> partitions
> and inherit the new aggregated one. This would keep the value of K down,
> at the expense of re-writing data multiple times (
Jeff Janes wrote
> Are partitions read-only once time has moved on, or can stragglers show up
> that need to be inserted into older partitions?
>
> You could periodically merge older partitions into larger tables, index
> those aggregated tables, then transactionally disinherit the old
> partition
> Point being: hardware is marching along pretty fast (after 20+ years
> of stagnation) and it's dangerous (IMO) to make big software
> investments based on the situation on the ground *today*.
Yes, that's a good point.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
On Wed, Oct 30, 2013 at 12:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> Yeah, I think that's probably what it is. There's PostmasterRandom()
>> to initialize the random-number generator on first use, but that
>> doesn't help if some other module calls random(). I wonder if we
>> ought to jus
Jeff Janes wrote
> The index insertions should be fast until the size of the active part of
> the indexes being inserted into exceeds shared_buffers by some amount
> (what
> that amount is would depend on how much dirty data the kernel is willing
> to
> allow in the page cache before it starts suff
On 10/30/2013 12:43 PM, Tom Lane wrote:
Alvaro Herrera writes:
At this point, I think we need to consider ossp-uuid as dead code.
Yeah, but what shall we replace it with? And can we preserve the
API contrib/uuid-ossp offers? (Maybe we shouldn't even try, but
just deprecate that module and s
On Wed, Oct 30, 2013 at 9:49 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2013-10-30 09:26:42 -0400, Tom Lane wrote:
>>> Isn't this complaining about the main shm segment, not a DSM extension?
>
>> Don't think so, that has a ":" in the name.
>
> If it *isn't* about the main memory segment, w
Robert Haas writes:
> Yeah, I think that's probably what it is. There's PostmasterRandom()
> to initialize the random-number generator on first use, but that
> doesn't help if some other module calls random(). I wonder if we
> ought to just get rid of PostmasterRandom() and instead have the
> po
Alvaro Herrera writes:
> At this point, I think we need to consider ossp-uuid as dead code.
Yeah, but what shall we replace it with? And can we preserve the
API contrib/uuid-ossp offers? (Maybe we shouldn't even try, but
just deprecate that module and start fresh.)
rega
Robert Haas writes:
> On Wed, Oct 30, 2013 at 9:26 AM, Tom Lane wrote:
>> Also, why is the error "not enough space", rather than something about
>> a collision? And if this is the explanation, why didn't the previous
>> runs probing for allowable shmem size fail?
> Good questions. I think that
On Wed, Oct 30, 2013 at 9:26 AM, Tom Lane wrote:
> Robert Haas writes:
>> If I'm reading this correctly, the last three runs on frogmouth have
>> all failed, and all of them have failed with a complaint about,
>> specifically, Global/PostgreSQL.851401618. Now, that really shouldn't
>> be happeni
On Wed, Oct 30, 2013 at 4:23 AM, Leonardo Francalanci wrote:
>
>
> 1) I haven't achieved what I need: realtime indexing. I can't query the
> "current 15 minutes" table efficiently. Plus, K*log(N) is not that great
> when you have a lot of K.
>
Are partitions read-only once time has moved on, or c
Hiroshi Saito escribió:
> Hi MauMau-san
>
> it my bug patch applied to ver 1.6.2sorry..
> then, I made the next patch is there, please see,
> http://winpg.jp/~saito/pg_work/OSSP_win32/
>
> I will be adjusted and Ralf-san again.
At this point, I think we need to consider ossp-uuid as dead cod
Andres Freund escribió:
> On 2013-10-30 10:52:05 -0300, Alvaro Herrera wrote:
> > Robert Haas escribió:
> > > On Wed, Oct 30, 2013 at 4:51 AM, David Rowley
> > > wrote:
> > > > I've attached a re-based version of this.
> > >
> > > I don't see any compelling reason not to commit this. Does anyon
On Wed, Oct 30, 2013 at 3:35 AM, Leonardo Francalanci wrote:
> > Presumably the data you are inserting isn't actually random. Please
> > describe the use case you are considering in more detail and some view
> > on how frequent that is, with some examples. Once we understand the
> > use case and a
On Wed, Oct 30, 2013 at 9:23 AM, Leonardo Francalanci wrote:
>> LSM-trees seem patent free
>
> I'm no expert, and I gave it just a look some time ago: it looked to me very
> complicated to get right... and as far as I remember you don't get that much
> gain, unless you go multi-level which would
Sergey Konoplev writes:
> On Tue, Oct 29, 2013 at 9:31 PM, Tom Lane wrote:
>> Say what? There's never been any hugepages support in Postgres.
> There were an ability to back shared memory with hugepages when using
> <=9.2. I use it on ~30 servers for several years and it brings 8-17%
> of perfo
Abhijit Menon-Sen writes:
> As a compromise, perhaps we can unconditionally round the size up to be
> a multiple of 2MB? That way, we can use huge pages more often, but also
> avoid putting in a lot of code and effort into the workaround and waste
> only a little space (if any at all).
That sound
On 30 October 2013 11:23, Leonardo Francalanci wrote:
>
> >> In terms of generality, do you think its worth a man year of developer
> >> effort to replicate what you have already achieved? Who would pay?
>
I work on an application that does exactly what Leonardo described. We hit
the exact same p
Hi MauMau-san
it my bug patch applied to ver 1.6.2sorry..
then, I made the next patch is there, please see,
http://winpg.jp/~saito/pg_work/OSSP_win32/
I will be adjusted and Ralf-san again.
best regards,
Hiroshi Saito
(2013/10/30 21:45), MauMau wrote:
> Hello,
>
> # Sorry, Saito san' addre
> LSM-trees seem patent free
I'm no expert, and I gave it just a look some time ago: it looked to me very
complicated to get right... and as far as I remember you don't get that much
gain, unless you go multi-level which would complicate things further
> Please somebody advise patent status of
On 2013-10-30 10:52:05 -0300, Alvaro Herrera wrote:
> Robert Haas escribió:
> > On Wed, Oct 30, 2013 at 4:51 AM, David Rowley wrote:
> > > I've attached a re-based version of this.
> >
> > I don't see any compelling reason not to commit this. Does anyone
> > wish to object?
>
> I think a blanke
On 30 October 2013 11:23, Leonardo Francalanci wrote:
>> What is the reason for needing such fast access to individual groups
>> of records? Sure sounds like the NSA or similar ;-)
>
>
> Users need to search all calls originated from/to a user or from/to a
> specific mobile phone to answer/analyz
Robert Haas escribió:
> On Wed, Oct 30, 2013 at 4:51 AM, David Rowley wrote:
> > I've attached a re-based version of this.
>
> I don't see any compelling reason not to commit this. Does anyone
> wish to object?
I think a blanket substitution of places that currently have %s might
cause bugs, pa
Andres Freund writes:
> On 2013-10-30 09:26:42 -0400, Tom Lane wrote:
>> Isn't this complaining about the main shm segment, not a DSM extension?
> Don't think so, that has a ":" in the name.
If it *isn't* about the main memory segment, what the hell are we doing
creating random addon segments du
On 2013-10-30 09:26:42 -0400, Tom Lane wrote:
> Robert Haas writes:
> > If I'm reading this correctly, the last three runs on frogmouth have
> > all failed, and all of them have failed with a complaint about,
> > specifically, Global/PostgreSQL.851401618. Now, that really shouldn't
> > be happeni
Robert Haas writes:
> If I'm reading this correctly, the last three runs on frogmouth have
> all failed, and all of them have failed with a complaint about,
> specifically, Global/PostgreSQL.851401618. Now, that really shouldn't
> be happening, because the code to choose that number looks like th
On Wed, Oct 30, 2013 at 4:51 AM, David Rowley wrote:
> I've attached a re-based version of this.
I don't see any compelling reason not to commit this. Does anyone
wish to object?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hac
On Wed, Oct 30, 2013 at 8:47 AM, Andres Freund wrote:
> On 2013-10-30 08:45:03 -0400, Robert Haas wrote:
>> If I'm reading this correctly, the last three runs on frogmouth have
>> all failed, and all of them have failed with a complaint about,
>> specifically, Global/PostgreSQL.851401618. Now, th
On Wed, Oct 30, 2013 at 8:22 AM, Robert Haas wrote:
> I find it hard to believe this is the right fix. I know we have
> similar code in win32_shmem.c, but surely if size is a 32-bit unsigned
> quantity then size >> 0 is simply 0 anyway.
Gosh, I stand corrected. According to
http://msdn.microsof
On 2013-10-30 08:45:03 -0400, Robert Haas wrote:
> If I'm reading this correctly, the last three runs on frogmouth have
> all failed, and all of them have failed with a complaint about,
> specifically, Global/PostgreSQL.851401618. Now, that really shouldn't
> be happening, because the code to choo
On Tue, Oct 29, 2013 at 3:12 PM, Tom Lane wrote:
> The last two buildfarm runs on frogmouth have failed in initdb,
> like this:
>
> creating directory
> d:/mingw-bf/root/HEAD/pgsql.2492/src/test/regress/./tmp_check/data ... ok
> creating subdirectories ... ok
> selecting default max_connections .
Hello,
# Sorry, Saito san' address doesn't seem to exist, so excuse for sending
again
For a certain reason, I need to build PostgreSQL on Windows with OSSP UUID
support to use UUID for primary keys. I have to use Visual Studio 2010.
The original source code for OSSP UUID and its fork for W
Hello,
For a certain reason, I need to build PostgreSQL on Windows with OSSP UUID
support to use UUID for primary keys. I have to use Visual Studio 2010.
The original source code for OSSP UUID and its fork for Windows can be
downloaded from:
http://www.ossp.org/pkg/lib/uuid/
http://sourcef
On Wed, Oct 30, 2013 at 1:22 AM, Amit Kapila wrote:
> On Wed, Oct 30, 2013 at 12:42 AM, Tom Lane wrote:
>> The last two buildfarm runs on frogmouth have failed in initdb,
>> like this:
>>
>> creating directory
>> d:/mingw-bf/root/HEAD/pgsql.2492/src/test/regress/./tmp_check/data ... ok
>> creati
On Wed, Oct 30, 2013 at 8:22 AM, Robert Haas wrote:
> On Wed, Oct 30, 2013 at 1:22 AM, Amit Kapila wrote:
>> On Wed, Oct 30, 2013 at 12:42 AM, Tom Lane wrote:
>>> The last two buildfarm runs on frogmouth have failed in initdb,
>>> like this:
>>>
>>> creating directory
>>> d:/mingw-bf/root/HEAD/
On 2013-10-30 12:08, Simon Riggs wrote:
effort to replicate what you have already achieved? Who would pay?
The NSA, obviously ;-)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> What is the reason for needing such fast access to individual groups
> of records? Sure sounds like the NSA or similar ;-)
Users need to search all calls originated from/to a user or from/to a specific
mobile phone to answer/analyze customers' probl... ok, I give up: I work for
the NSA ;)
>
On 30 October 2013 10:35, Leonardo Francalanci wrote:
>> Presumably the data you are inserting isn't actually random. Please
>> describe the use case you are considering in more detail and some view
>> on how frequent that is, with some examples. Once we understand the
>> use case and agree it is
> Presumably the data you are inserting isn't actually random. Please
> describe the use case you are considering in more detail and some view
> on how frequent that is, with some examples. Once we understand the
> use case and agree it is important, we might solve problems.
Collecting calls data
On 30 October 2013 07:55, Leonardo Francalanci wrote:
>> Hmm, you realise Alvaro is working on MinMax indexes in this release?
>> They are very efficient with regard to index inserts and specially
>> designed for use on large tables.
>>
>> Prior work by Heikki on Grouped Item Tuples was a way of r
On Mon, Sep 30, 2013 at 10:10 PM, David Rowley wrote:
> On Sat, Sep 28, 2013 at 9:44 PM, David Rowley wrote:
>
>> I did some benchmarking earlier in the week for the new patch which was
>> just commited to allow formatting in the log_line_prefix string. In version
>> 0.4 of the patch there was so
> Hmm, you realise Alvaro is working on MinMax indexes in this release?
> They are very efficient with regard to index inserts and specially
> designed for use on large tables.
>
> Prior work by Heikki on Grouped Item Tuples was a way of reducing the
> size of indexes, yet still allowing uniquenes
At 2013-10-30 00:10:39 -0700, da...@fetter.org wrote:
>
> How about documenting that 2MB is the quantum (OK, we'll say
> "indivisible unit" or "smallest division" or something) and failing
> with a message to that effect if someone tries to set it otherwise?
I don't think you understand the proble
On Wed, Oct 30, 2013 at 10:16:57AM +0530, Abhijit Menon-Sen wrote:
> At 2013-10-24 16:06:19 +0300, hlinnakan...@vmware.com wrote:
> >
> > Let's get rid of the rounding.
>
> I share Andres's concern that the bug is present in various recent
> kernels that are going to stick around for quite some ti
On Tue, Oct 29, 2013 at 11:08:05PM -0700, Sergey Konoplev wrote:
> On Tue, Oct 29, 2013 at 9:31 PM, Tom Lane wrote:
> > Sergey Konoplev writes:
> >> On Wed, Oct 23, 2013 at 11:03 PM, Abhijit Menon-Sen
> >> wrote:
> >>> This is a slightly reworked version of the patch submitted by Richard
> >>>
68 matches
Mail list logo
