Hello Fabien-san,
I have checked your v13 patch, and tested the new exponential distribution
generating algorithm. It works fine and less or no overhead than previous
version.
Great work! And I agree with your proposal.
And I'm also interested in your "decile percents" output like under
following
Amit Kapila writes:
> On Wed, Jun 18, 2014 at 2:09 AM, Tom Lane wrote:
>> On the other hand, this approach would entirely fail to account for
>> non-palloc'd allocations, which could be a significant issue in some
>> contexts.
> Won't it be possible if we convert malloc calls in backend code to
At 2014-06-18 12:55:36 +0900, masao.fu...@gmail.com wrote:
>
> Also I'm thinking to backpatch this to 9.4 because this is a bugfix
> rather than new feature.
That sounds reasonable, thanks.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Tue, Jun 17, 2014 at 2:08 PM, Abhijit Menon-Sen wrote:
> At 2014-06-17 09:49:35 +0530, amit.kapil...@gmail.com wrote:
>>
>> By above do you mean that the patch should allow GUC_NOT_IN_SAMPLE or
>> something else, if earlier then I have removed it as per comment from
>> Fujji-san.
>
> Yes, what
On Tue, Jun 17, 2014 at 2:11 PM, Shigeru Hanada
wrote:
> Fujii-san,
>
> I agree not to backpatch, but I noticed that the 9.3 document about
> stats collector doesn't mention $PGDATA/pg_stat.
>
> http://www.postgresql.org/docs/current/static/monitoring-stats.html
>
> It just says:
>> When the serve
On Wed, Jun 18, 2014 at 2:09 AM, Tom Lane wrote:
>
> Robert Haas writes:
> > We could do better by accounting for memory usage ourselves, inside
> > the memory-context system, but that'd probably impose some overhead we
> > don't have today.
>
> Hm. We could minimize the overhead if we just acco
Use subtraction is very inefficient, a project called pg_bulkload support
the?skip errors ,and it does not useing subtraction. It?performance is very
good.??So I want to imitate?pg_bulkload?to?implementation?skip errors of
copy.if i do the following thing to copy :1. disable all of trigger
Steven Siebert writes:
> Attached is a proposed patch for BUG #10680.
> It's a simple fix to the problem of the ldapbindpasswd leaking in
> clear text to the postgresql log. The patch simply removes the raw
> pg_hba.conf line from the log message, but retains the log line number
> to assist admi
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jun 16, 2014 at 1:15 AM, Stephen Frost wrote:
> > I understand that there are performance implications. As mentioned to
> > Tom, realistically, there's zero way to optimized at least some of these
> > use-cases because they require a complete
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jun 13, 2014 at 3:11 AM, Dean Rasheed
> wrote:
> > Yeah, I was thinking something like this could work, but I would go
> > further. Suppose you had separate GRANTable privileges for direct
> > access to individual tables, bypassing RLS, e.g.
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jun 12, 2014 at 8:13 PM, Stephen Frost wrote:
> > This approach was suggested by an existing user testing out this RLS
> > approach, to be fair, but it looks pretty sane to me as a way to address
> > some of these concerns. Certainly open to o
Robert,
However, I believe that
> there has been a lack of focus in the development of the patch thus
> far in a couple of key areas - first in terms of articulating how it
> is different from and better than a writeable security barrier view,
> and second on how to manage the security and operati
At 2014-06-17 15:31:33 -0300, klaussfre...@gmail.com wrote:
>
> On Tue, Jun 17, 2014 at 8:47 AM, Abhijit Menon-Sen
> wrote:
> > if (compress_backup_block = BACKUP_BLOCK_COMPRESSION_SNAPPY)
>
> You mean == right?
Of course. Thanks.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql
Hello,
Attached is a proposed patch for BUG #10680.
It's a simple fix to the problem of the ldapbindpasswd leaking in
clear text to the postgresql log. The patch simply removes the raw
pg_hba.conf line from the log message, but retains the log line number
to assist admins in troubleshooting.
Th
On Tue, Jun 17, 2014 at 5:18 PM, Robert Haas wrote:
> What bash does is annoying and stupid, and any time I find a system
> with that obnoxious behavior enabled I immediately disable it, so I
> don't consider that a good precedent for anything.
I happen to totally agree with you here. Bash someti
On 06/18/2014 12:41 AM, Robert Haas wrote:
> On Mon, Jun 16, 2014 at 12:58 AM, Craig Ringer wrote:
>> > On 05/30/2014 11:14 PM, Heikki Linnakangas wrote:
>>> >> Yeah. To recap, the failure mode is that if the master crashes and
>>> >> restarts, the transaction becomes visible in the master even th
On Tue, Jun 17, 2014 at 5:11 PM, Robert Haas wrote:
> I think there's something to be said for that, but I think at the
> moment I like the idea of a functional interface better. The reason
> is that I'm not sure we can predict all of the checks we're going to
> want to add.
That's true. Clearly
On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Jun 17, 2014 at 03:55:02PM -0400, Alvaro Herrera wrote:
> >> Can't you compare it to the historic default value? I mean, add an
> >> assumption that people thus far has never tweaked it.
>
> > Well, if
On 06/18/2014 02:34 AM, Ian Barwick wrote:
On 14/06/18 7:51, Andreas Karlsson wrote:
On 06/17/2014 01:36 PM, Ian Barwick wrote:
One issue - the table's internal triggers will also be listed. which can
result in
something like this:
This is a bit of an extreme case, but I don't think manually m
On 14/06/18 7:51, Andreas Karlsson wrote:
> On 06/17/2014 01:36 PM, Ian Barwick wrote:
>> One issue - the table's internal triggers will also be listed. which can
>> result in
>> something like this:
>>
>> This is a bit of an extreme case, but I don't think manually manipulating
>> internal trigger
On Tue, Jun 17, 2014 at 5:36 PM, Tom Lane wrote:
> Josh Berkus writes:
>> (2) If there are multiple columns with the same levenschtien distance,
>> which one do you suggest? The current code picks a random one, which
>> I'm OK with. The other option would be to list all of the columns.
>
> I ob
On 06/17/2014 07:25 PM, Andres Freund wrote:
On 2014-06-17 19:22:07 -0400, Tom Lane wrote:
Andrew Dunstan writes:
I went to have a look at documenting the jsonb comparison operators, and
found that the docs on comparison operators contain this:
Comparison operators are available for all
On Tue, Jun 17, 2014 at 5:10 PM, Peter Geoghegan wrote:
> On Tue, Jun 17, 2014 at 1:16 PM, Robert Haas wrote:
>> I don't feel qualified to comment on any of the substantive issues you
>> raise, so instead I'd like to bikeshed the name. I suggest that we
>> create one extension to be a repository
On Tue, Jun 17, 2014 at 11:16 AM, Andres Freund wrote:
> Well, it might be doable to correlate them along one axis, but along
> both? That's more complicated... And even alongside one axis you
> already get into problems if your geometries are irregularly sized.
> Asingle large polygon will compl
On 2014-06-17 19:22:07 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > I went to have a look at documenting the jsonb comparison operators, and
> > found that the docs on comparison operators contain this:
>
> > Comparison operators are available for all relevant data types.
>
> > They
Andrew Dunstan writes:
> I went to have a look at documenting the jsonb comparison operators, and
> found that the docs on comparison operators contain this:
> Comparison operators are available for all relevant data types.
> They neglect to specify further, however. This doesn't seem very
(Redirected from Bugs to Hackers, as it seems not to be the same bug
as the original one.)
On Mon, Jun 9, 2014 at 3:50 PM, Alvaro Herrera wrote:
> Jeff Janes wrote:
>
>> This patch seems to solve a problem I've also been having with non-existent
>> "pg_multixact/members/13D35" files in my testing
I went to have a look at documenting the jsonb comparison operators, and
found that the docs on comparison operators contain this:
Comparison operators are available for all relevant data types.
They neglect to specify further, however. This doesn't seem very
satisfactory. How is a user t
Bruce Momjian writes:
> On Tue, Jun 17, 2014 at 03:55:02PM -0400, Alvaro Herrera wrote:
>> Can't you compare it to the historic default value? I mean, add an
>> assumption that people thus far has never tweaked it.
> Well, if they did tweak it, then they would be unable to use pg_upgrade
> becau
Kevin Grittner wrote:
> Andres Freund wrote:
> The release of version n doesn't mean that version n-1 is no longer
> supported. As of today, this page:
>
> http://www.oracle.com/technetwork/server-storage/solaris10/overview/index-138972.html
>
> says:
>
> > The Oracle Solaris 9 operating syst
On Tue, Jun 17, 2014 at 03:55:02PM -0400, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Tue, Jun 17, 2014 at 12:28:46PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Uh, I think pg_upgrade needs to check that they match too.
> > >
> > > Possibly. What do you think it should do
On 06/17/2014 01:36 PM, Ian Barwick wrote:
Thanks for this patch; I'm playing around with rules at the moment and
it was
very useful. A quick review:
- applies cleanly to HEAD
- does what it claims, i.e. adds tab completion support for this syntax:
ALTER TABLE table { ENABLE | DISABLE } [
From: "Joe Conway"
That first hunk refers to dblink -- I'm guessing it does not belong with
this patch.
Ouch, what a careless mistake. The attached one is clean. I'll update the
CommitFest entry when I'm back home from work.
Regards
MauMau
pg_copy_v2.patch
Description: Binary data
--
On 17/06/14 22:32, Kevin Grittner wrote:
The release of version n doesn't mean that version n-1 is no longer
supported. As of today, this page:
http://www.oracle.com/technetwork/server-storage/solaris10/overview/index-138972.html
says:
The Oracle Solaris 9 operating system is now in the Exte
On 18/06/14 10:05, Peter Geoghegan wrote:
On Tue, Jun 17, 2014 at 2:53 PM, Tom Lane wrote:
I'm not proposing an immutable cutoff. Something that scales with the
string length might be a good idea, or we could make it a multiple of
the minimum observed distance, or probably there are a dozen ot
On Tue, Jun 17, 2014 at 2:53 PM, Tom Lane wrote:
> I'm not proposing an immutable cutoff. Something that scales with the
> string length might be a good idea, or we could make it a multiple of
> the minimum observed distance, or probably there are a dozen other things
> we could do. I'm just say
On 2014-06-17 13:32:51 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
> > On 2014-06-17 13:14:26 -0400, Robert Haas wrote:
> >> On Sat, Jun 14, 2014 at 9:12 PM, Andres Freund
> >> wrote:
>
> >>> 3) sparcv8: Last released model 1997.
> >>
> >> I seem to recall hearing about this in a custom
On 06/17/2014 02:53 PM, Tom Lane wrote:
> Josh Berkus writes:
>> On 06/17/2014 02:36 PM, Tom Lane wrote:
>>> Another issue is whether to print only those having exactly the minimum
>>> observed Levenshtein distance, or to print everything less than some
>>> cutoff. The former approach seems to me
Josh Berkus writes:
> On 06/17/2014 02:36 PM, Tom Lane wrote:
>> Another issue is whether to print only those having exactly the minimum
>> observed Levenshtein distance, or to print everything less than some
>> cutoff. The former approach seems to me to be placing a great deal of
>> faith in som
Peter Geoghegan writes:
> Maybe that's just a matter of phrasing the message appropriately. A
> more guarded message, that suggests that "foobar" is the *best* match
> is correct at least on its own terms (terms that are self evident).
> This does pretty effectively communicate to the user that th
On 06/17/2014 02:36 PM, Tom Lane wrote:
> Josh Berkus writes:
>> (2) If there are multiple columns with the same levenschtien distance,
>> which one do you suggest? The current code picks a random one, which
>> I'm OK with. The other option would be to list all of the columns.
>
> I objected to
On Wed, Jun 18, 2014 at 1:40 AM, Robert Haas wrote:
> On Mon, Jun 2, 2014 at 8:55 AM, Michael Paquier
> wrote:
> I'm not sure if this is reasonably possible, but one thing that would
> make this tool a whole lot easier to use would be if you could make
> all the magic happen in a single server.
Josh Berkus writes:
> (2) If there are multiple columns with the same levenschtien distance,
> which one do you suggest? The current code picks a random one, which
> I'm OK with. The other option would be to list all of the columns.
I objected to that upthread. I don't think that picking a ran
On Tue, Jun 17, 2014 at 1:59 PM, Tom Lane wrote:
> Yeah, that's my point exactly. There's no very good reason to assume that
> the intended answer is in fact among the set of column names we can see;
> and if it *is* there, the Levenshtein distance to it isn't going to be
> all that large. I thi
On 06/17/2014 09:14 AM, Robert Haas wrote:
> Well, I don't know: suppose you're loading geospatial data showing the
> location of every building in some country. It might easily be the
> case that the data is or can be loaded in an order that provides
> pretty good spatial locality, leading to tig
On 06/17/2014 01:59 PM, Tom Lane wrote:
> Robert Haas writes:
>> Emitting a suggestion with a large distance seems like it could be
>> rather irritating. If the user types in SELECT prodct_id FROM orders,
>> and that column does not exist, suggesting "product_id", if such a
>> column exists, will
Tom Lane wrote:
> I wouldn't necessarily hold up git as a model of user interface
> engineering ;-) ... but still, it might be interesting to take a
> look at exactly what heuristics they used here. I'm sure there
> are other precedents we could look at, too.
On my Ubuntu machine, bash does som
On Tue, Jun 17, 2014 at 1:16 PM, Robert Haas wrote:
> I don't feel qualified to comment on any of the substantive issues you
> raise, so instead I'd like to bikeshed the name. I suggest that we
> create one extension to be a repository for index-checking machinery
> (and perhaps also heap-checkin
Robert Haas writes:
> On Tue, Jun 17, 2014 at 12:51 AM, Peter Geoghegan wrote:
>> I disagree. I happen to think that making some guess is better than no
>> guess at all here, given the fact that there aren't too many
>> possibilities to choose from.
> Emitting a suggestion with a large distance
On Tue, Jun 17, 2014 at 4:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> We could do better by accounting for memory usage ourselves, inside
>> the memory-context system, but that'd probably impose some overhead we
>> don't have today.
>
> Hm. We could minimize the overhead if we just accounted
On Tue, Jun 17, 2014 at 12:51 AM, Peter Geoghegan wrote:
> On Mon, Jun 16, 2014 at 8:56 PM, Tom Lane wrote:
>> Not having looked at the patch, but: I think the probability of
>> useless-noise HINTs could be substantially reduced if the code prints a
>> HINT only when there is a single available a
Robert Haas writes:
> We could do better by accounting for memory usage ourselves, inside
> the memory-context system, but that'd probably impose some overhead we
> don't have today.
Hm. We could minimize the overhead if we just accounted for entire
malloc chunks and not individual palloc alloca
Andres Freund wrote:
> On 2014-06-17 13:14:26 -0400, Robert Haas wrote:
>> On Sat, Jun 14, 2014 at 9:12 PM, Andres Freund
>> wrote:
>>> 3) sparcv8: Last released model 1997.
>>
>> I seem to recall hearing about this in a customer situation
>> relatively recently, so there may be a few of these
On Mon, Jun 16, 2014 at 4:14 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Fujii Masao writes:
>> > That's harmful for audit purpose. I think that we should make
>> > log_disconnections PGC_SUSET rather than PGC_BACKEND in order
>> > to forbid non-superusers from changing i
On Mon, Jun 16, 2014 at 10:16 PM, Noah Misch wrote:
> On Sat, Jun 14, 2014 at 10:37:36AM -0400, Tom Lane wrote:
>> After giving somebody advice, for the Nth time, to install a
>> memory-consumption ulimit instead of leaving his database to the tender
>> mercies of the Linux OOM killer, it occurred
On Mon, Jun 16, 2014 at 9:47 PM, Peter Geoghegan wrote:
> As discussed at the developer meeting at pgCon, I think that there is
> a lot to be said for a tool that checks nbtree index invariants on
> live systems.
Me too.
> Attached prototype patch adds contrib extension, btreecheck.
I don't fee
On Sat, Jun 14, 2014 at 7:56 PM, Kevin Grittner wrote:
> I looked at the standard, and initially tried to implement the
> standard syntax for this; however, it appeared that the reasons
> given for not using standard syntax for the row variables also
> apply to the transition relations (the term u
Bruce Momjian wrote:
> On Tue, Jun 17, 2014 at 12:28:46PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Uh, I think pg_upgrade needs to check that they match too.
> >
> > Possibly. What do you think it should do when examining a pg_control
> > version that lacks the field?
>
> Good que
On Mon, Jun 16, 2014 at 1:15 AM, Stephen Frost wrote:
>> I'm not referring to the proposed implementation particularly; or at
>> least not that aspect of it. I don't think trying to run the view
>> quals as the defining user is likely to be very appealing, because I
>> think it's going to hurt pe
Robert,
On Tuesday, June 17, 2014, Robert Haas wrote:
>
> After sending that one (1) email, I was promptly told that "I'm very
> disappointed to hear that the mechanical pieces around making RLS easy
> for users to use ... is receiving such push-back." The push-back, at
> that point in time, con
On Thu, Jun 12, 2014 at 8:13 PM, Stephen Frost wrote:
>> I'm in full agreement we should clearly communicate the issues around
>> pg_dump in particular, because they can't necessarily be eliminated
>> altogether without some major work that's going to take a while to finish.
>> And if the work-aro
On Fri, Jun 13, 2014 at 3:11 AM, Dean Rasheed wrote:
> Yeah, I was thinking something like this could work, but I would go
> further. Suppose you had separate GRANTable privileges for direct
> access to individual tables, bypassing RLS, e.g.
>
> GRANT DIRECT SELECT|INSERT|UPDATE|DELETE ON table_
On Thu, Jun 12, 2014 at 6:33 PM, Gregory Smith wrote:
> I'm kind of surprised to see this turn into a hot button all of the sudden
> though, because my thought on all that so far has been a giant so what?
> This is what PostgreSQL does.
[...]
> But let's not act like RLS is a scary bogeyman becaus
On Tue, Jun 17, 2014 at 8:47 AM, Abhijit Menon-Sen wrote:
> if (compress_backup_block = BACKUP_BLOCK_COMPRESSION_SNAPPY)
You mean == right?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
On Tue, Jun 17, 2014 at 1:04 PM, Andres Freund wrote:
> For me minmax indexes are helpful because they allow to generate *small*
> 'coarse' indexes over large volumes of data. From my pov that's possible
> possible because they don't contain item pointers for every contained
> row.
But minmax is
On 2014-06-17 12:14:00 -0400, Robert Haas wrote:
> On Tue, Jun 17, 2014 at 12:04 PM, Andres Freund
> wrote:
> >> Well, I'm not the guy who does things with geometric data, but I don't
> >> want to ignore the significant percentage of our users who are. As
> >> you must surely know, the GIST impl
On 2014-06-17 13:14:26 -0400, Robert Haas wrote:
> On Sat, Jun 14, 2014 at 9:12 PM, Andres Freund wrote:
> > At this year developer's meeting we'd discussed the atomics abstraction
> > which is necessary for some future improvements. We'd concluded that a
> > overview over the hardware capabilitie
Abhijit Menon-Sen wrote:
> I find it hard to believe that gmail is incapable of threading messages
> using In-Reply-To/References header fields, especially given that mail
> subjects are changed all the time in the normal course of events. But
> I'll take your word for it and reply to the original
On Sat, Jun 14, 2014 at 9:12 PM, Andres Freund wrote:
> At this year developer's meeting we'd discussed the atomics abstraction
> which is necessary for some future improvements. We'd concluded that a
> overview over the hardware capabilities of the supported platforms would
> be helpful. I've sta
On Tue, Jun 17, 2014 at 12:28:46PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Uh, I think pg_upgrade needs to check that they match too.
>
> Possibly. What do you think it should do when examining a pg_control
> version that lacks the field?
Good question. I have existing cases where f
Noah Misch writes:
> Here's a fix to make the MSVC build process account for the addition of
> HAVE_UUID_OSSP. (None of the MSVC buildfarm members enable uuid-ossp.)
Looks reasonable. I'm unable to test this scenario, but if you have,
please commit.
regards, tom lane
At 2014-06-17 12:47:19 -0400, alvhe...@2ndquadrant.com wrote:
>
> > > P.S. If you tag your reviews with [REVIEW] in the Subject, it'll
> > > be easier to keep track of them.
> >
> > I and, I believe, various other people hate that style, because at
> > least in Gmail, it breaks the threading. It
On 2014-06-17 12:47:19 -0400, Alvaro Herrera wrote:
> Robert Haas wrote:
> > On Mon, Jun 16, 2014 at 2:36 AM, Abhijit Menon-Sen
> > wrote:
> > > P.S. If you tag your reviews with [REVIEW] in the Subject, it'll be
> > > easier to keep track of them.
> >
> > I and, I believe, various other people
Alvaro Herrera writes:
> Robert Haas wrote:
>> On Mon, Jun 16, 2014 at 2:36 AM, Abhijit Menon-Sen
>> wrote:
>>> P.S. If you tag your reviews with [REVIEW] in the Subject, it'll be
>>> easier to keep track of them.
>> I and, I believe, various other people hate that style, because at
>> least in
On 2014-06-17 12:07:04 -0400, Robert Haas wrote:
> On Tue, Jun 17, 2014 at 10:33 AM, Petr Jelinek wrote:
> > On 17/06/14 16:18, Robert Haas wrote:
> >> On Fri, Jun 13, 2014 at 8:31 PM, Petr Jelinek
> >> wrote:
> >>> attached is a simple patch which makes it possible to change the system
> >>> ide
Robert Haas wrote:
> On Mon, Jun 16, 2014 at 2:36 AM, Abhijit Menon-Sen
> wrote:
> > P.S. If you tag your reviews with [REVIEW] in the Subject, it'll be
> > easier to keep track of them.
>
> I and, I believe, various other people hate that style, because at
> least in Gmail, it breaks the thread
On Mon, Jun 16, 2014 at 2:36 AM, Abhijit Menon-Sen wrote:
> P.S. If you tag your reviews with [REVIEW] in the Subject, it'll be
> easier to keep track of them.
I and, I believe, various other people hate that style, because at
least in Gmail, it breaks the threading. It is much easier to find
th
On Mon, Jun 16, 2014 at 12:58 AM, Craig Ringer wrote:
> On 05/30/2014 11:14 PM, Heikki Linnakangas wrote:
>> Yeah. To recap, the failure mode is that if the master crashes and
>> restarts, the transaction becomes visible in the master even though it
>> was never replicated.
>
> Wouldn't another pg
On Mon, Jun 2, 2014 at 8:55 AM, Michael Paquier
wrote:
> On Wed, Apr 23, 2014 at 9:43 PM, Heikki Linnakangas
> wrote:
>> And here is the tool itself. It consists of two parts:
>>
>> 1. Modifications to the backend to write the page images
>> 2. A post-processing tool to compare the logged images
On Tue, May 27, 2014 at 07:46:41PM -0400, Tom Lane wrote:
> Pushed; thanks for working on this!
Here's a fix to make the MSVC build process account for the addition of
HAVE_UUID_OSSP. (None of the MSVC buildfarm members enable uuid-ossp.)
--
Noah Misch
EnterpriseDB
Bruce Momjian writes:
> Uh, I think pg_upgrade needs to check that they match too.
Possibly. What do you think it should do when examining a pg_control
version that lacks the field?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
Andres Freund writes:
> On 2014-06-17 21:09:25 +0530, Abhijit Menon-Sen wrote:
>> At 2014-06-17 11:32:37 -0400, br...@momjian.us wrote:
>>> Uh, what is replacing SRFs? CTEs?
>> I don't think Tom was referring to SRFs in general, only putting them
>> directly into the targetlist of a SELECT.
> A
On Fri, Jun 13, 2014 at 11:57 AM, David Johnston
wrote:
>> That's not the reading I want, and it's not the reading you want either,
>> but there is nothing in the existing text that justifies single
>> evaluation. So I think we'd be well advised to sit on our hands until
>> the committee clarifie
On Wed, Jun 4, 2014 at 06:57:31PM -0400, Tom Lane wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> There are at least two places in inv_api.c where we have
> >> "Assert(pagelen <= LOBLKSIZE)" that is protecting a subsequent memcpy
> >> into a local variable of size L
On Tue, Jun 17, 2014 at 12:04 PM, Andres Freund wrote:
>> Well, I'm not the guy who does things with geometric data, but I don't
>> want to ignore the significant percentage of our users who are. As
>> you must surely know, the GIST implementations for geometric data
>> types store bounding boxes
On Tue, Jun 17, 2014 at 10:33 AM, Petr Jelinek wrote:
> On 17/06/14 16:18, Robert Haas wrote:
>> On Fri, Jun 13, 2014 at 8:31 PM, Petr Jelinek
>> wrote:
>>> attached is a simple patch which makes it possible to change the system
>>> identifier of the cluster in pg_control. This is useful for
>>>
On 2014-06-17 11:48:10 -0400, Robert Haas wrote:
> On Tue, Jun 17, 2014 at 10:31 AM, Andres Freund
> wrote:
> > On 2014-06-17 10:26:11 -0400, Robert Haas wrote:
> >> On Sat, Jun 14, 2014 at 10:34 PM, Alvaro Herrera
> >> wrote:
> >> > Robert Haas wrote:
> >> >> On Wed, Sep 25, 2013 at 4:34 PM, Al
On Tue, Jun 17, 2014 at 10:31 AM, Andres Freund wrote:
> On 2014-06-17 10:26:11 -0400, Robert Haas wrote:
>> On Sat, Jun 14, 2014 at 10:34 PM, Alvaro Herrera
>> wrote:
>> > Robert Haas wrote:
>> >> On Wed, Sep 25, 2013 at 4:34 PM, Alvaro Herrera
>> >> wrote:
>> >> > Here's an updated version of
On 2014-06-17 21:09:25 +0530, Abhijit Menon-Sen wrote:
> At 2014-06-17 11:32:37 -0400, br...@momjian.us wrote:
> >
> > > SRFs in the SELECT targetlist tend to leak memory; this is not easily
> > > fixable, and nobody is likely to try hard considering the feature's on
> > > the edge of deprecation a
At 2014-06-17 11:32:37 -0400, br...@momjian.us wrote:
>
> > SRFs in the SELECT targetlist tend to leak memory; this is not easily
> > fixable, and nobody is likely to try hard considering the feature's on
> > the edge of deprecation anyhow.
>
> Uh, what is replacing SRFs? CTEs?
I don't think Tom
Hi Hackers,
I was facing a situation were we wanted to set temp_tablespaces to a
tablespace on a ephemeral disk (yes, it is AWS ephemeral disk), and I know
many users have faced the same situation. Although it seems safe to create
a tablespace on ephemeral disks if you use it to store only tempora
On Tue, Jun 3, 2014 at 03:59:45PM -0400, Tom Lane wrote:
> Soroosh Sardari writes:
> > I have problem with memory deallocation. look at the following queries
>
> > 1- create table test01(a) as select generate_series(1,1)::int8 ;
>
> Do it as, eg,
>
> create table test01(a) as select g:
On Tue, Jun 3, 2014 at 01:21:51AM -0700, Peter Geoghegan wrote:
> On Sun, May 4, 2014 at 5:46 AM, Bruce Momjian wrote:
> > Feedback expected and welcomed.
>
> One item currently reads "Improve valgrind error reporting". I
> suggest this be changed to "Add support for Valgrind memcheck memory
>
On Tue, Jun 17, 2014 at 3:31 PM, Andres Freund wrote:
> Is there actually a significant usecase behind that wish or just a
> general demand for being generic? To me it seems fairly unlikely you'd
> end up with something useful by doing a minmax index over bounding
> boxes.
Isn't min/max just a 2d
On 2014-06-17 20:47:51 +0530, Amit Kapila wrote:
> On Tue, Jun 17, 2014 at 6:35 PM, Andres Freund
> wrote:
> > On 2014-06-17 18:01:58 +0530, Amit Kapila wrote:
> > > On Tue, Jun 17, 2014 at 3:56 PM, Andres Freund
> > > > On 2014-06-17 12:41:26 +0530, Amit Kapila wrote:
> > I unfortunately still c
On Tue, Jun 17, 2014 at 6:35 PM, Andres Freund
wrote:
>
> On 2014-06-17 18:01:58 +0530, Amit Kapila wrote:
> > On Tue, Jun 17, 2014 at 3:56 PM, Andres Freund
> > > On 2014-06-17 12:41:26 +0530, Amit Kapila wrote:
> > > > 2.
> > > > Handling of potentialy_spurious case seems to be pending
> > > >
At 2014-06-17 08:02:59 -0700, m...@joeconway.com wrote:
>
> That first hunk refers to dblink -- I'm guessing it does not belong
> with this patch.
Yes, it's a leftover of the dblink memory leak patch that's in this CF.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/17/2014 07:26 AM, MauMau wrote:
> Hello,
>
> As I proposed before in the thread below, I've implemented a simple
> command for reliable WAL archiving. I would appreciate it if you could
> review and test the patch.
>
> http://www.postgresql.or
At 2014-06-17 23:26:37 +0900, maumau...@gmail.com wrote:
>
> Hello,
>
> As I proposed before in the thread below, I've implemented a simple
> command for reliable WAL archiving. I would appreciate it if you
> could review and test the patch.
Please add your patch to the next CF (i.e. 2014-08), s
On 17/06/14 16:18, Robert Haas wrote:
On Fri, Jun 13, 2014 at 8:31 PM, Petr Jelinek wrote:
attached is a simple patch which makes it possible to change the system
identifier of the cluster in pg_control. This is useful for
individualization of the instance that is started on top of data directo
1 - 100 of 134 matches
Mail list logo
