On Monday, March 17, 2014, Atri Sharma atri.j...@gmail.com wrote:
On Mon, Mar 17, 2014 at 10:58 PM, Stephen Frost
sfr...@snowman.netjavascript:_e(%7B%7D,'cvml','sfr...@snowman.net');
wrote:
* Atri Sharma
(atri.j...@gmail.comjavascript:_e(%7B%7D,'cvml','atri.j...@gmail.com');)
wrote:
On Monday, March 17, 2014, Tom Lane t...@sss.pgh.pa.us wrote:
Claudio Freire klaussfre...@gmail.com javascript:; writes:
On Mon, Mar 17, 2014 at 7:01 PM, Jim Nasby j...@nasby.net javascript:;
wrote:
Even better would be if the planner could estimate how bad a plan will
become if we made
Le mardi 18 mars 2014 03:54:19 Kouhei Kaigai a écrit :
I hacked on this for awhile, but there remain two matters on which I'm
uncertain about the right way forward.
(1) To acquire the old tuple for UPDATE/DELETE operations, the patch
closely
parallels our handling for INSTEAD OF
(2014/03/17 22:37), Tom Lane wrote:
KONDO Mitsumasa kondo.mitsum...@lab.ntt.co.jp writes:
(2014/03/17 18:02), Heikki Linnakangas wrote:
On 03/17/2014 10:40 AM, KONDO Mitsumasa wrote:
There is an infinite number of variants of the TPC-B test that we could
include
in pgbench. If we start
(2014/03/17 23:29), Robert Haas wrote:
On Sat, Mar 15, 2014 at 4:50 AM, Mitsumasa KONDO
kondo.mitsum...@gmail.com wrote:
There are explanations and computations as comments in the code. If it is
about the documentation, I'm not sure that a very precise mathematical
definition will help a lot of
Hello,
By the way, Can I have a simple script to build an environment to
run this on?
I built test environment and ran the simple test using
postgres_fdw and got parameterized path from v3 patch on the
following operation as shown there, and v6 also gives one, but I
haven't seen the
And I find new useful point of this feature. Under following results are
'--gaussian=20' case and '--gaussian=2' case, and postgresql setting is same.
[mitsu-ko@pg-rex31 pgbench]$ ./pgbench -c8 -j4 --gaussian=20 -T30 -P 5
starting vacuum...end.
progress: 5.0 s, 4285.8 tps, lat 1.860 ms stddev
On 03/18/2014 11:57 AM, KONDO Mitsumasa wrote:
I think that this feature will be also useful for survey new buffer-replace
algorithm and checkpoint strategy, so on.
Sure. No doubt about that.
If we remove this option, it is really dissapointed..
As long as we get the \setrandom changes in,
On 18.03.14 00:15, Tom Lane wrote:
Jim Nasby j...@nasby.net writes:
On 3/17/14, 8:47 AM, Tom Lane wrote:
(Note that this is only one of assorted O(N^2) behaviors in older versions
of pg_dump; we've gradually stamped them out over time.)
On that note, it's recommended that when you are
On 8 March 2014 11:14, Simon Riggs si...@2ndquadrant.com wrote:
On 7 March 2014 09:04, Simon Riggs si...@2ndquadrant.com wrote:
The right thing to do here is to not push to the extremes. If we mess
too much with the ruleutil stuff it will just be buggy. A more
considered analysis in a later
Hi, PostgreSQL community!
My name is Artur Gadelshin, I'm from Saint-Petersburg, Russia. I'm 4th year
student in Computer Scince.
I haven't enough experience in C/C++, but I really in love with PostgreSQL
(but, yes, haven't experience to develop this). My dream is to be computer
scientist or
Artur,
* Artur Gadelshin (ar.gadels...@gmail.com) wrote:
Is there any chance to participate in your community and get some help in
envolving, may be simple tasks, advices about books which I should read or
smth else.
There are a number of GSoC project ideas here:
When inserting into a B-tree index, all the pages are read-locked when
descending the tree. When we reach the leaf page, the read-lock is
exchanged for a write-lock.
There's nothing wrong with that, but why don't we just directly grab a
write-lock on the leaf page? When descending, we know
On Mon, Mar 17, 2014 at 11:54 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
I hacked on this for awhile, but there remain two matters on which I'm
uncertain about the right way forward.
(1) To acquire the old tuple for UPDATE/DELETE operations, the patch closely
parallels our handling for
On Thu, Mar 13, 2014 at 9:07 PM, Josh Berkus j...@agliodbs.com wrote:
On 03/13/2014 05:28 PM, Robert Haas wrote:
Well we may have kind of hosed ourselves, because the in-memory data
structures that represent the data structure have an in_use flag that
indicates whether the structure is
On Mon, Mar 17, 2014 at 1:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
After mulling over a few possible approaches, I came up with the
attached, which seems short and to the point.
Looks reasonable in principle. I didn't run through all the existing
On 14/03/14 13:12, Simon Riggs wrote:
On 14 March 2014 11:10, Pavel Stehule pavel.steh...@gmail.com wrote:
2014-03-14 12:02 GMT+01:00 Marko Tiikkaja ma...@joh.to:
On 3/14/14 10:56 AM, Simon Riggs wrote:
The patch looks fine, apart from some non-guideline code formatting
issues.
I'm not
On 18.03.14 02:32, Joe Conway wrote:
On 03/17/2014 05:55 PM, Jeff Janes wrote:
On Mon, Mar 17, 2014 at 5:48 PM, Craig Ringer
cr...@2ndquadrant.com I wonder if doing large batches of
LOCK TABLE table1, table2, table3, ...
would help, instead of doing individual statements?
If I recall
On Mon, Mar 17, 2014 at 10:44 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Fujii Masao escribió:
On Sun, Mar 16, 2014 at 7:15 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
That could be optimized, but I figured we can live with it, thanks to the
fastupdate feature. Fastupdate
On 18 March 2014 11:59, Robert Haas rh...@postgresql.org wrote:
Make it easy to detach completely from shared memory.
The new function dsm_detach_all() can be used either by postmaster
children that don't wish to take any risk of accidentally corrupting
shared memory; or by forked children of
2014-03-18 13:23 GMT+01:00 Petr Jelinek p...@2ndquadrant.com:
On 14/03/14 13:12, Simon Riggs wrote:
On 14 March 2014 11:10, Pavel Stehule pavel.steh...@gmail.com wrote:
2014-03-14 12:02 GMT+01:00 Marko Tiikkaja ma...@joh.to:
On 3/14/14 10:56 AM, Simon Riggs wrote:
The patch looks
On 18 March 2014 12:23, Petr Jelinek p...@2ndquadrant.com wrote:
Agree that compile_errors dos not make sense, additional_errors and
additional_warnings seems better, maybe plpgsql.extra_warnings and
plpgsql.extra_errors?
That sems better to me also.
--
Simon Riggs
On Tue, Mar 18, 2014 at 8:41 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 18 March 2014 11:59, Robert Haas rh...@postgresql.org wrote:
Make it easy to detach completely from shared memory.
The new function dsm_detach_all() can be used either by postmaster
children that don't wish to take
On Mon, Mar 17, 2014 at 10:27 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Tue, Mar 18, 2014 at 10:24 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Thu, Mar 13, 2014 at 10:22 AM, Robert Haas robertmh...@gmail.com wrote:
Well, it's fairly harmless, but it might not
Hello!
Here is the text of my proposal which I've applied to GSoC.
(and link
http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/lubennikovaav/5629499534213120)
Any suggestions and comments are welcome.
*Project name*
Support for index-only scans for GIST index
*Brief review*
On Tue, Mar 18, 2014 at 11:25:46AM +0530, Amit Kapila wrote:
On Thu, Mar 13, 2014 at 11:18 AM, Bruce Momjian br...@momjian.us wrote:
I have developed the attached patch which fixes all cases where
readdir() wasn't checking for errno, and cleaned up the syntax in other
cases to be
Hi,
Is there the explicit reason why --slot option that pg_receivexlog
already has has not been added into pg_basebackup? If not,
I'd like to support that option to eliminate the need to increase
wal_keep_segments for pg_basebackup. Thought?
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers
Hi,
On 2014-03-18 22:25:05 +0900, Fujii Masao wrote:
Is there the explicit reason why --slot option that pg_receivexlog
already has has not been added into pg_basebackup? If not,
I'd like to support that option to eliminate the need to increase
wal_keep_segments for pg_basebackup. Thought?
I
On 03/18/2014 03:25 PM, Fujii Masao wrote:
Hi,
Is there the explicit reason why --slot option that pg_receivexlog
already has has not been added into pg_basebackup? If not,
I'd like to support that option to eliminate the need to increase
wal_keep_segments for pg_basebackup. Thought?
That
On Tue, Mar 18, 2014 at 2:32 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 03/18/2014 03:25 PM, Fujii Masao wrote:
Hi,
Is there the explicit reason why --slot option that pg_receivexlog
already has has not been added into pg_basebackup? If not,
I'd like to support that option
Bruce Momjian br...@momjian.us writes:
Very good point. I have modified the patch to add this block in all
cases where it was missing. I started to wonder about the comment and
if the Mingw fix was released. Based on some research, I see this as
fixed in mingw-runtime-3.2, released
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 18, 2014 at 8:41 AM, Simon Riggs si...@2ndquadrant.com wrote:
Perhaps we should consider a parameter for PGSharedMemoryDetach() ?
Yeah, maybe. It seems like a possible modularity violation, because
the PGSharedMemory... stuff has
On Tue, Mar 18, 2014 at 9:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Very good point. I have modified the patch to add this block in all
cases where it was missing. I started to wonder about the comment and
if the Mingw fix was released. Based on some
On Tue, Mar 18, 2014 at 10:03:46AM -0400, Robert Haas wrote:
On Tue, Mar 18, 2014 at 9:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Very good point. I have modified the patch to add this block in all
cases where it was missing. I started to wonder about
On 18 March 2014 13:51, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 18, 2014 at 8:41 AM, Simon Riggs si...@2ndquadrant.com wrote:
Perhaps we should consider a parameter for PGSharedMemoryDetach() ?
Yeah, maybe. It seems like a possible modularity
On Tue, Mar 18, 2014 at 9:46 AM, Magnus Hagander mag...@hagander.net wrote:
I started working on that at some point long ago, but never got far enough.
Right now, it seems the right way to do that is to somehow reimplement it on
top of a lightweight slot that gets automatically destroyed when
Bruce Momjian escribió:
On Tue, Mar 18, 2014 at 10:03:46AM -0400, Robert Haas wrote:
On Tue, Mar 18, 2014 at 9:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Very good point. I have modified the patch to add this block in all
cases where it was
On Mon, Mar 17, 2014 at 11:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
OK, I tried this out. The major complication that cropped up was
that, if we make the length word always a Size but align the buffer to
MAXIMUM_ALIGNOF, then the length word might
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 17, 2014 at 11:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Would it get noticeably simpler or faster if you omitted support for
the sizeof(Size) MAXIMUM_ALIGNOF case? It looks like perhaps not,
but if we were paying anything much I'd be
On Tue, Mar 18, 2014 at 9:12 AM, Anastasia Lubennikova
lubennikov...@gmail.com wrote:
Support for index-only scans for GIST index
This is a cool idea, if it can be made to work.
If the fetch() is specified by the developer, then using it, algorithm can
retrieve the data directly to output
Robert Haas robertmh...@gmail.com writes:
Tom Lane previously proposed extending SP-GiST to support index-only
scans. You might find that discussing worth reading, or perhaps
consider it as an alternative if GiST doesn't work out:
On 03/17/2014 10:31 PM, Peter Eisentraut wrote:
On Sun, 2014-03-16 at 22:34 -0400, Tom Lane wrote:
As for 2.4 vs 2.5, I don't have a lot of faith that we're really
supporting anything that's not represented in the buildfarm...
There are many other features that the build farm doesn't test and
On Tue, Mar 18, 2014 at 10:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The thing I kind of like about this approach is that it makes the code
fully independent of the relationship between MAXIMUM_ALIGNOF and
sizeof(Size).
Yeah. If it's not costing us much to support both cases, let's do so.
On 18 March 2014 14:15, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Bruce Momjian escribió:
On Tue, Mar 18, 2014 at 10:03:46AM -0400, Robert Haas wrote:
On Tue, Mar 18, 2014 at 9:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Very good point. I have
On 3/17/14, 10:55 PM, Tom Lane wrote:
It doesn't pass the regression tests. Do you need more of a bug report
than that?
It does pass the tests for me and others. If you are seeing something
different, then we need to see some details, like what platform, what
version, what Python version, how
On Tue, Mar 18, 2014 at 11:36 AM, Simon Riggs si...@2ndquadrant.com wrote:
Given the above, this means we've run for about 7 years without a
reported issue on this. If we are going to make this better by
actually having it throw errors in places that didn't throw errors
before, are we sure
On Tue, Mar 18, 2014 at 3:42 AM, Amit Kapila amit.kapil...@gmail.com wrote:
The message for exclusive lock on tuple print the database information.
It is true that it is possible to have a deadlock or lock chains that
involves locks on other databases.
In this example the table test is not in
On 3/17/14, 10:47 PM, Joshua D. Drake wrote:
We shouldn't be supporting anything the community doesn't support.
Python 2.3 is dead. We shouldn't actively support it nor suggest that we
could or should via the docs.
The information that is available to me about this issue is lacking
details,
On 18 March 2014 15:50, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 18, 2014 at 11:36 AM, Simon Riggs si...@2ndquadrant.com wrote:
Given the above, this means we've run for about 7 years without a
reported issue on this. If we are going to make this better by
actually having it throw
On 3/18/14, 11:22 AM, Andrew Dunstan wrote:
Actually, if you run a buildfarm animal you have considerable control
over what it tests.
I appreciate that. My problem here isn't time or ideas or coding, but
lack of hardware resources. If I had hardware, I could set up tests for
every build
All right.
On Fri, Mar 14, 2014 at 4:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Whilst setting up a buildfarm member on an old, now-spare Mac, I was
somewhat astonished to discover that contrib/test_shm_mq crashes thus:
TRAP: FailedAssertion(!(rb = sizeof(uint64)), File: shm_mq.c, Line: 429)
On Tue, Mar 18, 2014 at 11:59 AM, Greg Stark st...@mit.edu wrote:
On Tue, Mar 18, 2014 at 3:42 AM, Amit Kapila amit.kapil...@gmail.com wrote:
The message for exclusive lock on tuple print the database information.
It is true that it is possible to have a deadlock or lock chains that
involves
Robert Haas robertmh...@gmail.com writes:
First, can you retest this with the latest code?
Yeah, on it now.
If we want to inject some randomness into the test, which parameters
do we want to randomize and over what ranges?
I think the message length is the only particularly interesting
On Tue, Mar 18, 2014 at 12:00 AM, Amit Kapila amit.kapil...@gmail.com wrote:
Therefore I think the only case worth considering here is when
database/relation/TID are all defined. The other cases where there is
partial information are dead code; and the case where there is nothing
defined
On 13 March 2014 05:48, Bruce Momjian br...@momjian.us wrote:
On Mon, Dec 9, 2013 at 11:27:28AM -0500, Robert Haas wrote:
On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But the other usages seem to be in assorted utilities, which
will need to do it right for themselves.
Peter Eisentraut-2 wrote
On 3/18/14, 11:22 AM, Andrew Dunstan wrote:
Actually, if you run a buildfarm animal you have considerable control
over what it tests.
I appreciate that. My problem here isn't time or ideas or coding, but
lack of hardware resources. If I had hardware, I could set
I wrote:
Robert Haas robertmh...@gmail.com writes:
First, can you retest this with the latest code?
Yeah, on it now.
Early returns not good:
***
/Users/buildfarm/bf-data/HEAD/pgsql.93630/contrib/test_shm_mq/expected/test_shm_mq.out
Tue Mar 18 12:00:18 2014
---
Robert Haas escribió:
On Tue, Mar 18, 2014 at 12:00 AM, Amit Kapila amit.kapil...@gmail.com wrote:
Therefore I think the only case worth considering here is when
database/relation/TID are all defined. The other cases where there is
partial information are dead code; and the case where
Robert Haas robertmh...@gmail.com writes:
Well, if we're back to one version of the message, and I'm glad we
are, can we go back to saying:
CONTEXT: while updating tuple (0,2) in relation public.foo of
database postgres
If I end up being the one who commits this, it's going to say
while
Tom Lane escribió:
Robert Haas robertmh...@gmail.com writes:
Well, if we're back to one version of the message, and I'm glad we
are, can we go back to saying:
CONTEXT: while updating tuple (0,2) in relation public.foo of
database postgres
If I end up being the one who commits this,
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Please see my reply to Robert. My proposal (in form of a patch) is
while operating on tuple (0,2) in table foo: updating tuple
Would this work for you?
It's pretty lousy from a readability standpoint, even in English;
I shudder to think what
On Mon, Mar 17, 2014 at 8:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Claudio Freire klaussfre...@gmail.com writes:
On Mon, Mar 17, 2014 at 7:01 PM, Jim Nasby j...@nasby.net wrote:
Even better would be if the planner could estimate how bad a plan will
become if we made assumptions that turn
Fwiw I'm finding myself repeatedly caught up by the operator
precedence rules when experimenting with jsonb:
stark=***# select segment-'id' as id from flight_segments where
segment-'marketing_airline_code'
segment-'operating_airline_code' ;
ERROR: 42883: operator does not exist: text jsonb
Alexander,
Can you comment on the below proposal? I'd like your opinion on how
difficult it will be.
On 03/18/2014 06:12 AM, Anastasia Lubennikova wrote:
Hello!
Here is the text of my proposal which I've applied to GSoC.
(and link
I wrote:
Early returns not good:
Also, these compiler messages are probably relevant:
ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g
On Tue, Mar 18, 2014 at 1:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Early returns not good:
Also, these compiler messages are probably relevant:
ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
On 2014-03-18 13:31:47 -0400, Robert Haas wrote:
Well, I definitely forgot that. I'll count myself lucky if that's the
only problem.
One minor thing missing, patch attached.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development,
On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote:
While I am not a fan of backpatching, the fact we are ignoring errors in
some critical cases seems the non-cosmetic parts should be backpatched.
pg_resetxlog was not an offender here; its coding was sound.
We shouldn't be
On 18 March 2014 18:01, Bruce Momjian br...@momjian.us wrote:
On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote:
While I am not a fan of backpatching, the fact we are ignoring errors in
some critical cases seems the non-cosmetic parts should be backpatched.
pg_resetxlog was not an
On Mon, Mar 17, 2014 at 8:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. I would like to see the planner's cost estimates extended to
include some sort of uncertainty estimate, whereupon risk-averse people
could ask it to prefer low-uncertainty plans over high-uncertainty ones
(the plans
On Tue, Mar 18, 2014 at 06:11:30PM +, Simon Riggs wrote:
On 18 March 2014 18:01, Bruce Momjian br...@momjian.us wrote:
On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote:
While I am not a fan of backpatching, the fact we are ignoring errors in
some critical cases seems the
and...@anarazel.de (Andres Freund) writes:
On 2014-03-18 13:31:47 -0400, Robert Haas wrote:
Well, I definitely forgot that. I'll count myself lucky if that's the
only problem.
One minor thing missing, patch attached.
setup_dynamic_shared_memory needed some more hacking too. Committed.
On Tue, Mar 18, 2014 at 11:43 PM, Josh Berkus j...@agliodbs.com wrote:
On Mon, Mar 17, 2014 at 8:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. I would like to see the planner's cost estimates extended to
include some sort of uncertainty estimate, whereupon risk-averse people
could ask
Atri Sharma atri.j...@gmail.com writes:
One of the factors that leads to bad estimates is that the histogram of the
values of a column maintained by the planner gets old by time and the data
in the column changes. So, the histogram is no longer a quite accurate view
of the data and it leads to
On 03/17/2014 05:49 PM, Josh Berkus wrote:
All,
https://wiki.postgresql.org/wiki/20140320UpdateIssues
I'm sure my explanation of the data corruption issue is not correct, so
please fix it. Thanks!
Anyone? We're going public with this in 36 hours, so I'd love for it to
actually be
Bruce Momjian escribió:
On Tue, Mar 18, 2014 at 06:11:30PM +, Simon Riggs wrote:
On 18 March 2014 18:01, Bruce Momjian br...@momjian.us wrote:
On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote:
While I am not a fan of backpatching, the fact we are ignoring errors
in
On 18 March 2014 18:18, Bruce Momjian br...@momjian.us wrote:
On Tue, Mar 18, 2014 at 06:11:30PM +, Simon Riggs wrote:
On 18 March 2014 18:01, Bruce Momjian br...@momjian.us wrote:
On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote:
While I am not a fan of backpatching, the
Simon Riggs escribió:
On 18 March 2014 18:18, Bruce Momjian br...@momjian.us wrote:
On Tue, Mar 18, 2014 at 06:11:30PM +, Simon Riggs wrote:
Why make style changes at all? A patch with no style changes would
mean backpatch and HEAD versions would be the same.
The old style had
On 18/03/14 13:43, Pavel Stehule wrote:
2014-03-18 13:23 GMT+01:00 Petr Jelinek p...@2ndquadrant.com
mailto:p...@2ndquadrant.com
Agree that compile_errors dos not make sense, additional_errors
and additional_warnings seems better, maybe plpgsql.extra_warnings
and
After the last round of changes, I can confirm that my original test with
UTF8 locale works, and my HPPA box is happy too. We could still stand
to improve the regression test though.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On 02/06/2014 06:42 AM, Peter Geoghegan wrote:
I'm not sure about this:
*** _bt_findinsertloc(Relation rel,
*** 675,680
--- 701,707
static void
_bt_insertonpg(Relation rel,
Buffer buf,
+ Buffer cbuf,
On 18 March 2014 18:55, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
That said, I don't find comma expression to be particularly not
simple.
Maybe, but we've not used it before anywhere in Postgres, so I don't
see a reason to start now. Especially since C is not the native
language of many
2014-03-18 19:56 GMT+01:00 Petr Jelinek p...@2ndquadrant.com:
On 18/03/14 13:43, Pavel Stehule wrote:
2014-03-18 13:23 GMT+01:00 Petr Jelinek p...@2ndquadrant.com
Agree that compile_errors dos not make sense, additional_errors and
additional_warnings seems better, maybe
On Tue, Mar 18, 2014 at 6:41 PM, Josh Berkus j...@agliodbs.com wrote:
Anyone? We're going public with this in 36 hours, so I'd love for it to
actually be correct.
I'll do a first pass now.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Tue, Mar 18, 2014 at 5:12 PM, Anastasia Lubennikova
lubennikov...@gmail.com wrote:
2. gistget algorithm (several parts omitted):
Check the key
gistindex_keytest() - does this index tuple satisfy the scan key(s)?
Scan all items on the GiST index page and insert them into the queue (or
On Tue, Mar 18, 2014 at 12:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It's tempting to instead add one or more tests that we specifically
choose to have values we think are likely to exercise
platform-specific differences or otherwise find bugs - e.g. just add a
second test where the queue
Josh,
Anastasia has already consulted to me in person. It is not big proposal.
But for newbie who is not familiar with PostgreSQL code base and especially
GiST it seems fair enough.
With best regards,
Alexander Korotkov.
On Tue, Mar 18, 2014 at 9:16 PM, Josh Berkus j...@agliodbs.com wrote:
On 03/18/2014 12:11 PM, Alexander Korotkov wrote:
Josh,
Anastasia has already consulted to me in person. It is not big proposal.
But for newbie who is not familiar with PostgreSQL code base and especially
GiST it seems fair enough.
Thanks, that's what I wanted to know.
--
Josh Berkus
On Tue, Mar 18, 2014 at 4:12 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
See attached patch. The new contract of _bt_getroot is a bit weird: it locks
the returned page in the requested lock-mode, shared or exclusive, if the
root page was also the leaf page. Otherwise it's locked in
On 03/18/2014 09:04 PM, Simon Riggs wrote:
On 18 March 2014 18:55, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
That said, I don't find comma expression to be particularly not
simple.
Maybe, but we've not used it before anywhere in Postgres, so I don't
see a reason to start now. Especially
On 18 March 2014 19:04, Pavel Stehule pavel.steh...@gmail.com wrote:
I don't think so only shadow is good name for some check. Maybe
shadow-variables-check
shadowed-variables would be a better name.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
2014-03-18 20:14 GMT+01:00 Simon Riggs si...@2ndquadrant.com:
On 18 March 2014 19:04, Pavel Stehule pavel.steh...@gmail.com wrote:
I don't think so only shadow is good name for some check. Maybe
shadow-variables-check
shadowed-variables would be a better name.
+1
--
Simon Riggs
On 18/03/14 20:15, Pavel Stehule wrote:
2014-03-18 20:14 GMT+01:00 Simon Riggs si...@2ndquadrant.com
mailto:si...@2ndquadrant.com:
On 18 March 2014 19:04, Pavel Stehule pavel.steh...@gmail.com
mailto:pavel.steh...@gmail.com wrote:
I don't think so only shadow is good name for
On Tue, Mar 18, 2014 at 7:05 PM, Greg Stark st...@mit.edu wrote:
I'll do a first pass now.
I fixed the Causes section. I haven't touched the other sections
which are pretty reasonable. It would be nice to have more suggestions
for what people should do other than dump/restore.
It would be nice
On 2014-03-18 19:28:53 +, Greg Stark wrote:
It would be nice to be able to tell people that if they vacuum, then
reindex and check all their foreign key constraints then they should
be ok.
I don't think so:
Hello
Tomorrow I'll do a review
fast check
para
+To aid the user in finding instances of simple but common problems
before
+they cause harm, applicationPL/PgSQL/ provides a number of
additional
+replaceablechecks/. When enabled, depending on the configuration,
they
+can be
On 3/18/14, 7:56 PM, Petr Jelinek wrote:
Ok, so I took the liberty of rewriting the patch so that it uses
plpgsql.extra_warnings and plpgsql.extra_errors configuration variables
with possible values none, all and shadow (none being the default).
Updated doc and regression tests to reflect the
On Tue, Mar 18, 2014 at 12:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Please see my reply to Robert. My proposal (in form of a patch) is
while operating on tuple (0,2) in table foo: updating tuple
Would this work for you?
It's pretty lousy
On 18/03/14 20:36, Pavel Stehule wrote:
para
+To aid the user in finding instances of simple but common
problems before
+they cause harm, applicationPL/PgSQL/ provides a number of
additional
+replaceablechecks/. When enabled, depending on the
configuration, they
+can be
2014-03-18 20:44 GMT+01:00 Petr Jelinek p...@2ndquadrant.com:
On 18/03/14 20:36, Pavel Stehule wrote:
para
+To aid the user in finding instances of simple but common problems
before
+they cause harm, applicationPL/PgSQL/ provides a number of
additional
+
1 - 100 of 138 matches
Mail list logo
