On Mon, Sep 16, 2013 at 3:47 AM, Thom Brown t...@linux.com wrote:
On 15 September 2013 01:14, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Hi,
Here's a reviewable version of what I've dubbed Minmax indexes.
Thanks for the patch, but I seem to have immediately hit a snag:
pgbench=#
syncrep.c: In function ‘SyncRepReleaseWaiters’:
syncrep.c:421:6: warning: variable ‘numdataflush’ set but not used
[-Wunused-but-set-variable]
Sorry I forgot fix it.
I have attached the patch which I modified.
Attached patch combines documentation patch and source-code patch.
--
Apt.pgdg got the patch present in postgresql head applyed.
Erm, isn't apt.postgresql.org supposed to ship the *official*
PostgreSQL versions? Given that this issue affects all distros, I
don't see why Ubuntu/Debian need to be patched separately.
Well, the patches are applyed on the debian
On 17 September 2013 07:20, Jaime Casanova ja...@2ndquadrant.com wrote:
On Mon, Sep 16, 2013 at 3:47 AM, Thom Brown t...@linux.com wrote:
On 15 September 2013 01:14, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Hi,
Here's a reviewable version of what I've dubbed Minmax indexes.
Hi Marko,
I have reviewed this patch.
1. Patch applies well.
2. make and make install is fine
3. make check is fine too.
But as Peter pointed out plperl regression tests are failing.
I just did grep on .sql files and found following files which has RAISE
statement into it. These files too need
On Mon, Sep 16, 2013 at 7:22 PM, Haribabu kommi
haribabu.ko...@huawei.comwrote:
*On *14 August 2013 Rushabh Lathia wrote:**
** **
postgres=# create table test ( a timestamptz);
CREATE TABLE
** **
-- Date with year 1000
postgres=# insert into test values ( 'Sat Mar 11
On 09/16/2013 04:01 PM, Kevin Grittner wrote:
Hannu Krosing ha...@2ndquadrant.com wrote:
Lots of people were bitten when (undocumented) hash
functions were changed thus breaking hash-based partitioning.
Nobody can be affected by the new operators in this patch unless
they choose to use them
I ran into a typo. Attached is a patch.
Thanks,
Best regards,
Etsuro Fujita
typofix-20130917.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I think the document in advanced.sgml should be corrected, though I might
misunderstand the rules of usage. Attached is a patch.
Thanks,
Best regards,
Etsuro Fujita
docsfix-20130917.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Hi Amit.
I gone through the mail thread discussion regarding this issue and reviewed
you patch.
-- Patch get applied cleanly on Master branch
-- Make and Make Install fine
-- make check also running cleanly
In the patch code changes looks good to me.
This patch having two part:
1) Allowed
Hi,
I did put some time review the patch, please see my findings below i.e.
1. It seems that you have used strdup() on multiple places in the patch,
e.g. in the below code snippet is it going to lead crash if newp-ident is
NULL because of strdup() failure ?
static EPlan *
find_plan(char
On Tue, Sep 17, 2013 at 3:13 PM, Asif Naeem anaeem...@gmail.com wrote:
Hi,
I did put some time review the patch, please see my findings below i.e.
1. It seems that you have used strdup() on multiple places in the patch,
e.g. in the below code snippet is it going to lead crash if newp-ident
On Sun, Sep 15, 2013 at 3:54 PM, samthakur74 samthaku...@gmail.com wrote:
You have added this email to the commit fest, but it contains no patch.
Please add the email with the actual patch.
I hope its attached now!
You seem to have forgotten to include the pg_stat_statements--1.2.sql
and
Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-16 15:26:08 -0700, Kevin Grittner wrote:
I can understand claiming that the risk is acceptable but
arguing it's not there seems extremly strange to me.
It's not a risk. It's why the operator exists.
Pft. It's fine if the materialized
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of MauMau
Hello,
I think it would be nice for PostgreSQL to support national character
types
largely because it should ease migration from other DBMSs.
[Reasons why we
On Tue, Sep 17, 2013 at 8:23 AM, Kevin Grittner kgri...@ymail.com wrote:
Of course, that begs the question of whether == is already taken.
If not, we could knock one '=' off of everything above except for
equals. What existing uses are known for == ?
== is already taken as a common typo in
On Tue, Sep 17, 2013 at 3:45 PM, Samrat Revagade
revagade.sam...@gmail.com wrote:
syncrep.c: In function ‘SyncRepReleaseWaiters’:
syncrep.c:421:6: warning: variable ‘numdataflush’ set but not used
[-Wunused-but-set-variable]
Sorry I forgot fix it.
I have attached the patch which I
On Tue, 17 September 2013 14:33 Rushabh Lathia wrote:
On Mon, Sep 16, 2013 at 7:22 PM, Haribabu kommi
haribabu.ko...@huawei.commailto:haribabu.ko...@huawei.com wrote:
On 14 August 2013 Rushabh Lathia wrote:
postgres=# create table test ( a timestamptz);
CREATE TABLE
-- Date with year 1000
On Mon, Sep 16, 2013 at 4:13 PM, Andrew Gierth
and...@tao11.riddles.org.ukwrote:
Alexander == Alexander Korotkov aekorot...@gmail.com writes:
Alexander 2) NaN coordinates should be processed in GiST index scan
Alexander like in sequential scan.
postgres=# select * from pts order by a -
On 09/17/2013 02:46 PM, Rod Taylor wrote:
On Tue, Sep 17, 2013 at 8:23 AM, Kevin Grittner kgri...@ymail.com
mailto:kgri...@ymail.com wrote:
Of course, that begs the question of whether == is already taken.
If not, we could knock one '=' off of everything above except for
equals.
On 09/17/2013 12:52 AM, Andres Freund wrote:
On 2013-09-16 15:26:08 -0700, Kevin Grittner wrote:
I can understand claiming that the risk is acceptable but arguing
it's not there seems extremly strange to me.
It's not a risk. It's why the operator exists.
Pft. It's fine if the materialized
On Tue, Sep 17, 2013 at 3:30 AM, Thom Brown t...@linux.com wrote:
On 17 September 2013 07:20, Jaime Casanova ja...@2ndquadrant.com wrote:
On Mon, Sep 16, 2013 at 3:47 AM, Thom Brown t...@linux.com wrote:
On 15 September 2013 01:14, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Hi,
On Wed, Sep 11, 2013 at 12:43 PM, Satoshi Nagayasu sn...@uptime.jp wrote:
(2013/09/10 22:48), Peter Eisentraut wrote:
On 9/10/13 3:37 AM, Satoshi Nagayasu wrote:
Thanks for checking. Revised one attached.
Please fix compiler warning:
walwriter.c: In function ‘WalWriterMain’:
On 9/16/13 9:59 AM, Heikki Linnakangas wrote:
Here's a rebased version of the patch, including the above-mentioned
fixes. Nothing else new.
It still fails to apply. You might need to rebase it again.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On 17 September 2013 14:37, Jaime Casanova ja...@2ndquadrant.com wrote:
On Tue, Sep 17, 2013 at 3:30 AM, Thom Brown t...@linux.com wrote:
On 17 September 2013 07:20, Jaime Casanova ja...@2ndquadrant.com
wrote:
On Mon, Sep 16, 2013 at 3:47 AM, Thom Brown t...@linux.com wrote:
On 15
On 2013-09-17 09:41:47 -0400, Peter Eisentraut wrote:
On 9/16/13 9:59 AM, Heikki Linnakangas wrote:
Here's a rebased version of the patch, including the above-mentioned
fixes. Nothing else new.
It still fails to apply. You might need to rebase it again.
FWIW, I don't think it's too
On 9/15/13 11:30 AM, Andres Freund wrote:
On 2013-09-15 11:20:20 -0400, Peter Eisentraut wrote:
On Sat, 2013-09-14 at 22:49 +0200, Andres Freund wrote:
Attached you can find the newest version of the logical changeset
generation patchset.
You probably have bigger things to worry about, but
You seem to have forgotten to include the pg_stat_statements--1.2.sql
and pg_stat_statements--1.1--1.2.sql in the patch.
Sorry again. Please find updated patch attached.
http://www.postgresql.org/mailpref/pgsql-hackers
Kevin Grittner kgri...@ymail.com writes:
= equals (but doesn't necessarily look the same as)
=== IS NOT DISTINCT FROM as an operator
reserved for has no user-visible differences from
= stored image is the same
I understand the need for more than one equality
On Sat, Sep 14, 2013 at 7:23 AM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
Peter Please fix compiler warnings:
Someone should do the same in WaitForBackgroundWorkerStartup so that
building with -Werror works.
I don't get a warning there. Can you be more specific about the problem?
On Sat, Sep 14, 2013 at 9:42 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
I have developed the attached patch based on your suggestion. I did not
see anything in the code that would make it STABLE, except a lookup of a
dictionary library:
dictOid =
In make check, there are 4 shared libraries that are loaded for test cases
from the src/test/regress folder. Whereas, output of other libraries
contain @libdir@ tag, the output file for security_label (dumm_seclabel)
contains a tag for @abs_builddir@ in the output/security_label.source file.
I
On Sat, Sep 14, 2013 at 3:23 PM, Andrew Dunstan and...@dunslane.net wrote:
While writing slides for pgopen next week, I noticed that the JSON docs on
json_populate_record and json_populate_recordset contain this sentence:
A column may only be specified once.
IIRC we removed that
On Sat, Sep 14, 2013 at 5:21 PM, Andres Freund and...@2ndquadrant.com wrote:
a) allow repeatedly qualified names like a.b.c
The attached patch does a)
What is the use case for this change?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent
On 2013-09-17 10:23:30 -0400, Robert Haas wrote:
On Sat, Sep 14, 2013 at 5:21 PM, Andres Freund and...@2ndquadrant.com wrote:
a) allow repeatedly qualified names like a.b.c
The attached patch does a)
What is the use case for this change?
Check
On 2013-09-17 10:57:46 -0400, Robert Haas wrote:
On Mon, Sep 16, 2013 at 1:25 AM, Satoshi Nagayasu sn...@uptime.jp wrote:
How about adding new system view with new function which returns
a single pg_controldata value in text type, and using a cast for
each column in the view definition?
Pavel Stehule escribió:
fixed - see attached patch
There's a typo tange in some error messages, which has found its way
to the regression tests.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers
On Sun, Sep 15, 2013 at 8:05 PM, Jeff Janes jeff.ja...@gmail.com wrote:
But note that the current behavior is worse in this regard. If you specify
a scale of 4 at the column level, than it is not possible to distinguish
between 5.000 and 5. on a per-value basis within that column. If the
On Mon, Sep 16, 2013 at 1:25 AM, Satoshi Nagayasu sn...@uptime.jp wrote:
How about adding new system view with new function which returns
a single pg_controldata value in text type, and using a cast for
each column in the view definition?
CREATE VIEW pg_catalog.pg_controldata AS
SELECT
On Tue, Sep 17, 2013 at 10:48 PM, samthakur74 samthaku...@gmail.com wrote:
You seem to have forgotten to include the pg_stat_statements--1.2.sql
and pg_stat_statements--1.1--1.2.sql in the patch.
Sorry again. Please find updated patch attached.
pg_stat_statements--1.2.sql is missing.
On Tue, Sep 17, 2013 at 10:59 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-17 10:57:46 -0400, Robert Haas wrote:
On Mon, Sep 16, 2013 at 1:25 AM, Satoshi Nagayasu sn...@uptime.jp wrote:
How about adding new system view with new function which returns
a single pg_controldata
On Tue, Sep 17, 2013 at 8:43 AM, Thom Brown t...@linux.com wrote:
On 17 September 2013 14:37, Jaime Casanova ja...@2ndquadrant.com wrote:
On Tue, Sep 17, 2013 at 3:30 AM, Thom Brown t...@linux.com wrote:
On 17 September 2013 07:20, Jaime Casanova ja...@2ndquadrant.com
wrote:
On Mon, Sep
On Sat, Sep 14, 2013 at 6:27 PM, Peter Geoghegan p...@heroku.com wrote:
Note that today there is no guarantee that the original waiter for a
duplicate-inserting xact to complete will be the first one to get a
second chance, so I think it's hard to question this on correctness
grounds. Even if
On 9/7/13 12:34 AM, Andres Freund wrote:
What I was thinking of was to keep track of the oldest xids on pages
that cannot be marked all visible. I haven't thought about the
statistics part much, but what if we binned the space between
[RecentGlobalXmin, -nextXid) into 10 bins and counted the
On Mon, Sep 16, 2013 at 11:02:28PM -0300, Alvaro Herrera wrote:
relscan.h is a bit of an unfortunate header because it requires a lot of
other headers to compile, and is also required by execnodes.h. This
Not in my copy of the source tree. execnodes.h uses the corresponding
typedefs that
Heikki Linnakangas escribió:
Here's a rebased version of the patch, including the above-mentioned
fixes. Nothing else new.
Nice work. I apologize for the conflicts I created yesterday.
I would suggest renaming varsup_internal.h to varsup_xlog.h.
You added a FIXME comment to
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 specific about
Robert the problem?
bgworker.c: In function
Noah Misch wrote:
On Mon, Sep 16, 2013 at 11:02:28PM -0300, Alvaro Herrera wrote:
relscan.h is a bit of an unfortunate header because it requires a lot of
other headers to compile, and is also required by execnodes.h. This
Not in my copy of the source tree. execnodes.h uses the
On Mon, Sep 16, 2013 at 9:13 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Robert, do you remember why you put the pagesize = sysconf(_SC_PAGE_SIZE);
call in the new mmap() shared memory allocator?
Hmm, no. Unfortunately, I don't. We could try ripping it out and see
if the buildfarm
On Tue, Sep 17, 2013 at 2:30 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
-1 on header restructuring in the absence of noteworthy compile-time
benchmark
improvements. Besides the obvious benchmark of full-build time, one could
exercise the benefit of fewer header dependencies by
Hi,
Attached is a patch with the following changes:
On 16/09/2013 10:57, I wrote:
On 9/16/13 8:04 AM, Ian Lawrence Barwick wrote:
However the sample function provided in the documentation throws a
runtime error due to a missing FROM-clause entry.
Ugh. I'll look into fixing that.
Fixed.
On Tue, Sep 17, 2013 at 10:27 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-17 10:23:30 -0400, Robert Haas wrote:
On Sat, Sep 14, 2013 at 5:21 PM, Andres Freund and...@2ndquadrant.com
wrote:
a) allow repeatedly qualified names like a.b.c
The attached patch does a)
What is
On 17 September 2013 22:03, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Thom Brown wrote:
Thanks for testing.
Thanks for the patch, but I seem to have immediately hit a snag:
pgbench=# CREATE INDEX minmaxtest ON pgbench_accounts USING minmax (aid);
PANIC: invalid xlog record
Robert Haas escribió:
Personally, I'm not particularly in favor of these kinds of changes.
The changes we made last time broke a lot of extensions - including
some proprietary EDB ones that I had to go fix. I think a lot of
people spent a lot of time fixing broken builds, at EDB and
Thom Brown wrote:
Thanks for testing.
Thanks for the patch, but I seem to have immediately hit a snag:
pgbench=# CREATE INDEX minmaxtest ON pgbench_accounts USING minmax (aid);
PANIC: invalid xlog record length 0
Silly mistake I had already made in another patch. Here's an
incremental
On Tue, September 17, 2013 23:03, Alvaro Herrera wrote:
[minmax-1.patch. + minmax-2-incr.patch. (and initdb)]
The patches apply and compile OK.
I've not yet really tested; I just wanted to mention that make check gives
the following differences:
***
On Mon, Sep 16, 2013 at 10:38 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-08-29 10:39:09 -0400, Robert Haas wrote:
I have been of the opinion for some time now that the
shared-invalidation code is not a particularly good design for much of
what we need. Waiting for an old snapshot
Thom Brown wrote:
Hit another issue with exactly the same procedure:
pgbench=# create index minmaxtest on pgbench_accounts using minmax (aid);
ERROR: lock 176475 is not held
That's what I get for restructuring the way buffers are acquired to use
the FSM, and then neglecting to test
On 2013-09-16 21:24, Pavel Stehule wrote:
2. a failed assert should to raise a exception, that should not be handled
by any exception handler - similar to ERRCODE_QUERY_CANCELED - see
exception_matches_conditions.
I'm not sure what I think about that idea. I see decent arguments for
it
Erik Rijkers wrote:
On Tue, September 17, 2013 23:03, Alvaro Herrera wrote:
[minmax-1.patch. + minmax-2-incr.patch. (and initdb)]
The patches apply and compile OK.
I've not yet really tested; I just wanted to mention that make check gives
the following differences:
Oops, I forgot
On 2013-09-17 12:53, Dean Rasheed wrote:
Thanks for the review. Those changes all look sensible to me.
Here's an updated patch incorporating all your fixes, and rebased to
apply without offsets.
Looks good to me. Marking this one ready for committer.
Regards,
Marko Tiikkaja
--
Sent via
On 2013-09-17 11:37:35 -0500, Jim Nasby wrote:
On 9/7/13 12:34 AM, Andres Freund wrote:
What I was thinking of was to keep track of the oldest xids on pages
that cannot be marked all visible. I haven't thought about the
statistics part much, but what if we binned the space between
On 2013-09-17 16:34:37 -0400, Robert Haas wrote:
On Mon, Sep 16, 2013 at 10:38 AM, Andres Freund and...@2ndquadrant.com
wrote:
Actually, the shared inval code already has that knowledge, doesn't it?
ISTM all we'd need is have a sequence number of SI entries which has
to be queryable. Then
Hi,
On 2013-09-17 16:24:34 -0400, Robert Haas wrote:
On Tue, Sep 17, 2013 at 10:27 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2013-09-17 10:23:30 -0400, Robert Haas wrote:
What is the use case for this change?
Check
On 2013-09-17 12:29:51 -0400, Robert Haas wrote:
But I'm skeptical that you're going to be able to accomplish that,
especially without adversely affecting maintainability. I think the
way that you're proposing to use lwlocks here is sufficiently
different from what the rest of the system does
On Tue, Sep 17, 2013 at 9:52 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Sep 17, 2013 at 3:45 PM, Samrat Revagade
revagade.sam...@gmail.com wrote:
syncrep.c: In function ‘SyncRepReleaseWaiters’:
syncrep.c:421:6: warning: variable ‘numdataflush’ set but not used
On Wed, Sep 18, 2013 at 10:35 AM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Tue, Sep 17, 2013 at 9:52 PM, Fujii Masao masao.fu...@gmail.com wrote:
I set up synchronous replication with synchronous_transfer = all, and then I
ran
pgbench -i and executed CHECKPOINT in the master. After
On Tue, Sep 17, 2013 at 3:29 PM, Rushabh Lathia
rushabh.lat...@gmail.com wrote:
Hi Amit.
I gone through the mail thread discussion regarding this issue and reviewed
you patch.
-- Patch get applied cleanly on Master branch
-- Make and Make Install fine
-- make check also running cleanly
On Wed, Sep 18, 2013 at 11:45 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Sep 18, 2013 at 10:35 AM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Tue, Sep 17, 2013 at 9:52 PM, Fujii Masao masao.fu...@gmail.com wrote:
I set up synchronous replication with synchronous_transfer = all,
On Wed, Sep 18, 2013 at 1:05 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Wed, Sep 18, 2013 at 11:45 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Sep 18, 2013 at 10:35 AM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Tue, Sep 17, 2013 at 9:52 PM, Fujii Masao
Attached.
Regards
Ian Barwick
psql-command-c-typo.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
You seem to have forgotten to include the pg_stat_statements--1.2.sql
and pg_stat_statements--1.1--1.2.sql in the patch.
Sorry again. Please find updated patch attached.
I did not add pg_stat_statements--1.2.sql. I have added that now and
updated the patch again.
The patch attached should
On Tue, Sep 17, 2013 at 6:20 PM, Andres Freund and...@2ndquadrant.com wrote:
I agree that unpredictable deadlocks are bad. I think the fundamental
problem with UPSERT, MERGE, and this proposal is what happens when the
conflicting tuple is present but not visible to your scan, either
because
73 matches
Mail list logo
