-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/05/2013 10:01 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Now maybe that's fine. But given that, I think it's pretty
>> important that we get the syntax right. Because if you're adding
>> a feature primarily to ad
On 11/05/2013 09:30 PM, Robert Haas wrote:
>> So really, there are four cases:
>>
>> READ
>> WRITE INSERT
>> WRITE UPDATE
>> WRITE DELETE
>
> Isn't READ similarly divisible into READ SELECT, READ UPDATE, and READ DELETE?
Not in my opinion. No matter what the command, the read side is all
about ha
On 11/05/2013 09:36 PM, Robert Haas wrote:
> I haven't studied this patch in detail, but I see why there's some
> unhappiness about that code: it's an RLS-specific kluge. Just
> shooting from the hip here, maybe we should attack the problem of
> making security-barrier views updatable first, as a
On Thu, Oct 31, 2013 at 8:22 PM, Noah Misch wrote:
> CommitTransaction() and AbortTransaction() both do much work, and large
> portions of that work either should not or must not throw errors. An error
> during either function will, as usual, siglongjmp() out. Ordinarily,
> PostgresMain() will r
Peter Eisentraut wrote:
> This makes the entire tree git diff --check clean. After this, future
> patches can be inspected for whitespace errors with git diff --check,
> something that has been discussed on occasion.
+1 to this, and also +1 to Tom's suggestion of making it more strongly
enforced
Peter Eisentraut writes:
> Attached is a patch that
> - Adds a .gitattributes file to configure appropriate whitespace checks
> for git diff --check.
> - Cleans up all whitespace errors found in this way in existing code.
> Most of that is in files not covered by pgindent, some in new code since
Andres,
> There's zap chance of doing anything for 9.3, this would require quite a
> bit of code in tablecmds.c and that surely isn't going to happen in the
> backbranches.
Oh, sure, I was thinking of a workaround.
Actually, being able to separate "need to check contents" from "need to
rewrite v
Greg Stark escribió:
> I think minmax indexes are more akin to bitmap indexes. They will be very
> effective for columns with low-cardinality, especially for columns that are
> very clustered. In the extreme if all the values in some regions of the
> table are the same then minmax indexes would be
On Tue, Nov 5, 2013 at 5:30 PM, Claudio Freire wrote:
> > Maybe there's value in minmax indexes for sequential data, but not for
> > random data, which is the topic of this thread.
>
>
> Well, of course, they're not magic pixie dust.
>
> But is your data really random? (or normal?)
I think minma
On Tue, Nov 5, 2013 at 4:29 PM, Oskari Saarenmaa wrote:
> This can be used to tag custom built packages with an extra version string
> such as the git describe id or distribution package release version.
Could you attach a proper patch to your email and register it to the
next commit fest? Typical
Ian Lawrence Barwick writes:
> 2013/9/10 Bruce Momjian :
>> I still see that weird behavior in git head:
>>
>> pgdevel=# \s history.txt
>> Wrote history to file "./history.txt".
>> pgdevel=# \s /tmp/history.txt
>> Wrote history to file ".//tmp/history.txt".
>> pgdevel=# \cd /tmp
>> pgdevel=# \s /
On 2013-11-05 17:19:21 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On that note, any chance you remember why you increased MAX_LOCKMODE by
> > 2 to 10 back in 2001 although AccessExclusiveLock is 8? The relevant
> > commit is 4fe42dfbc3bafa0ea615239d716a6b37d67da253 .
>
> Probably because
I wrote:
> Attached is a proposed patch against HEAD that fixes this by supporting
> default arguments properly for window functions. In passing, it also
> allows named-argument notation in window function calls, since that's
> free once the other thing works (because the same subroutine fixes up
Andres Freund writes:
> On that note, any chance you remember why you increased MAX_LOCKMODE by
> 2 to 10 back in 2001 although AccessExclusiveLock is 8? The relevant
> commit is 4fe42dfbc3bafa0ea615239d716a6b37d67da253 .
Probably because it seemed like a round number, which 9 wasn't ...
keep in
On 11/5/13, 1:04 AM, Arulappan, Arul Shaji wrote:
> Implements NCHAR/NVARCHAR as distinct data types, not as synonyms
If, per SQL standard, NCHAR(x) is equivalent to CHAR(x) CHARACTER SET
"cs", then for some "cs", NCHAR(x) must be the same as CHAR(x).
Therefore, an implementation as separate data
On 2013-11-05 22:35:41 +0100, Andres Freund wrote:
> We could relatively easily optimize that to a constant factor by just
> iterating over the possible lockmodes. Should only take a couple more
> lines.
On that note, any chance you remember why you increased MAX_LOCKMODE by
2 to 10 back in 2001 a
On 2013-11-05 16:45:49 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-11-05 16:25:53 -0500, Tom Lane wrote:
> >> If we're sufficiently worried by this type of bug, ISTM we'd be better off
> >> just disallowing heap_open(NoLock). At the time we invented that, every
> >> lock request we
Andres Freund wrote:
> On 2013-11-05 12:21:23 -0800, Kevin Grittner wrote:
>> Andres Freund
>>
>>> Looks fine to me
>>
>> Any thoughts on whether this should be back-patched to 9.3? I
>> can see arguments both ways, and don't have a particularly
>> strong feeling one way or the other.
>
> Hehe.
Andres Freund writes:
> On 2013-11-05 16:25:53 -0500, Tom Lane wrote:
>> If we're sufficiently worried by this type of bug, ISTM we'd be better off
>> just disallowing heap_open(NoLock). At the time we invented that, every
>> lock request went to shared memory; but now that we have the local lock
On 2013-11-05 16:25:53 -0500, Tom Lane wrote:
> Andres Freund writes:
> > There frequently have been bugs where (heap|relation|index)_open(NoLock)
> > was used without a previous locks which in some circumstances is an easy
> > mistake to make and which is hard to notice.
> > The attached patch ad
Andres Freund writes:
> There frequently have been bugs where (heap|relation|index)_open(NoLock)
> was used without a previous locks which in some circumstances is an easy
> mistake to make and which is hard to notice.
> The attached patch adds --use-cassert only WARNINGs against doing so:
While
From: "Albe Laurenz"
I looked into the Standard, and it does not have NVARCHAR.
The type is called NATIONAL CHARACTER VARYING, NATIONAL CHAR VARYING
or NCHAR VARYING.
OUch, that's just a mistake in my mail. You are correct.
> I guess that the goal of this patch is to support Oracle syntax.
Hi,
There frequently have been bugs where (heap|relation|index)_open(NoLock)
was used without a previous locks which in some circumstances is an easy
mistake to make and which is hard to notice.
The attached patch adds --use-cassert only WARNINGs against doing so:
Add cassert-only checks aga
I wrote:
> I noticed this while poking at the variadic-aggregates issue:
> regression=# create function nth_value_def(anyelement, integer = 1) returns
> anyelement language internal window immutable strict as 'window_nth_value';
> CREATE FUNCTION
> regression=# SELECT nth_value_def(ten) OVER (PART
On 2013-11-05 12:21:23 -0800, Kevin Grittner wrote:
> Andres Freund
>
> > Looks fine to me
>
> Any thoughts on whether this should be back-patched to 9.3? I can
> see arguments both ways, and don't have a particularly strong
> feeling one way or the other.
Hehe. I was wondering myself. I'd ten
On 2013-11-05 11:56:25 -0800, Kevin Grittner wrote:
> Andres Freund wrote:
> > On 2013-11-02 17:05:24 -0700, Kevin Grittner wrote:
> >> Andres Freund wrote:
>
> >>> Also attached is 0004 which just adds a heap_lock() around a
> >>> newly created temporary table in the matview code which
> >>> sh
Andres Freund wrote:
> On 2013-11-02 17:05:24 -0700, Kevin Grittner wrote:
>> Andres Freund wrote:
>>> Also attached is 0004 which just adds a heap_lock() around a
>>> newly created temporary table in the matview code which
>>> shouldn't be required for correctness but gives warm and fuzzy
>>> f
This patch implements the following TODO item:
Split out pg_resetxlog output into pre- and post-sections
http://archives.postgresql.org/pgsql-hackers/2010-08/msg02040.php
On execution of pg_resetxlog using the option -n
1. It will
On 2013-11-04 13:48:32 +0100, Andres Freund wrote:
> What about just unowning the smgr entry with
> if (rel->rd_smgr != NULL)
>smgrsetowner(NULL, rel->rd_smgr)
> when closing the fake relcache entry?
>
> That shouldn't require any further changes than changing the comment in
> smgrsetowner() t
On 2013-11-05 11:15:29 -0800, Josh Berkus wrote:
> Noah,
>
> > That's all true, but the system has no concept like "this cast validates the
> > data, never changing it". We would first need to add metadata supporting
> > such
> > a concept. On the other hand, "create cast (json as text) without
Noah,
> That's all true, but the system has no concept like "this cast validates the
> data, never changing it". We would first need to add metadata supporting such
> a concept. On the other hand, "create cast (json as text) without function;"
> leans only on concepts the system already knows.
>
On Tue, Nov 5, 2013 at 11:55 PM, Tom Lane wrote:
> Joe Love writes:
>> I'm wondering what type of index would work for this as it is a volatile
>> function. Not knowing how PGs optimizer runs, I'm at a loss as to why this
>> wouldn't be possible or worth doing. It seems to me that all functions i
Joe Love writes:
> I'm wondering what type of index would work for this as it is a volatile
> function. Not knowing how PGs optimizer runs, I'm at a loss as to why this
> wouldn't be possible or worth doing. It seems to me that all functions in
> the "select" part of the statement could be calcula
We've had a couple of complaints about the error message that's thrown
for the case where you try to copy-and-modify a window definition that
includes a frame clause:
http://www.postgresql.org/message-id/200911191711.najhbped009...@wwwmaster.postgresql.org
http://www.postgresql.org/message-id/CADyr
On Tue, Nov 05, 2013 at 10:00:15AM -0800, Josh Berkus wrote:
> Noah,
>
> >> Also, JSON <--> Text seems to be missing from the possible binary
> >> conversions. That's a TODO, I suppose.
> >
> > Only json --> text, not json <-- text. Note that you can add the cast
> > manually if you have an imm
Noah,
>> Also, JSON <--> Text seems to be missing from the possible binary
>> conversions. That's a TODO, I suppose.
>
> Only json --> text, not json <-- text. Note that you can add the cast
> manually if you have an immediate need.
Huh? Why would text --> JSON require a physical rewrite? We
On Tue, Nov 5, 2013 at 2:52 PM, Leonardo Francalanci wrote:
> Jeff Janes wrote
>> Some experiments I did a few years ago showed that applying sorts to the
>> data to be inserted could be helpful even when the sort batch size was as
>> small as one tuple per 5 pages of existing index. Maybe even l
Jeff Janes wrote
> Some experiments I did a few years ago showed that applying sorts to the
> data to be inserted could be helpful even when the sort batch size was as
> small as one tuple per 5 pages of existing index. Maybe even less.
Cool!!! Do you have any idea/hint on how I could try and rep
Claudio Freire wrote
> Well, of course, they're not magic pixie dust.
Of course they aren't. I think they can make a difference in a sequential
input scenario. But I'm not the one who said that they are fit to
solve the problems me and other people are talking about in this thread.
Claudio Frei
On 04.11.2013 23:44, Alexander Korotkov wrote:
On Mon, Oct 21, 2013 at 11:12 PM, Alexander Korotkov
wrote:
Attached version of patch is debugged. I would like to note that number of
bugs was low and it wasn't very hard to debug. I've rerun tests on it. You
can see that numbers are improved as t
On Tue, Nov 5, 2013 at 12:22 PM, Leonardo Francalanci wrote:
> Claudio Freire wrote
>> you haven't really
>> analyzed update cost, which is what we were talking about in that last
>> post.
>
> I don't care for a better update cost if the cost to query is a table scan.
> Otherwise, I'll just claim
On Tue, Nov 5, 2013 at 6:35 AM, Tom Lane wrote:
> Oskari Saarenmaa writes:
> > On Tue, Nov 05, 2013 at 02:06:26PM +0200, Heikki Linnakangas wrote:
> >> I can see some value in that kind of information, ie. knowing what
> >> patches a binary was built with, but this would only solve the
> >> prob
I'm wondering what type of index would work for this as it is a volatile
function. Not knowing how PGs optimizer runs, I'm at a loss as to why this
wouldn't be possible or worth doing. It seems to me that all functions in
the "select" part of the statement could be calculated at the end of the
quer
On Tue, Nov 5, 2013 at 12:25 AM, Leonardo Francalanci wrote:
> Andres Freund-3 wrote
> > On 2013-11-04 11:27:33 -0500, Robert Haas wrote:
> >> On Mon, Nov 4, 2013 at 11:24 AM, Claudio Freire <
>
> > klaussfreire@
>
> > > wrote:
> >> > Such a thing would help COPY, so maybe it's worth a look
> >>
>
Back at
http://www.postgresql.org/message-id/520d221e.2060...@gmail.com
there was a complaint about strange behavior of a query that looks
basically like this:
SELECT ...
FROM
(SELECT ... ,
( SELECT ...
ORDER BY random()
LIMIT 1
) AS
This can be used to tag custom built packages with an extra version string
such as the git describe id or distribution package release version.
Based on pgsql-hackers discussion:
http://www.postgresql.org/message-id/20131105102226.ga26...@saarenmaa.fi
Signed-off-by: Oskari Saarenmaa
---
configu
On Tue, Nov 5, 2013 at 9:01 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Now maybe that's fine. But given that, I think it's pretty important
>> that we get the syntax right. Because if you're adding a feature
>> primarily to add a more convenient syntax, then the s
On 11/05/2013 10:53 AM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
What about, say, a configure option to add a
user-specified string to the version() result?
I quite like that idea, personally. Folks who care about it being a git
tag could then trivially get that also.
+1
Hi,
(Coming back to this now)
On 2013-10-28 21:55:22 +0100, Andres Freund wrote:
> The list I have previously suggested was:
>
> * pg_atomic_load_u32(uint32 *)
> * uint32 pg_atomic_store_u32(uint32 *)
>
> To be able to write code without spreading volatiles all over while
> making it very clear
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> What about, say, a configure option to add a
> user-specified string to the version() result?
I quite like that idea, personally. Folks who care about it being a git
tag could then trivially get that also.
Thanks,
Stephen
signat
On 11/05/2013 10:32 AM, Stephen Frost wrote:
All-in-all, I'm not super excited about this but I also wouldn't mind,
so while not really a '+1', I'd say '+0'. Nice idea, if it isn't
painful to deal with and maintain.
I doubt it's buying us anything worth having. What's more, it migh
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> So basically, this
>> would only be useful to people building production servers from random git
>> pulls from development or release-branch mainline. How many people really
>> do that, and should we inconvenience everybody else to
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I agree with Heikki that this is basically useless. Most of my builds are
> from git + uncommitted changes, so telling me what the top commit was has
> no notable value.
The focus of this change would really be, imv anyway, for more casual
PG developers,
Claudio Freire wrote
> real data isn't truly random
Well, let's try normal_rand???
create table t1 as select trunc(normal_rand(100, 50, 3)) as n,
generate_series(1, 100) as i;
with cte as
(select min(n) as minn, max(n) as maxn, i/100 from t1 group by i/100),
On Tue, Nov 5, 2013 at 11:28 AM, Leonardo Francalanci wrote:
> I get > 9000 pages for 49 values out of 50... which means scanning 90% of
> the table.
>
> Either my sql is not correct (likely), or my understanding of the minmax
> index is
> not correct (even more likely), or the minmax index is not
Robert Haas writes:
> On Mon, Nov 4, 2013 at 8:17 PM, Noah Misch wrote:
>> I was prepared to suppose that no substantial clientele relies on the
>> to_char() "TZ" format code expanding to blank, the other behavior that
>> changed
>> with this patch. It's more of a stretch to figure applications
Oskari Saarenmaa writes:
> On Tue, Nov 05, 2013 at 02:06:26PM +0200, Heikki Linnakangas wrote:
>> I can see some value in that kind of information, ie. knowing what
>> patches a binary was built with, but this would only solve the
>> problem for git checkouts. Even for a git checkout, the binaries
Claudio Freire wrote
> Min-max indexes always require a sequential scan of the min-max index
> itself when querying.
I'm worried about the number of heap pages that will be scanned.
My understanding is that given the random input, the index will
not be selective enough, and will end up requiring
David Rowley escribió:
> In this case how does Postgresql know that attnum 3 is the 2nd user column
> in that table? Unless I have misunderstood something then there must be
> some logic in there to skip dropped columns and if so then could it not
> just grab the "attphynum" at that location? then
On Tue, Nov 5, 2013 at 2:05 PM, Oskari Saarenmaa wrote:
>> I can see some value in that kind of information, ie. knowing what
>> patches a binary was built with, but this would only solve the
>> problem for git checkouts. Even for a git checkout, the binaries
>> won't be automatically updated unle
On Tue, Nov 05, 2013 at 02:06:26PM +0200, Heikki Linnakangas wrote:
> On 05.11.2013 12:22, Oskari Saarenmaa wrote:
> >This makes it easy to see if the binaries were built from a real release
> >or if they were built from a custom git tree.
>
> Hmm, that would mean that a build from "git checkout R
* Robert Haas (robertmh...@gmail.com) wrote:
> Now maybe that's fine. But given that, I think it's pretty important
> that we get the syntax right. Because if you're adding a feature
> primarily to add a more convenient syntax, then the syntax had better
> actually be convenient.
I agree that we
Hello.
Examining pg_dump sources recently I've found that different exit
procedure used for the same situations.
A quick example from pg_dump.c:
if (dataOnly && schemaOnly)
exit_horribly(NULL, "options -s/--schema-only and
-a/--data-only cannot be used together\n");
On Mon, Nov 4, 2013 at 8:17 PM, Noah Misch wrote:
> On Mon, Nov 04, 2013 at 02:34:02PM -0500, Tom Lane wrote:
>> Noah Misch writes:
>> > On Fri, Nov 01, 2013 at 04:51:34PM +, Tom Lane wrote:
>> >> Remove internal uses of CTimeZone/HasCTZSet.
>>
>> > This changed EncodeDateTime() output for US
On Mon, Nov 4, 2013 at 8:46 PM, Craig Ringer wrote:
> On 11/04/2013 11:17 PM, Robert Haas wrote:
>> I'd still like to here what's wrong with what I said here:
>>
>> http://www.postgresql.org/message-id/ca+tgmoyr1phw3x9vnvuwdcfxkzk2p_jhtwc0fv2q58negcx...@mail.gmail.com
>
> For me, just my understan
On Mon, Nov 4, 2013 at 8:00 PM, Craig Ringer wrote:
> On 11/04/2013 09:55 PM, Robert Haas wrote:
>> I continue to think that this syntax is misguided. For SELECT and
>> DELETE there is only read-side security, and for INSERT there is only
>> write-side security, so that's OK as far as it goes, bu
Hello,
Please find attached pg_stat_statements-identification-v9.patch.
I have tried to address the following review comments
1. Use version PGSS_TUP_V1_2
2.Fixed total time being zero
3. Remove 'session_start' from the view and use point release number
to generate queryid
4. Hide only queryid and
On Tue, Nov 5, 2013 at 6:57 AM, Leonardo Francalanci wrote:
> Simon Riggs wrote
>> Minmax indexes seem to surprise many people, so broad generalisations
>> aren't likely to be useful.
>>
>> I think the best thing to do is to publish some SQL requests that
>> demonstrate in detail what you are tryi
MauMau wrote:
> From: "Albe Laurenz"
>> If I understood the discussion correctly the use case is that
>> there are advantages to having a database encoding different
>> from UTF-8, but you'd still want sume UTF-8 columns.
>>
>> Wouldn't it be a better design to allow specifying the encoding
>> per
From: "Albe Laurenz"
If I understood the discussion correctly the use case is that
there are advantages to having a database encoding different
from UTF-8, but you'd still want sume UTF-8 columns.
Wouldn't it be a better design to allow specifying the encoding
per column? That would give you m
On 05.11.2013 12:22, Oskari Saarenmaa wrote:
This makes it easy to see if the binaries were built from a real release
or if they were built from a custom git tree.
Hmm, that would mean that a build from "git checkout REL9_3_1" produces
a different binary than one built from postgresql-9.3.1.ta
On 05.11.2013 13:21, Soroosh Sardari wrote:
When PG crashes or the computer turned down unexpectedly, next time
postmaster
starts up, it does the crash recovery, actually redo xlog records, vacuum,
etc.
What module is responsible for crash recovery?
See src/backend/access/transam/xlog.c. The c
Hi
When PG crashes or the computer turned down unexpectedly, next time
postmaster
starts up, it does the crash recovery, actually redo xlog records, vacuum,
etc.
What module is responsible for crash recovery?
Regards,
Soroosh Sardari
Simon Riggs wrote
> On 5 November 2013 09:57, Leonardo Francalanci <
> m_lists@
> > wrote:
>> While I do believe in testing (since "In theory there is no difference
>> between theory and practice. In practice there is"), I would like to know
>> the "properties" of the minmax index before trying i
On 5 November 2013 09:57, Leonardo Francalanci wrote:
> Simon Riggs wrote
>> Minmax indexes seem to surprise many people, so broad generalisations
>> aren't likely to be useful.
>>
>> I think the best thing to do is to publish some SQL requests that
>> demonstrate in detail what you are trying to
This makes it easy to see if the binaries were built from a real release
or if they were built from a custom git tree.
---
configure.in | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/configure.in b/configure.in
index a4baeaf..7c5b3ce 100644
--- a/configure.in
+++ b/con
Simon Riggs wrote
> Minmax indexes seem to surprise many people, so broad generalisations
> aren't likely to be useful.
>
> I think the best thing to do is to publish some SQL requests that
> demonstrate in detail what you are trying to achieve and test them
> against minmax indexes. That way we c
> Hello,
>
> > > With this index, you will get a different plan like this,
> > >
> > Exactly my point, can we look at making windowing functions
> > smart and make use of available indexes?
>
> I might have guessed..
>
>
> > > Does this satisfies your needs?
> > >
> > Not exactly. If I have missed
On 5 November 2013 08:32, Leonardo Francalanci wrote:
> Simon Riggs wrote
>> Everybody on this thread is advised to look closely at Min Max indexes
>> before starting any further work.
>>
>> MinMax will give us access to many new kinds of plan, plus they are
>> about as close to perfectly efficien
Arul Shaji Arulappan wrote:
> Attached is a patch that implements the first set of changes discussed
> in this thread originally. They are:
>
> (i) Implements NCHAR/NVARCHAR as distinct data types, not as synonyms so
> that:
> - psql \d can display the user-specified data types.
> - pg
Simon Riggs wrote
> Everybody on this thread is advised to look closely at Min Max indexes
> before starting any further work.
>
> MinMax will give us access to many new kinds of plan, plus they are
> about as close to perfectly efficient, by which I mean almost zero
> overhead, with regard to ins
Andres Freund-3 wrote
> On 2013-11-04 11:27:33 -0500, Robert Haas wrote:
>> On Mon, Nov 4, 2013 at 11:24 AM, Claudio Freire <
> klaussfreire@
> > wrote:
>> > Such a thing would help COPY, so maybe it's worth a look
>>
>> I have little doubt that a deferred insertion buffer of some kind
>> could
82 matches
Mail list logo
