On Wed, Sep 18, 2013 at 9:54 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello
thank you,
I have no comments
Thanks.
Assigned it to committer.
Regards
Pavel
--
Jeevan B Chalke
On Thu, Sep 19, 2013 at 2:25 PM, samthakur74 samthaku...@gmail.com wrote:
I got the segmentation fault when I tested the case where the
least-executed
query statistics is discarded, i.e., when I executed different queries more
than
pg_stat_statements.max times. I guess that the patch might have
Kevin Grittner kgri...@ymail.com writes:
There are examples in the patch and this thread, but rather than
reference back to those I'll add a new one. Without the patch:
Thanks much for doing that.
The problem, as I see it, is that the view and the concurrently
refreshed materialized view
On 2013-09-18 11:02:50 +0200, Andres Freund wrote:
On 2013-09-18 11:55:24 +0530, Amit Kapila wrote:
I think that ship has long since sailed. postgresql.conf has allowed
foo.bar style GUCs via custom_variable_classes for a long time, and
these days we don't even require that but allow
On Thu, Sep 19, 2013 at 12:25 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Sep 19, 2013 at 11:48 AM, Sawada Masahiko sawada.m...@gmail.com
wrote:
I attached the patch which I have modified.
Thanks for updating the patch!
Here are the review comments:
Thank you for reviewing!
I
Hi Pavel,
I have reviewed you patch.
-- Patch got applied cleanly (using patch -p1)
-- Make Make install works fine
-- make check looks good
I done code-walk and it looks good. Also did some manual testing and haven't
found any issue with the implementation.
Patch introduced two new API
On Thu, Sep 19, 2013 at 7:07 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Thu, Sep 19, 2013 at 12:25 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Sep 19, 2013 at 11:48 AM, Sawada Masahiko sawada.m...@gmail.com
wrote:
I attached the patch which I have modified.
Thanks for
(Forgot to copy list)
From: David Rowley [mailto:dgrowle...@gmail.com]
Sent: 19 September 2013 22:35
To: Albe Laurenz
Subject: Re: REVIEW: Allow formatting in log_line_prefix
Hi Laurenz,
Thanks for the review.
Please see my comments below and the updated patch attached.
On Thu, Sep
On 09/19/2013 10:54 AM, Dimitri Fontaine wrote:
Kevin Grittner kgri...@ymail.com writes:
There are examples in the patch and this thread, but rather than
reference back to those I'll add a new one. Without the patch:
Thanks much for doing that.
The problem, as I see it, is that the view and
On 18.09.2013 16:22, Andres Freund wrote:
On 2013-09-16 16:59:28 +0300, Heikki Linnakangas wrote:
Here's a rebased version of the patch, including the above-mentioned fixes.
Nothing else new.
* We need some higherlevel description of the algorithm somewhere in the
source. I don't think
2013/9/19 Rushabh Lathia rushabh.lat...@gmail.com
Hi Pavel,
I have reviewed you patch.
-- Patch got applied cleanly (using patch -p1)
-- Make Make install works fine
-- make check looks good
I done code-walk and it looks good. Also did some manual testing and
haven't
found any issue
2013/9/18 Jim Nasby j...@nasby.net
On 9/14/13 11:55 PM, Pavel Stehule wrote:
2013/9/15 Marko Tiikkaja ma...@joh.to mailto:ma...@joh.to
On 2013-09-15 00:09, Pavel Stehule wrote:
this is a possibility for introduction a new hook and possibility
implement
asserions
On 9/18/13 5:11 PM, Pavel Stehule wrote:
In this code a assert fail can be lost in app log. Or can be knowingly
handled and ignored - what is wrong, and should not be allowed.
When I wrote a little bit complex procedures, I had to use a EXCEPTION WHEN
OTHERS clause - because I would not to lost
On 9/19/13 2:08 PM, Pavel Stehule wrote:
I think so similar frameworks will be exists (we have some similar
Probably You and me have a same opinion so only simple and very primitive
assert is not enough:
I see as useful feature for assertions:
a) possibility to specify a message (two
Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Kevin Grittner kgri...@ymail.com writes:
The problem, as I see it, is that the view and the concurrently
refreshed materialized view don't yield the same results for the
same query. The rows are equal, but they are not the same.
With the patch
On 2013-09-19 05:33:22 -0700, Kevin Grittner wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Kevin Grittner kgri...@ymail.com writes:
The problem, as I see it, is that the view and the concurrently
refreshed materialized view don't yield the same results for the
same query. The
2013/9/19 Marko Tiikkaja ma...@joh.to
On 9/19/13 2:08 PM, Pavel Stehule wrote:
I think so similar frameworks will be exists (we have some similar
Probably You and me have a same opinion so only simple and very primitive
assert is not enough:
I see as useful feature for assertions:
a)
Hi,
On 2013-09-19 14:42:19 +0300, Heikki Linnakangas wrote:
On 18.09.2013 16:22, Andres Freund wrote:
* Why can we do a GetOldestXmin(allDbs = false) in
BeginXidLSNRangeSwitch()?
Looks like a bug. I think I got the arguments backwards, was supposed to be
allDbs = true and ignoreVacuum =
Hannu Krosing ha...@2ndquadrant.com wrote:
the patch solves the general problem of when the table changes,
refresh
After saying it like this, the problem could also be solved by
including xmin(s) for rows from underlying table(s)in the
matview.
Would this be a better approach ?
Now
Something is weird in your latest patch. The header is:
diff -u -r b/postgresql/doc/src/sgml/config.sgml
a/postgresql/doc/src/sgml/config.sgml
--- b/postgresql/doc/src/sgml/config.sgml 2013-09-09 23:40:52.356371191
+1200
+++ a/postgresql/doc/src/sgml/config.sgml 2013-09-19
On 15 September 2013 01:35, Peter Eisentraut pete...@gmx.net wrote:
Here is an updated patch which fixes the bug you have pointed out.
On Thu, 2013-01-31 at 18:59 +0500, Ali Dar wrote:
I checked our your patch. There seems to be an issue when we have OUT
parameters after the DEFAULT
On 09/19/2013 02:41 PM, Kevin Grittner wrote:
Hannu Krosing ha...@2ndquadrant.com wrote:
the patch solves the general problem of when the table changes,
refresh
After saying it like this, the problem could also be solved by
including xmin(s) for rows from underlying table(s)in the
matview.
On 2013-09-19 14:40:35 +0200, Andres Freund wrote:
* I think heap_lock_tuple() needs to unset all-visible, otherwise we
won't vacuum that page again which can lead to problems since we
don't do full-table vacuums again?
It's OK if the page is never vacuumed again, the whole point
On Thu, Sep 19, 2013 at 7:32 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Sep 19, 2013 at 7:07 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Thu, Sep 19, 2013 at 12:25 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Sep 19, 2013 at 11:48 AM, Sawada Masahiko
On Tue, Sep 17, 2013 at 10:31 AM, Andres Freund and...@2ndquadrant.com wrote:
Rebased patches attached.
I spent a bit of time looking at these patches yesterday and today.
It seems to me that there's a fair amount of stylistic cleanup that is
still needed, and some pretty bad naming choices, and
On Tue, Sep 17, 2013 at 2:27 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
Robert == Robert Haas robertmh...@gmail.com writes:
Someone should do the same in WaitForBackgroundWorkerStartup so
that building with -Werror works.
Robert I don't get a warning there. Can you be more
On Wed, Sep 18, 2013 at 10:09 PM, Daniel Farina dan...@heroku.com wrote:
I'm not sure how many of you have been tracking this but courtesy of
lwn.net I have learned that it seems that the OOM killer behavior in
Linux 3.12 will be significantly different. And by description, it
sounds like an
Hi Robert,
On 2013-09-19 10:02:31 -0400, Robert Haas wrote:
On Tue, Sep 17, 2013 at 10:31 AM, Andres Freund and...@2ndquadrant.com
wrote:
Rebased patches attached.
I spent a bit of time looking at these patches yesterday and today.
It seems to me that there's a fair amount of stylistic
On Thu, Sep 19, 2013 at 9:12 AM, Robert Haas robertmh...@gmail.com wrote:
But, naturally, that will not be a problem
since all user-space code diligently checks the return status of every
system call and responds with well-tested error-handling code when
things go wrong.
That just short
On Thu, Sep 19, 2013 at 11:30 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Thu, Sep 19, 2013 at 9:12 AM, Robert Haas robertmh...@gmail.com wrote:
But, naturally, that will not be a problem
since all user-space code diligently checks the return status of every
system call and responds with
On 2013-09-19 18:23:07 +0200, Dimitri Fontaine wrote:
I've been told at several instances that this has been made for the JVM
and other such programs that want to allocate huge amount of memory even
if they don't really intend to use it.
That's not really related - what you describe is memory
On Thu, Sep 19, 2013 at 12:02 PM, Andres Freund and...@2ndquadrant.com wrote:
The problem is that it's not just about malloc() (aka brk() and
mmap()) and friends. It's about many of the other systemcalls. Like
e.g. send() to name one of the more likely ones.
*shrug*
If you're using for send()
On 2013-09-19 11:49:05 -0400, Robert Haas wrote:
On Thu, Sep 19, 2013 at 11:30 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Thu, Sep 19, 2013 at 9:12 AM, Robert Haas robertmh...@gmail.com wrote:
But, naturally, that will not be a problem
since all user-space code diligently checks the
On Thu, Sep 19, 2013 at 10:43 AM, Andres Freund and...@2ndquadrant.com wrote:
- Looking specifically at the 0004 patch, I think that the
RecentGlobalDataXmin changes are logically separate from the rest of
the patch, and that if we're going to commit them at all, it should be
separate from the
Andres Freund and...@2ndquadrant.com writes:
What has changed is how to react to situations where memory has been
overcommitted but is now actually needed.
Sure. You either have a failure at malloc() or usage, over commit is all
about never failing at malloc(), but now you have to deal with OOM
We intsall postgresql 9.3.0 server from FreeBSD ports
http://svnweb.freebsd.org/ports/head/databases/postgresql93-server/ the
administrator says that he already contains this patch.
--
View this message in context:
On Tue, Sep 17, 2013 at 7:04 PM, Andres Freund and...@2ndquadrant.com wrote:
1. We're not in a huge hurry to ensure that sinval notifications are
delivered in a timely fashion. We know that sinval resets are bad, so
if a backend is getting close to needing a sinval reset, we kick it in
an
Robert Haas robertmh...@gmail.com writes:
I laughed, too, but the reality is that at least as far as PG is
concerned it's probably a truthful statement, and if it isn't, nobody
here is likely to complain about having to fix it. Yeah, there's a
lot of other code out there not as well written
2013/9/19 David Johnston pol...@yahoo.com
Misa Simic wrote
I guess that rule can be achieved with triigers on TableA and TableC -
but
the same is true for FK (and FK constraint is more effective then trigger
-
that is why I wonder would it be useful/achievable to create that kind of
On Thu, Sep 19, 2013 at 12:52 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
It compiles without error and looks ok...
Thanks for checking. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
Robert == Robert Haas robertmh...@gmail.com writes:
bgworker.c: In function 'WaitForBackgroundWorkerStartup':
bgworker.c:866: warning: 'pid' may be used uninitialized in this function
Robert Does the attached patch fix it for you?
It compiles without error and looks ok...
--
Andrew
Hello
here is patch
Regards
Pavel
2013/9/19 Pavel Stehule pavel.steh...@gmail.com
2013/9/19 Rushabh Lathia rushabh.lat...@gmail.com
Hi Pavel,
I have reviewed you patch.
-- Patch got applied cleanly (using patch -p1)
-- Make Make install works fine
-- make check looks good
I
Marking this as Ready for committer.
Thanks a ton for reviewing the patch.
I rewrote the comments for this patch and fixed the incorrect
formatting in parse_relation.c. It used spaces instead of tabs, which
is why if you look at the patch file you'll see that the alignment
looked off. See
Misa Simic wrote
Hi hackers,
I just wonder how hard would be to implement something like Not In FK
Constraint or opposite to FK...
A more useful couple next sentences would be along the lines of:
I have this problemI've approached it by doingbut it seems that an
actual database
On Wed, Sep 18, 2013 at 12:53 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-18 08:46:08 -0400, Robert Haas wrote:
Here's another idea. At initdb time, create an empty directory called
called pg_you_can_load_stuff_from_here (pick a better name) inside
$PGDATA. Allow it to be
On Wed, Sep 18, 2013 at 6:20 PM, Greg Stark st...@mit.edu wrote:
The following code is in the ProcSleep at proc.c:1138.
GetBlockingAutoVacuumPgproc() should presumably always return a vacuum
pgproc entry since the deadlock state says it's blocked by autovacuum.
But I'm not really familiar
On Tue, Sep 17, 2013 at 7:10 PM, Andres Freund and...@2ndquadrant.com wrote:
I generally think the current logic for triggering VACUUMs via
autovacuum doesn't really make all that much sense in the days where we
have the visibility map.
Right now, whether or not to autovacuum is the rest of a
On Wed, Sep 18, 2013 at 6:42 PM, MauMau maumau...@gmail.com wrote:
It seems to me that these two points here are the real core of your
proposal. The rest is just syntactic sugar.
No, those are desirable if possible features. What's important is to
declare in the manual that PostgreSQL
On Sat, Sep 14, 2013 at 6:09 PM, Marko Tiikkaja ma...@joh.to wrote:
On 2013-09-14 23:55, Pavel Stehule wrote:
but introduction a reserved keword for one very special purpose (without
extensibility) is not prudent.
How about using an existing keyword then? ASSERTION used to be reserved in
On Wed, Sep 18, 2013 at 7:29 PM, Vik Fearing vik.fear...@dalibo.com wrote:
On 09/19/2013 12:55 AM, Dimitri Fontaine wrote:
We have, as a community, gone to a fair amount of trouble to make
the concept of equality pluggable and allow multiple types of
equality per type. To me it seems the
On Tue, Sep 17, 2013 at 6:56 PM, Andres Freund and...@2ndquadrant.com wrote:
That's more or less what I figured. One thing I'm uncomfortable with
is that, while this is useful for extensions, what do we do when we
have a similar requirement for core? The proposed GUC name is of the
format
create table tstztest( trange tstzrange );
postgres=# insert into tstztest select tstzrange(t, t + interval '1 month')
from generate_series('2012-01-01'::timestamptz,'2018-01-01','1 month')
as gs(t);
INSERT 0 73
postgres=# analyze tstztest;
ANALYZE
postgres=# select * from pg_stats where
I don't know if this has been discussed before, a cursory search of the
archives didn't turn up anything interesting. I perhaps didn't put in
the right keywords.
Unfortunately, the easiest way that I've found to reproduce this bug is
to apply the attached patch to the unaccent extension. This
Robert Haas robertmh...@gmail.com writes:
I think I'd prefer a GUC that allows specifying multiple directories
that are searched in order to a single symlinked directory.
Why?
I ask because I have the opposite preference, based on the precedent of
pg_xlog.
I understand Andres preference,
Robert Haas robertmh...@gmail.com wrote:
Right now, whether or not to autovacuum is the rest of a two-pronged
test. The first prong is based on number of updates and deletes
relative to table size; that triggers a regular autovacuum. The
second prong is based on age(relfrozenxid) and
Vik Fearing vik.fear...@dalibo.com writes:
I don't know if this has been discussed before, a cursory search of the
archives didn't turn up anything interesting. I perhaps didn't put in
the right keywords.
For others not to spend too much time on this: it seems like a problem
with the
On 2013-09-19 22:56:52 +0200, Dimitri Fontaine wrote:
Robert Haas robertmh...@gmail.com writes:
I think I'd prefer a GUC that allows specifying multiple directories
that are searched in order to a single symlinked directory.
Why?
I ask because I have the opposite preference, based on
On Thu, Sep 19, 2013 at 2:42 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
* switchFinishXmin and nextSwitchXid should probably be either volatile
or have a compiler barrier between accessing shared memory and
checking them. The compiler very well could optimize them away and
On 2013-09-19 14:57:53 -0400, Robert Haas wrote:
On Tue, Sep 17, 2013 at 6:56 PM, Andres Freund and...@2ndquadrant.com wrote:
I think that ship has long since sailed. postgresql.conf has allowed
foo.bar style GUCs via custom_variable_classes for a long time, and
these days we don't even
2013/9/16 Satoshi Nagayasu sn...@uptime.jp
(2013/07/06 1:16), Pavel Stehule wrote:
I am sending a patch that removes strict requirements for DROP IF
EXISTS statements. This behave is similar to our ALTER IF EXISTS
behave now.
postgres=# DROP CAST IF EXISTS (sss AS public.casttesttype);
On 09/12/2013 06:27 PM, Kevin Grittner wrote:
Attached is a patch for a bit of infrastructure I believe to be
necessary for correct behavior of REFRESH MATERIALIZED VIEW
CONCURRENTLY as well as incremental maintenance of matviews.
Here is attempt at a review of the v1 patch.
There has been a
From: Robert Haas robertmh...@gmail.com
That may be what's important to you, but it's not what's important to
me.
National character types support may be important to some potential users of
PostgreSQL and the popularity of PostgreSQL, not me. That's why national
character support is listed
On 2013-09-19 14:39:43 -0400, Robert Haas wrote:
On Tue, Sep 17, 2013 at 7:10 PM, Andres Freund and...@2ndquadrant.com wrote:
I generally think the current logic for triggering VACUUMs via
autovacuum doesn't really make all that much sense in the days where we
have the visibility map.
So I'm just going to make the code defensive and assume NULL is possible
when if maybe it isn't.
In case it's not clear, this is one of the thing's Xi Wang's took picked
up. There not to many but it turns out they are indeed not all in the adt
code so I might wait until after the commit fest to
Hi,
I'm Looking for information on our elephant: especially how/why we
chose elephant as our mascot.
According to:
http://wiki.postgresql.org/wiki/Logo
The discussion was back to 1997 on the hackers list. Unfortunately the
official archive for 1997 was lost. Mine seems to be gone too. Any
Tatsuo,
I have emails even from 1995 ! You can see that historical message here:
http://www.pgsql.ru/db/mw/msg.html?mid=1238939
Re: [HACKERS] PostgreSQL logo.
*Author:* yang( at )sjuphil( dot )sju( dot )edu
*Date:* 1997-04-03 20:36:33
On Mon, Sep 16, 2013 at 8:49 AM, MauMau maumau...@gmail.com wrote:
2. NCHAR/NVARCHAR columns can be used in non-UTF-8 databases and always
contain Unicode data.
...
3. Store strings in UTF-16 encoding in NCHAR/NVARCHAR columns.
Fixed-width encoding may allow faster string manipulation as
Oh great! Thank you Oleg!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
Tatsuo,
I have emails even from 1995 ! You can see that historical message here:
http://www.pgsql.ru/db/mw/msg.html?mid=1238939
Re: [HACKERS]
On Thu, Sep 19, 2013 at 4:54 PM, Josh Berkus j...@agliodbs.com wrote:
create table tstztest( trange tstzrange );
postgres=# insert into tstztest select tstzrange(t, t + interval '1 month')
from generate_series('2012-01-01'::timestamptz,'2018-01-01','1 month')
as gs(t);
INSERT 0 73
Hi,
That may be what's important to you, but it's not what's important to
me.
National character types support may be important to some potential users
of PostgreSQL and the popularity of PostgreSQL, not me. That's why
national character support is listed in the PostgreSQL TODO wiki.
On Thu, Sep 19, 2013 at 2:48 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-18 11:02:50 +0200, Andres Freund wrote:
On 2013-09-18 11:55:24 +0530, Amit Kapila wrote:
I think that ship has long since sailed. postgresql.conf has allowed
foo.bar style GUCs via
On Thu, Sep 19, 2013 at 10:19 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello
here is patch
Looks good.
Marking it as Ready for Committer.
Regards
Pavel
2013/9/19 Pavel Stehule pavel.steh...@gmail.com
2013/9/19 Rushabh Lathia rushabh.lat...@gmail.com
Hi Pavel,
I
72 matches
Mail list logo
