On Tue, Aug 5, 2014 at 6:25 PM, Fujii Masao wrote:
>
>
> This gradual approach looks good to me. And, if the additional compression
> algorithm like lz4 is always better than pglz for every scenarios, we can
> just
> change the code so that the additional algorithm is always used. Which
> would
>
On Tue, Jul 29, 2014 at 9:26 PM, Amit Kapila wrote:
> On Mon, Jul 28, 2014 at 11:33 PM, Fujii Masao wrote:
>> There is other side effect on this patch. With the patch, when reloading
>> the configurartion file, the server cannot warm an invalid setting value
>> if it's not the last setting of the
> > - break; /* ignore
> the rest of this XLogData packet */
> >
> > + return true;/* ignore the rest of
> this XLogData packet */
> >
> > For break statement at close of wal file, it is a return to true.
> > It may be
Hi,
It is pretty annoying that pgbench does not check parameter which
should not be used with -i. I often type like:
pgbench -c 10 -T 300 -S -i test
and accidentally initialize pgbench database. This is pretty
uncomfortable if the database is huge since initializing huge database
takes long time
On Tue, Aug 5, 2014 at 9:21 PM, Robert Haas wrote:
> On Thu, Jun 5, 2014 at 4:43 AM, Amit Kapila
wrote:
> This essentially removes BgWriterDelay, but it's still mentioned in
BgBufferSync(). Looking further, I see that with the patch applied,
BgBufferSync() is still present in the source code but
(2014/07/01 11:10), Etsuro Fujita wrote:
> (2014/06/30 22:48), Tom Lane wrote:
>> Etsuro Fujita writes:
>>> Done. I think this is because create_foreignscan_plan() makes reference
>>> to attr_needed, which isn't computed for inheritance children.
>>
>> I wonder whether it isn't time to change tha
On Tue, Aug 5, 2014 at 7:05 AM, Ashutosh Bapat
wrote:
> There are quite a few members added to the generic Path, Plan structures,
> whose use is is induced only through foreign scans. Each path now stores two
> sets of costs, one with parallelism and one without. The parallel values
> will make se
On Wed, Aug 6, 2014 at 5:10 PM, wrote:
>> > - break; /* ignore
>> the rest of this XLogData packet */
>> >
>> > + return true;/* ignore the rest of
>> this XLogData packet */
>> >
>> > For break statement at close of
Hi hackers,
Attached is a patch to add support for PGP signatures in encrypted
messages into pgcrypto.
Currently, the list of limitations is the following:
- It only knows how to generate one signature per message. I don't
see that as a problem.
- If a message has been signed with m
If so, adding some randomness in the decision process would suffice to
counter the adversarial input argument you raised.
This is specifically addressed by the paper. Indeed, randomly choosing
a pivot is a common strategy. It won't fix the problem.
Too bad. I must admit that I do not see how
Included is the patch to enhance the behavior of pgbench in this regard
IMO. Here is a sample session after patching:
$ ./pgbench -c 10 -T 300 -S -i test
some parameters cannot be used in initialize mode
I have not tested, but the patch looks ok in principle.
I'm not sure of the variable na
Three different modulo operators seems like a lot for a language that
doesn't even have a real expression syntax, but I'll yield to whatever
the consensus is on this one.
Here is a third simpler patch which only implements the Knuth's modulo,
where the remainder has the same sign as the divis
On Wed, Aug 6, 2014 at 6:12 AM, Amit Kapila wrote:
>> If I'm reading this right, the new statistic is an incrementing counter
>> where, every time you update it, you add the number of buffers currently on
>> the freelist. That makes no sense.
>
> I think using 'number of buffers currently on the
On Wed, Aug 6, 2014 at 06:48:55AM +0100, Simon Riggs wrote:
> On 6 August 2014 03:16, Bruce Momjian wrote:
> > On Wed, Aug 6, 2014 at 09:17:35AM +0900, Michael Paquier wrote:
> >> On Wed, Aug 6, 2014 at 9:04 AM, Simon Riggs wrote:
> >> >
> >> > On 5 August 2014 22:38, Claudio Freire wrote:
> >
On Wed, Aug 6, 2014 at 12:12:29AM -0300, Fabrízio de Royes Mello wrote:
>
> On Tue, Aug 5, 2014 at 10:55 PM, Tom Lane wrote:
>
> Josh Berkus writes:
> > BTW, while there's unlikely to be a good reason to put search_path in
> > pg.conf with appends, there are a LOT of reasons to wan
On Tue, Aug 5, 2014 at 6:05 PM, Jeff Janes wrote:
> I think you missed one of the regression tests, see attached
Woops. Thanks, committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On Sat, Aug 2, 2014 at 4:40 PM, Jeff Davis wrote:
> Attached is a patch that explicitly tracks allocated memory (the blocks,
> not the chunks) for each memory context, as well as its children.
>
> This is a prerequisite for memory-bounded HashAgg, which I intend to
> submit for the next CF. Hashjo
FYI, I have kept this email from 2011 about poor performance of parsed
words in headline generation. If someone wants to research it, please
do so:
http://www.postgresql.org/message-id/1314117620.3700.12.camel@dragflick
---
On Tue, Aug 5, 2014 at 7:55 PM, Josh Berkus wrote:
> On 08/05/2014 04:41 PM, Alvaro Herrera wrote:
>> I have chosen to keep the name "minmax", even if the opclasses now let
>> one implement completely different things on top of it such as geometry
>> bounding boxes and bloom filters (aka bitmap in
On Tue, Aug 5, 2014 at 5:53 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Mon, Aug 4, 2014 at 5:20 AM, Fabien COELHO wrote:
>> >> This patch is pretty trivial.
>> > Another slightly less trivial but more useful version.
>> >
>> > The issue is that there are 3 definitions of modulo, two of
On Wed, Aug 6, 2014 at 12:20 PM, Bruce Momjian wrote:
>
> Well, for file-level backups we have:
>
> 1) use file modtime (possibly inaccurate)
> 2) use file modtime and checksums (heavy read load)
>
> For block-level backups we have:
>
> 3) accumulate block numbers as WAL is
I'm very new to Postgres, but have plenty of experience developing stored
procs in Oracle.
I'm going to be creating Postgres stored procedures (functions actually,
since I discovered that in postgres, everything is a function) to do a
variety of batch-type processing. These functions may or may
I just browsed the paper linked by Peter and it looks like the attack has
to be active against a currently executing qsort. In the paper, what
happens is the comparison function is supplied by the attacker and
effectively lies about the result of a comparison. It keeps the lies
consistent in a very
Bill,
* Bill Epstein (epste...@us.ibm.com) wrote:
[...]
This should really go to the -general mailing list. The -hackers
mailing list is for discussion regarding developing the PostgreSQL
server itself.
Thanks!
Stephen
signature.asc
Description: Digital signatur
On Wed, Aug 6, 2014 at 01:15:32PM -0300, Claudio Freire wrote:
> On Wed, Aug 6, 2014 at 12:20 PM, Bruce Momjian wrote:
> >
> > Well, for file-level backups we have:
> >
> > 1) use file modtime (possibly inaccurate)
> > 2) use file modtime and checksums (heavy read load)
> >
> > Fo
On Wed, Aug 6, 2014 at 1:25 PM, Alvaro Herrera wrote:
> "Summary" seems good. If I get enough votes I can change it to that.
>
> CREATE INDEX foo ON t USING summary (cols)
>
> "Summarizing" seems weird on that command. Not sure about "compressed
> range", as you would have to use an abbreviation
On Wed, Aug 6, 2014 at 01:31:14PM -0300, Claudio Freire wrote:
> On Wed, Aug 6, 2014 at 1:25 PM, Alvaro Herrera
> wrote:
> > CREATE INDEX foo ON t USING crange (cols) -- misspelling of "cringe"?
> > CREATE INDEX foo ON t USING comprange (cols)
> > CREATE INDEX foo ON t USING compressedrng (col
On Wed, Aug 6, 2014 at 1:25 PM, Alvaro Herrera wrote:
> CREATE INDEX foo ON t USING crange (cols) -- misspelling of "cringe"?
> CREATE INDEX foo ON t USING comprange (cols)
> CREATE INDEX foo ON t USING compressedrng (cols) -- ugh
> -- or use an identifier with whitespace:
> CREATE INDEX foo O
On Wed, Aug 6, 2014 at 1:35 PM, Bruce Momjian wrote:
> On Wed, Aug 6, 2014 at 01:31:14PM -0300, Claudio Freire wrote:
>> On Wed, Aug 6, 2014 at 1:25 PM, Alvaro Herrera
>> wrote:
>> > CREATE INDEX foo ON t USING crange (cols) -- misspelling of "cringe"?
>> > CREATE INDEX foo ON t USING compran
On Fri, Nov 29, 2013 at 02:04:10AM +, Greg Stark wrote:
> Attached is what I have so far. I have to say I'm starting to come
> around to Tom's point of view. This is a lot of hassle for not much
> gain. i've noticed a number of other overflow checks that the llvm
> optimizer is not picking up o
On Wed, Aug 6, 2014 at 1:55 PM, Alvaro Herrera wrote:
> Claudio Freire wrote:
>> On Wed, Aug 6, 2014 at 1:25 PM, Alvaro Herrera
>> wrote:
>> > CREATE INDEX foo ON t USING crange (cols) -- misspelling of "cringe"?
>> > CREATE INDEX foo ON t USING comprange (cols)
>> > CREATE INDEX foo ON t USIN
Seems we still have not addressed this.
---
On Sat, May 25, 2013 at 10:18:57AM +0100, Simon Riggs wrote:
> On 21 May 2013 19:16, Fujii Masao wrote:
>
> > We cannot run parallel pg_dump on the standby server because
> > pg_
On Fri, Aug 1, 2014 at 10:58 AM, Heikki Linnakangas wrote:
> On 07/08/2014 08:11 PM, Jeff Janes wrote:
>
>> Is there some recipe for testing the 0002 patch? Can it be tested on an
>> MinGW environment, or does it need to use the MicroSoft supplied
>> compilers?
>>
>
> I used MSVC. It ought to wo
Hi,
The WAL files that pg_receivexlog writes will not be re-read soon basically,
so we can advise the OS to release any cached pages when WAL file is
closed. I feel inclined to change pg_receivexlog that way. Thought?
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hack
On Wed, Aug 6, 2014 at 9:18 AM, John Cochran wrote:
> So it seems to me that the vulnerability only exits if an attacker supplied
> comparison function is permitted. For all other cases, assuming that only
> vetted comparison functions are permitted, the selection of a random pivot
> would make an
On 2.8.2014 22:40, Jeff Davis wrote:
> Attached is a patch that explicitly tracks allocated memory (the blocks,
> not the chunks) for each memory context, as well as its children.
>
> This is a prerequisite for memory-bounded HashAgg, which I intend to
Anyway, I'm really looking forward to the me
On Wed, Aug 6, 2014 at 1:39 PM, Fujii Masao wrote:
> The WAL files that pg_receivexlog writes will not be re-read soon basically,
> so we can advise the OS to release any cached pages when WAL file is
> closed. I feel inclined to change pg_receivexlog that way. Thought?
How do we know that the us
On 08/06/2014 08:39 PM, Fujii Masao wrote:
Hi,
The WAL files that pg_receivexlog writes will not be re-read soon basically,
so we can advise the OS to release any cached pages when WAL file is
closed. I feel inclined to change pg_receivexlog that way. Thought?
-1. The OS should be smart enough
Random pivot selection will certainly result in more frequent lopsided
partitions without any malicious intent.
Yep. It makes "adversary input" attacks more or less impossible, at the
price of higher average cost. Maybe a less randomized version would do,
i.e. select randomly one of the "3"
Maybe we ought to break down and support a real expression syntax.
Sounds like that would be better all around.
Adding operators is more or less orthogonal with providing a new
expression syntax. I'm not sure that there is currently a crying need for
it (a syntax). It would be a significant
Hi
I returned to this issue and maybe I found a root issue. It is PL/pgSQL
implicit IO cast
Original text:
postgres=# DO LANGUAGE plpgsql $$ DECLARE n real;
DECLARE f integer;
BEGIN
FOR f IN 1..1000 LOOP
if 0=0 then
n = SQRT (f);
end if;
END LOOP;
RAISE NOTICE 'Result => %',n;
END $$;
NOTICE
Hi
this code is +/- equal to Oracle (it should be eliminate a useless code)
postgres=# DO LANGUAGE plpgsql $$ DECLARE n real;
DECLARE f integer;
BEGIN
FOR f IN 1..1000 LOOP
--if 0=0 then
n = SQRT (f)::real;
--end if;
END LOOP;
RAISE NOTICE 'Result => %',n;
END $$;
NOTICE: Result => 3162.28
D
2014-08-06 Claudio Freire :
> So, I like blockfilter a lot. I change my vote to blockfilter ;)
+1 for blockfilter, because it stresses the fact that the "physical"
arrangement of rows in blocks matters for this index.
Nicolas
--
A. Because it breaks the logical sequence of discussion.
Q. Why i
> "ST" == Shaun Thomas writes:
ST> That said, the documentation here says FLOAT4 is an alias for REAL,
ST> so it's somewhat nonintuitive for FLOAT4 to be so much slower than
ST> FLOAT8, which is an alias for DOUBLE PRECISION.
There are some versions of glibc where doing certain math on doubl
On Tue, Aug 5, 2014 at 3:54 PM, Peter Geoghegan wrote:
> On Tue, Aug 5, 2014 at 12:33 PM, Robert Haas wrote:
>> Per your other email, here's the patch again; hopefully I've got the
>> right stuff in the file this time.
>
> Your patch looks fine to me. I recommend committing patch 1 with these
> a
On Wed, Aug 6, 2014 at 2:36 AM, Fujii Masao wrote:
> On Wed, Aug 6, 2014 at 4:47 AM, Robert Haas wrote:
>> On Mon, Aug 4, 2014 at 11:35 AM, Manuel Kniep wrote:
>>> I’m missing the PG_RETURN_UINT16 macro in fmgr.h
>>> Since we already have the PG_GETARG_UINT16 macro
>>> I guess it makes sense to
2014-08-06 22:07 GMT+02:00 James Cloos :
> > "ST" == Shaun Thomas writes:
>
> ST> That said, the documentation here says FLOAT4 is an alias for REAL,
> ST> so it's somewhat nonintuitive for FLOAT4 to be so much slower than
> ST> FLOAT8, which is an alias for DOUBLE PRECISION.
>
> There are so
On 08/01/2014 10:58 AM, Anastasia Lubennikova wrote:
Hi, hackers!
I work on a GSoC project "Index-only scans for GIST"
https://wiki.postgresql.org/wiki/Support_for_Index-only_scans_for_GIST_GSoC_2014
Repository is
https://github.com/lubennikovaav/postgres/tree/indexonlygist2
Patch is in attachme
Any progress on this?
---
On Sat, Nov 30, 2013 at 12:43:39PM -0500, Tom Lane wrote:
> In our fine manual, at
> http://www.postgresql.org/docs/devel/static/typeconv-union-case.html
> it's claimed that the nontrivial parts of
Tom Lane-2 wrote
> In our fine manual, at
> http://www.postgresql.org/docs/devel/static/typeconv-union-case.html
> it's claimed that the nontrivial parts of UNION type resolution
> work like this:
>
> 4. Choose the first non-unknown input type which is a preferred type in
> that category, if t
Hello
updated version patch in attachment
2014-08-05 13:31 GMT+02:00 Fujii Masao :
> On Wed, Jul 16, 2014 at 4:34 AM, Pavel Stehule
> wrote:
> >
> >
> >
> > 2014-07-15 12:07 GMT+02:00 Fujii Masao :
> >
> >> On Tue, Jul 15, 2014 at 7:01 PM, Pavel Stehule >
> >> wrote:
> >> >
> >> >
> >> >
> >>
On 7/21/14, 10:56 PM, I wrote:
Here's a patch which allows you to notice those annoying bugs with INTO
slightly more quickly. Adding to the next commit phest.
New version, fixed bugs with set operations and VALUES lists.
.marko
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
On Wed, Aug 6, 2014 at 1:11 PM, Robert Haas wrote:
> I've committed the patch I posted yesterday. I did not see a good
> reason to meld that together in a single commit with the first of the
> patches you posted; I'll leave you to revise that patch to conform
> with this approach.
Okay. Attached
On Wed, Aug 6, 2014 at 8:35 AM, Robert Haas wrote:
> On Tue, Aug 5, 2014 at 6:05 PM, Jeff Janes wrote:
> > I think you missed one of the regression tests, see attached
>
> Woops. Thanks, committed.
>
Thanks.
It needs to go into 9_4_STABLE as well.
Cheers,
Jeff
On Tue, Aug 5, 2014 at 8:55 PM, Noah Misch wrote:
>> However, with work_mem set low enough to get an external sort, the
>> difference is more interesting. If I set work_mem to 10 MB, then the
>> query takes about 10.7 seconds to execute with a suitably patched
>> Postgres. Whereas on master, it co
Hi all
To support transparent client-side failover in BDR, it's necessary to
know what the LSN of a node was at the time a transaction committed and
keep track of that in the client/proxy.
I'm thinking about adding a new message type in the protocol that gets
sent immediately before CommandComple
On Sun, Jan 12, 2014 at 12:53:40PM -0500, Noah Misch wrote:
> On Sat, Jan 11, 2014 at 02:10:01PM -0500, Bruce Momjian wrote:
> > On Mon, Jun 3, 2013 at 03:07:27PM -0400, Noah Misch wrote:
> > > A colleague, Korry Douglas, observed a table partitioning scenario where
> > > deserializing pg_constrai
2014-08-06 23:38 GMT+09:00 Fabien COELHO :
>
> Three different modulo operators seems like a lot for a language that
>> doesn't even have a real expression syntax, but I'll yield to whatever
>> the consensus is on this one.
>>
>
> Here is a third simpler patch which only implements the Knuth's mo
On Wed, Aug 6, 2014 at 11:39 AM, Fujii Masao wrote:
>
> On Tue, Aug 5, 2014 at 12:49 PM, Fujii Masao
wrote:
> > On Mon, Aug 4, 2014 at 11:52 PM, Tom Lane wrote:
> >> Fujii Masao writes:
> >>> The patch chooses the last settings for every parameters and ignores
the
> >>> former settings. But I d
On Wed, Aug 6, 2014 at 1:32 PM, Fujii Masao wrote:
> On Tue, Jul 29, 2014 at 9:26 PM, Amit Kapila
wrote:
> >
> > The reason is that during startup DataDir is not set by the time server
> > processes config file due to which we process .auto.conf file in second
> > pass. I think ideally it should
On Thu, Aug 7, 2014 at 2:17 AM, Bruce Momjian wrote:
>
> Seems we still have not addressed this.
Thanks for the reminder :) I'm not sure if I have time to work on this
for a while. If anyone is interested in this, please feel free to try it.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers
On Thu, Aug 7, 2014 at 3:59 AM, Heikki Linnakangas
wrote:
> On 08/06/2014 08:39 PM, Fujii Masao wrote:
>>
>> Hi,
>>
>> The WAL files that pg_receivexlog writes will not be re-read soon
>> basically,
>> so we can advise the OS to release any cached pages when WAL file is
>> closed. I feel inclined
On Thu, Aug 7, 2014 at 6:26 AM, Pavel Stehule wrote:
> Hello
>
> updated version patch in attachment
Thanks! But ISTM you forgot to attached the patch.
>> +/* all psql known variables are included in list by default */
>> +for (known_varname = known_varnames; *known_varname; known_varnam
On Tue, Aug 5, 2014 at 9:32 PM, Peter Geoghegan wrote:
> I knew that I'd heard that at least once. Apparently some other
> database systems have external sorts that tend to be faster than
> equivalent internal sorts. I'd guess that that is an artifact of their
> having a substandard internal sort,
On Thu, Aug 7, 2014 at 8:20 AM, Jeff Janes wrote:
> It needs to go into 9_4_STABLE as well.
It is worth noticing that the buildfarm is completely in red because
this patch was not backpatched to REL9_4_STABLE:
http://buildfarm.postgresql.org/cgi-bin/show_status.pl
Regards,
--
Michael
--
Sent v
65 matches
Mail list logo
