It's better to post a review as a reply to the message which contains
the patch.
Sorry about that, I did not have the email in my inbox and couldn't figure
out how to use the old message ID to send a reply. Here is the thread:
Hello
after patching I god segfault
Program terminated with signal 11, Segmentation fault.
#0 0x0805aab4 in get_prompt (status=PROMPT_READY) at prompt.c:98
98 for (p = prompt_string;
Missing separate debuginfos, use: debuginfo-install glibc-2.13-2.i686
I just applied the patch to a clean branch from the latest master. I
couldn't get a segfault from using the new feature. Could you provide a
little more info to reproduce the segfault? Thanks
On Thu, Jun 27, 2013 at 11:28 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello
after patching I
Hello
It's look like my bug - wrong compilation
I am sorry
Pavel
2013/6/28 ian link i...@ilink.io:
I just applied the patch to a clean branch from the latest master. I
couldn't get a segfault from using the new feature. Could you provide a
little more info to reproduce the segfault? Thanks
No worries! :)
On Fri, Jun 28, 2013 at 12:20 AM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello
It's look like my bug - wrong compilation
I am sorry
Pavel
2013/6/28 ian link i...@ilink.io:
I just applied the patch to a clean branch from the latest master. I
couldn't get a
On 2013-06-27 18:18:50 -0400, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I'm looking at the combined patches 0003-0005, which are essentially all
about adding a function to obtain relation OID from (tablespace,
filenode). It takes care to look through the relation
Hi Pavel,
On Fri, Jun 28, 2013 at 2:53 AM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello
2013/6/27 Jeevan Chalke jeevan.cha...@enterprisedb.com:
Hi Pavel,
I had a look over your new patch and it looks good to me.
My review comments on patch:
1. It cleanly applies with patch
On 2013-06-28 16:30:16 +0900, Michael Paquier wrote:
When I ran VACUUM FULL, I got the following error.
ERROR: attempt to apply a mapping to unmapped relation 16404
STATEMENT: vacuum full;
This can be reproduced when doing a vacuum full on pg_proc,
pg_shdescription or
On Fri, Jun 28, 2013 at 4:52 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-06-28 16:30:16 +0900, Michael Paquier wrote:
When I ran VACUUM FULL, I got the following error.
ERROR: attempt to apply a mapping to unmapped relation 16404
STATEMENT: vacuum full;
This can be
Thanks for checking the patch!
So what's left to fix?
* Moving the escaping-related functions to separate module,
* applying your corrections.
Did I missed anything?
I'll submit corrected patch after the weekend.
M
On 27 June 2013 15:05, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Gierth and...@tao11.riddles.org.uk writes:
Tom Lane said:
Agreed, separating out the function-call-with-trailing-declaration
syntaxes so they aren't considered in FROM and index_elem seems like
the best compromise.
If we do
On Fri, Jun 28, 2013 at 5:54 AM, Kevin Grittner kgri...@ymail.com wrote:
Robert Haas robertmh...@gmail.com wrote:
Magnus Hagander mag...@hagander.net wrote:
The functionality of materialized views will (over time) totally swamp
that of normal views, so mixing all the corresponding
On 27.06.2013 17:30, Robert Haas wrote:
On Wed, Jun 26, 2013 at 5:49 PM, Jeff Janesjeff.ja...@gmail.com wrote:
If we think the patch has a risk of introducing subtle errors, then it
probably can't be justified based on the small performance gains you saw.
But if we think it has little risk,
There is a spot on the disk to which the current WAL is destined to go.
That spot on the disk is not going to be under the write-head for (say)
another 6 milliseconds.
Without commit_delay, I try to commit my record, but find that someone else
is already on the lock (and on the fsync as
Yep. To take a degenerate case, suppose that you had many small WAL
records, say 64 bytes each, so more than 100 per 8K block. If you
flush those one by one, you're going to rewrite that block 100 times.
If you flush them all at once, you write that block once.
But even when the range is
On Fri, Jun 28, 2013 at 3:32 AM, Andres Freund and...@2ndquadrant.com wrote:
What that means is that for every heap record in the target database in
the WAL we need to query pg_class to turn the relfilenode into a
pg_class.oid. So, we can easily replace syscache.c with some custom
caching
On 2013-06-28 08:41:46 -0400, Robert Haas wrote:
On Fri, Jun 28, 2013 at 3:32 AM, Andres Freund and...@2ndquadrant.com wrote:
What that means is that for every heap record in the target database in
the WAL we need to query pg_class to turn the relfilenode into a
pg_class.oid. So, we can
(2013/06/28 0:08), Robert Haas wrote:
On Tue, Jun 25, 2013 at 4:28 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I'm pretty sure Greg Smith tried it the fixed-sleep thing before and
it didn't work that well. I have also tried it and the resulting
behavior was unimpressive. It makes
On 2013-06-27 21:52:03 -0700, Kevin Grittner wrote:
Tried that, too, and problem persists. The log shows the last
commit on your branch as 022c2da1873de2fbc93ae524819932719ca41bdb.
I get the same failure, with primary key or unique index column
showing as 0 in results.
I have run enough
On Fri, Jun 28, 2013 at 12:52 AM, Amit Kapila amit.kap...@huawei.com wrote:
Currently it wakes up based on bgwriterdelay config parameter which is by
default 200ms, so you means we should
think of waking up bgwriter based on allocations and number of elements left
in freelist?
I think that's
On Fri, Jun 28, 2013 at 8:50 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jun 28, 2013 at 12:52 AM, Amit Kapila amit.kap...@huawei.com wrote:
Currently it wakes up based on bgwriterdelay config parameter which is by
default 200ms, so you means we should
think of waking up bgwriter
On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote:
2013/6/28 Noah Misch n...@leadboat.com:
On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote:
cleaned patch is in attachment
Of the five options you're adding to GET STACKED DIAGNOSTICS, four of them
appear in the
On Thu, Jun 27, 2013 at 12:56 PM, Andres Freund and...@2ndquadrant.com wrote:
Please find attached the next version of the extensible toast
support. There basically are two changes:
* handle indirect toast tuples properly in heap_tuple_fetch_attr
and related places
* minor comment
Hello
2013/6/28 Noah Misch n...@leadboat.com:
On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote:
2013/6/28 Noah Misch n...@leadboat.com:
On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote:
cleaned patch is in attachment
Of the five options you're adding to GET
On Fri, Jun 28, 2013 at 9:23 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jun 27, 2013 at 12:56 PM, Andres Freund and...@2ndquadrant.com
wrote:
Please find attached the next version of the extensible toast
support. There basically are two changes:
* handle indirect toast tuples
On Tue, Jun 25, 2013 at 02:54:55PM +0530, Jeevan Chalke wrote:
On Tue, Jun 25, 2013 at 11:11 AM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
Hi David,
I hope this is the latest patch to review, right ?
I am going to review it.
I have gone through the discussion on this
On 6/28/13 8:46 AM, Andres Freund wrote:
I personally favor making catalog modifications a bit more more
expensive instead of increasing the WAL volume during routine
operations. I don't think index maintenance itself comes close to the
biggest cost for DDL we have atm.
That makes sense to me
David Fetter da...@fetter.org writes:
Please find attached the latest patch.
I remain of the opinion that this is simply a bad idea. It is unlike
our habits for constructing other types of nodes, and makes it harder
not easier to find all the places that need to be updated when adding
another
On Fri, Jun 28, 2013 at 10:31:16AM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
Please find attached the latest patch.
I remain of the opinion that this is simply a bad idea. It is unlike
our habits for constructing other types of nodes, and makes it harder
not easier to
Andres Freund and...@2ndquadrant.com writes:
On 2013-06-28 08:41:46 -0400, Robert Haas wrote:
The alternative I previously proposed was to make the WAL records
carry the relation OID. There are a few problems with that: one is
that it's a waste of space when logical replication is turned off,
Magnus Hagander escribió:
They are already crosslinked under see also. But that doesn't really
help the guy doing \h CREATE VIEW in psql, which was the case where
it was brought to my attention.
Maybe \h should somehow display the see also section?
--
Álvaro Herrera
On Fri, Jun 28, 2013 at 4:49 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Magnus Hagander escribió:
They are already crosslinked under see also. But that doesn't really
help the guy doing \h CREATE VIEW in psql, which was the case where
it was brought to my attention.
Maybe \h should
On 2013-06-28 09:49:53 -0400, Robert Haas wrote:
On Fri, Jun 28, 2013 at 9:23 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jun 27, 2013 at 12:56 PM, Andres Freund and...@2ndquadrant.com
wrote:
Please find attached the next version of the extensible toast
support. There basically
On Fri, Jun 28, 2013 at 10:31:16AM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
Please find attached the latest patch.
I remain of the opinion that this is simply a bad idea. It is unlike
our habits for constructing other types of nodes, and makes it harder
not easier to
On 2013-06-28 10:49:26 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-06-28 08:41:46 -0400, Robert Haas wrote:
The alternative I previously proposed was to make the WAL records
carry the relation OID. There are a few problems with that: one is
that it's a
On Fri, Jun 28, 2013 at 03:31:00PM +0200, Pavel Stehule wrote:
Hello
2013/6/28 Noah Misch n...@leadboat.com:
On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote:
2013/6/28 Noah Misch n...@leadboat.com:
On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote:
cleaned
On Fri, Jun 28, 2013 at 10:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert's idea sounds fairly reasonable to me; another 4 bytes per
insert/update/delete WAL entry isn't that big a deal, ...
How big a deal is it? This is a serious question, because I don't
know. Let's suppose that the
2013/6/28 Noah Misch n...@leadboat.com:
On Fri, Jun 28, 2013 at 03:31:00PM +0200, Pavel Stehule wrote:
Hello
2013/6/28 Noah Misch n...@leadboat.com:
On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote:
2013/6/28 Noah Misch n...@leadboat.com:
On Tue, Jun 25, 2013 at 03:56:27PM
On Fri, Jun 28, 2013 at 10:53 AM, Andres Freund and...@2ndquadrant.com wrote:
Why does toast_insert_or_update() need to go through all the
rigamarole in toast_datum_differs()? I would have thought that it
could simply treat any external-indirect value as needing to be
detoasted and retoasted,
On Thu, Jun 27, 2013 at 8:52 PM, Nicholas White n.j.wh...@gmail.com wrote:
The result of the current patch using lead
Actually, I think I agree with you (and, FWIW, so does Oracle:
http://docs.oracle.com/cd/E11882_01/server.112/e25554/analysis.htm#autoId18).
I've refactored the window
On Fri, Jun 28, 2013 at 10:31 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Fetter da...@fetter.org writes:
Please find attached the latest patch.
I remain of the opinion that this is simply a bad idea. It is unlike
our habits for constructing other types of nodes, and makes it harder
not
Robert Haas escribió:
On Fri, Jun 28, 2013 at 10:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert's idea sounds fairly reasonable to me; another 4 bytes per
insert/update/delete WAL entry isn't that big a deal, ...
How big a deal is it? This is a serious question, because I don't
know.
Robert Haas escribió:
On Thu, Jun 27, 2013 at 8:52 PM, Nicholas White n.j.wh...@gmail.com wrote:
The documentation you've added reads kind of funny to me:
+ [respect nulls]|[ignore nulls]
Wouldn't we normally write that as [ [ RESPECT | IGNORE ] NULLS ] ?
I think it should be
[ {
Hello
I am not sure, this interface is really user friendly
there is not possible searching in history, and not every query push
to history some interesting content.
It require:
* simply decision if content should be stored in history or not,
* simply remove last entry (table) of history
*
Alvaro Herrera escribió:
An INSERT wal record is:
typedef struct xl_heap_insert
{
xl_heaptid target; /* inserted tuple id */
boolall_visible_cleared;/* PD_ALL_VISIBLE was cleared */
/* xl_heap_header TUPLE DATA FOLLOWS AT END OF
On Fri, Jun 28, 2013 at 11:41 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Robert Haas escribió:
On Thu, Jun 27, 2013 at 8:52 PM, Nicholas White n.j.wh...@gmail.com wrote:
The documentation you've added reads kind of funny to me:
+ [respect nulls]|[ignore nulls]
Wouldn't we
Robert Haas robertmh...@gmail.com writes:
I'm just talking out of my rear end here because I don't know what the
real numbers are, but it's far from obvious to me that there's any
free lunch here. That having been said, just because indexing
relfilenode or adding relfilenodes to WAL records
On 06/27/2013 12:22 PM, Magnus Hagander wrote:
On Tue, Jun 25, 2013 at 3:31 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On 2013/06/25, at 22:23, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jun 25, 2013 at 6:33 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Tue, Jun
On Fri, Jun 28, 2013 at 05:21:29PM +0200, Pavel Stehule wrote:
2013/6/28 Noah Misch n...@leadboat.com:
Okay. I failed to note the first time through that while the patch uses the
same option names for RAISE and GET STACKED DIAGNOSTICS, the existing option
lists for those commands differ:
On 24 June 2013 22:17, Simon Riggs si...@2ndquadrant.com wrote:
On 24 June 2013 21:42, Jeff Janes jeff.ja...@gmail.com wrote:
On Sun, Jun 23, 2013 at 8:58 PM, Abhijit Menon-Sen
a...@2ndquadrant.comwrote:
At 2013-06-08 21:45:24 +0100, si...@2ndquadrant.com wrote:
ALTER TABLE foo
On 6/28/13 8:50 AM, Robert Haas wrote:
On Fri, Jun 28, 2013 at 12:52 AM, Amit Kapila amit.kap...@huawei.com wrote:
4. Separate processes for writing dirty buffers and moving buffers to
freelist
I think this part might be best pushed to a separate patch, although I
agree we probably need it.
On Fri, Jun 28, 2013 at 11:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I'm just talking out of my rear end here because I don't know what the
real numbers are, but it's far from obvious to me that there's any
free lunch here. That having been said, just
On Fri, Jun 28, 2013 at 12:10 PM, Greg Smith g...@2ndquadrant.com wrote:
This refactoring idea will make that hard to keep around. I think this is
OK though. Switching to a latch based design should eliminate the
bgwriter_delay, which means you won't have this worst case of a 200ms stall
Robert Haas robertmh...@gmail.com writes:
On the other hand, I can't entirely shake the feeling that adding the
information into WAL would be more reliable.
That feeling has been nagging at me too. I can't demonstrate that
there's a problem when an ALTER TABLE is in process of rewriting a
This patch will need to be rebased over those changes
See attached -
lead-lag-ignore-nulls.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
Simon Riggs escribió:
Looks like that really is a deficiency in my tool chain on OSX, rather than
some bug/user error. Even at the very latest, very shiny version.
Latest versions of gcc trap the error, so I'll have to investigate an
alternative.
Funnily enough, on Debian Wheezy with gcc
Magnus Hagander escribió:
However, if oyu're looking for a snapshot, please use the one on the
ftpsite. Generating those snapshots on the git server is slow and
expensive...
Maybe we should redirect those gitweb snapshot URLs to the FTP site?
--
Álvaro Herrera
On 28 June 2013 17:10, Robert Haas robertmh...@gmail.com wrote:
But to tell the truth, I'm mostly exercised about the non-unique
syscache. I think that's simply a *bad* idea.
+1.
I don't think the extra index on pg_class is going to hurt that much,
even if we create it always, as long
On 6/17/13 3:38 PM, Josh Berkus wrote:
Why? Why can't we just update the affected pages in the index?
The page range has to be scanned in order to find out the min/max values
for the indexed columns on the range; and then, with these data, update
the index.
Seems like you could incrementally
On Fri, Jun 28, 2013 at 2:18 PM, Jim Nasby j...@nasby.net wrote:
On 6/17/13 3:38 PM, Josh Berkus wrote:
Why? Why can't we just update the affected pages in the index?
The page range has to be scanned in order to find out the min/max values
for the indexed columns on the range; and then,
On Fri, Jun 28, 2013 at 12:29 PM, Nicholas White n.j.wh...@gmail.com wrote:
This patch will need to be rebased over those changes
See attached -
Thanks. But I see a few issues...
+ [respect nulls]|[ignore nulls]
You fixed one of these but missed the other.
replaceable
On 6/28/13 11:30 AM, Robert Haas wrote:
On Fri, Jun 28, 2013 at 10:31 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Fetter da...@fetter.org writes:
Please find attached the latest patch.
I remain of the opinion that this is simply a bad idea. It is unlike
our habits for constructing other
On 6/28/13 10:49 AM, Alvaro Herrera wrote:
Magnus Hagander escribió:
They are already crosslinked under see also. But that doesn't really
help the guy doing \h CREATE VIEW in psql, which was the case where
it was brought to my attention.
Maybe \h should somehow display the see also
On 6/28/13 12:26 PM, Claudio Freire wrote:
On Fri, Jun 28, 2013 at 2:18 PM, Jim Nasby j...@nasby.net wrote:
On 6/17/13 3:38 PM, Josh Berkus wrote:
Why? Why can't we just update the affected pages in the index?
The page range has to be scanned in order to find out the min/max values
for
Peter Eisentraut escribió:
On 6/28/13 10:49 AM, Alvaro Herrera wrote:
Magnus Hagander escribió:
They are already crosslinked under see also. But that doesn't really
help the guy doing \h CREATE VIEW in psql, which was the case where
it was brought to my attention.
Maybe \h should
On Fri, Jun 28, 2013 at 2:18 PM, Jim Nasby j...@nasby.net wrote:
If we add a dirty flag it would probably be wise to allow for more
than one
value so we can do a clock-sweep. That would allow for detecting a range
that is getting dirtied repeatedly and not bother to try and
re-summarize it
On Fri, Jun 28, 2013 at 01:34:17PM -0400, Peter Eisentraut wrote:
On 6/28/13 10:49 AM, Alvaro Herrera wrote:
Magnus Hagander escribió:
They are already crosslinked under see also. But that doesn't
really help the guy doing \h CREATE VIEW in psql, which was the
case where it was brought
On 06/20/2013 07:19 PM, Jeff Davis wrote:
On Sun, 2013-06-16 at 23:53 -0500, Jon Nelson wrote:
Please find attached v5 of the patch, with the above correction in place.
The only change from the v4 patch is wrapping the if
(wal_use_fallocate) block in an #ifdef USE_POSIX_FALLOCATE.
Thanks!
Folks,
We are starting the 3rd week of the commitfest tommorrow, and here's the
update on status. In the last week, we are at the following status levels:
- 40 patches still Need Review,
including 11 which have no reviewer assigned.
- 23 patches are Waiting on Author, most of them
On 2013-06-28 12:16:09 -0700, Josh Berkus wrote:
- Remove PD_ALL_VISIBLE**
I think this is primarily delayed because people don't agree it's a good
idea.
- Use posix_fallocate to build (new) WAL files**
I don't think this needs much further testing. We should just remove the
enable/disable
On Fri, Jun 28, 2013 at 4:16 PM, Josh Berkus j...@agliodbs.com wrote:
(2) ideas on how we can speed up/parallelize performance testing efforts
are extremely welcome.
An official perf-test script in GIT, even if it only tests general
pg-bench-like performance, that can take two builds and
On Tue, Jun 25, 2013 at 2:20 AM, Alexander Korotkov aekorot...@gmail.comwrote:
4. If we do go with a new function, I'd like to just call it consistent
(or consistent2 or something, to keep it separate form the old consistent
function), and pass it a tri-state input for each search term. It
On 05/13/2013 05:37 PM, Robins Tharakan wrote:
Hi,
Patch to add more regression tests to ASYNC (/src/backend/commands/async).
Take code-coverage from 39% to 75%.
This isn't applying for me anymore due to changes in the
parallel_schedule file. Where did you mean this to execute in the
On 2013-06-28 12:26:52 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On the other hand, I can't entirely shake the feeling that adding the
information into WAL would be more reliable.
That feeling has been nagging at me too. I can't demonstrate that
there's a problem
On 06/28/2013 12:42 PM, Josh Berkus wrote:
On 05/13/2013 05:37 PM, Robins Tharakan wrote:
Hi,
Patch to add more regression tests to ASYNC (/src/backend/commands/async).
Take code-coverage from 39% to 75%.
This isn't applying for me anymore due to changes in the
parallel_schedule file.
On 06/27/2013 05:04 AM, Szymon Guz wrote:
On 27 June 2013 05:21, Steve Singer st...@ssinger.info
mailto:st...@ssinger.info wrote:
On 06/26/2013 04:47 PM, Szymon Guz wrote:
Hi Steve,
thanks for the changes.
You're idea about common code for decimal and cdecimal is good,
however not
On 21 June 2013 06:16, David Fetter da...@fetter.org wrote:
Please find attached a patch which allows subqueries in the FILTER
clause and adds regression testing for same.
This needs re-basing/merging following Robert's recent commit to make
OVER unreserved.
Regards,
Dean
--
Sent via
On 28 June 2013 22:14, Steve Singer st...@ssinger.info wrote:
I think the value is more important than the name, I want to the tests to
make sure that the conversion is actually converting properly. With your
method of getting the class name without the module we can have both.
The
On Fri, Jun 28, 2013 at 5:14 PM, Steve Singer st...@ssinger.info wrote:
On 06/27/2013 05:04 AM, Szymon Guz wrote:
On 27 June 2013 05:21, Steve Singer st...@ssinger.info
mailto:st...@ssinger.info wrote:
On 06/26/2013 04:47 PM, Szymon Guz wrote:
Hi Steve,
thanks for the changes.
On 06/28/2013 06:51 PM, Alvaro Herrera wrote:
Magnus Hagander escribió:
However, if oyu're looking for a snapshot, please use the one on the
ftpsite. Generating those snapshots on the git server is slow and
expensive...
Maybe we should redirect those gitweb snapshot URLs to the FTP site?
On 05/07/2013 03:40 PM, Robins Tharakan wrote:
Hi,
Have provided an updated patch as per Fabien's recent response on
Commitfest site.
Any and all feedback is appreciated.
The updated patch is giving a FAILURE for me:
parallel group (19 tests): limit temp plancache conversion rowtypes
Hi Andres,
Just an aside, your point about CONNECTION LIMIT was something that just
didn't come to my mind and is probably a good way to test ALTER DATABASE
with CONNECTION LIMIT.
Its just that that actually wasn't what I was testing there. That
'CONNECTION LIMIT' test was coupled with CREATE
Hackers,
Per discussion on these tests, I ran make check against 9.4 head,
applied all of the regression tests other than DISCARD.
Time for 3 make check runs without new tests: 65.9s
Time for 3 make check runs with new tests: 71.7s
So that's an increase of about 10% in test runtime (or 2
I've fixed the problems you mentioned (see attached) - sorry, I was a bit
careless with the docs.
+ null_values = (Bitmapset *) WinGetPartitionLocalMemory(
+ winobj,
+ BITMAPSET_SIZE(words_needed));
+
Seems like thats because of a recent (15th May 2013) patch
(b14206862278347a379f2bb72d92d16fb9dcea45) that changed the error message
that is printed. Its just one line of difference actually.
Let me know if this is otherwise good to go.
I'll checkout the latest revision and submit this patch
On 06/28/2013 02:15 PM, Robins Tharakan wrote:
Seems like thats because of a recent (15th May 2013) patch
(b14206862278347a379f2bb72d92d16fb9dcea45) that changed the error message
that is printed. Its just one line of difference actually.
Let me know if this is otherwise good to go.
I'll
On 06/28/2013 02:15 PM, Robins Tharakan wrote:
Seems like thats because of a recent (15th May 2013) patch
(b14206862278347a379f2bb72d92d16fb9dcea45) that changed the error message
that is printed. Its just one line of difference actually.
Let me know if this is otherwise good to go.
I'll
On 2013-06-28 14:01:23 -0700, Josh Berkus wrote:
Per discussion on these tests, I ran make check against 9.4 head,
applied all of the regression tests other than DISCARD.
Time for 3 make check runs without new tests: 65.9s
Time for 3 make check runs with new tests: 71.7s
So that's an
How did you evaluate that coverage increased greatly? I am not
generally against these tests but I'd be surprised if the overall test
coverage improved noticeably by this. Which makes 10% runtime overhead
pretty hefty if the goal is to actually achieve a high coverage.
I was relying on
MauMau escribió:
Hi,
I did this. Please find attached the revised patch. I modified
HandleChildCrash(). I tested the immediate shutdown, and the child
cleanup succeeded.
Thanks, committed.
There are two matters pending here:
1. do we want postmaster to exit immediately after sending the
On Tue, May 28, 2013 at 09:08:03PM -0700, Joshua D. Drake wrote:
On 05/28/2013 07:55 PM, Bruce Momjian wrote:
Perhaps just documenting the behavior is all that is needed, but -U is
everywhere and I think that's a good thing.
[ moved to hacker ]
Wow, I never realized other tools used
On 2013-06-28 14:46:10 -0700, Josh Berkus wrote:
How did you evaluate that coverage increased greatly? I am not
generally against these tests but I'd be surprised if the overall test
coverage improved noticeably by this. Which makes 10% runtime overhead
pretty hefty if the goal is to
On Wed, May 29, 2013 at 09:44:00AM -0400, Peter Eisentraut wrote:
On 5/28/13 10:55 PM, Bruce Momjian wrote:
Wow, I never realized other tools used -U for user, instead of -u.
Should I change pg_upgrade to use -U for 9.4? I can keep supporting -u
as an undocumented option.
It seems to
On Fri, Jun 28, 2013 at 6:00 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
MauMau escribió:
Hi,
I did this. Please find attached the revised patch. I modified
HandleChildCrash(). I tested the immediate shutdown, and the child
cleanup succeeded.
Thanks, committed.
There are two
Hi,
I was looking at psql 8.3 documention about \pset options and saw that
there was the following note :
Note: It is an error to call \pset without any arguments. In the
future this case might show the current status of all printing options.
I looked backward and forward to find that this
On Thu, May 30, 2013 at 08:42:21AM -0400, Ray Stell wrote:
On May 29, 2013, at 11:07 AM, Bruce Momjian wrote:
On Wed, May 29, 2013 at 08:59:42AM -0400, Ray Stell wrote:
[ moved to hacker ] The question is whether hard-wiring these
helps more than it hurts, and which ones should be
On Sun, Aug 26, 2012 at 09:47:01AM -0400, Bruce Momjian wrote:
On Thu, Dec 29, 2011 at 10:40:19PM -0500, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Dec 29, 2011 at 5:10 PM, Jean-Yves F. Barbier 12u...@gmail.com
wrote:
CREATE INDEX tst1m_name_lu_ix ON
On Sat, Jan 26, 2013 at 11:31:49AM +0530, Amit Kapila wrote:
On Friday, January 25, 2013 8:36 PM Bruce Momjian wrote:
On Fri, Sep 14, 2012 at 02:04:51PM +, Amit kapila wrote:
On Thu, 6 Sep 2012 14:50:05 -0400 Robert Hass wrote:
On Tue, Aug 28, 2012 at 6:40 AM, Amit Kapila
On 24 June 2013 10:21, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Hi Simon,
I checked this patch. One thing I could comment on is, do you think it is
a good
idea to have oid of exception function list on
contain_volatile_functions_walker()?
The walker function is static thus here is no
On 6/28/13 6:06 PM, Bruce Momjian wrote:
On Wed, May 29, 2013 at 09:44:00AM -0400, Peter Eisentraut wrote:
On 5/28/13 10:55 PM, Bruce Momjian wrote:
Wow, I never realized other tools used -U for user, instead of -u.
Should I change pg_upgrade to use -U for 9.4? I can keep supporting -u
as
1 - 100 of 112 matches
Mail list logo
