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 wrote:
> Hello
>
> after patching I god segfault
>
> Pro
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
ncurses-libs-5.7-9.20100703.fc
>
> 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:
http://www.postgresql.org/message-id/flat/caecsyxjri++t3pevdyzawh
Hello
2013/6/28 Noah Misch :
> 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 SQL standard. DATATYPE_NAME does not; I think we should call it
> PG_DATAT
On Wed, Jun 26, 2013 at 1:40 PM, Amit Kapila wrote:
> On Tuesday, June 25, 2013 10:23 AM Amit Langote wrote:
>> Hi,
>>
>> >
>> >> So our proposal on this problem is that we must ensure that master
>> should
>> > not make any file system level changes without confirming that the
>> >> corresponding
On Thursday, June 27, 2013 5:54 PM Robert Haas wrote:
> On Wed, Jun 26, 2013 at 8:09 AM, Amit Kapila
> wrote:
> > Configuration Details
> > O/S - Suse-11
> > RAM - 128GB
> > Number of Cores - 16
> > Server Conf - checkpoint_segments = 300; checkpoint_timeout = 15 min,
> > synchronous_commit = 0FF,
Andres Freund wrote:
> Hm. There were some issues with the test_logical_decoding
> Makefile not cleaning up the regression installation properly.
> Which might have caused the issue.
>
> Could you try after applying the patches and executing a clean
> and then rebuild?
Tried, and problem persist
Robert Haas escribió:
> All right, so here's a patch that does something along those lines.
> We have to always take a new snapshot when somebody scans a catalog
> that has no syscache, because there won't be any invalidation messages
> to work off of in that case. The only catalog in that catego
Robert Haas wrote:
> Magnus Hagander wrote:
>>> The functionality of materialized views will (over time) totally swamp
>>> that of normal views, so mixing all the corresponding documentation
>>> with the documentation for normal views probably doesn’t make things
>>> easier for people that a
On Thu, Jun 27, 2013 at 09:54:45PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Should we be using entab -s 3?
>
> IIUC, that wouldn't affect leading whitespace at all. What it would
> affect I think (outside of comment blocks) is whitespace between code
> and a same-line /* ... */ comment
On Thu, Jun 27, 2013 at 6:18 PM, Tom Lane wrote:
> Alvaro Herrera 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 mapper, and uses
>> a
Bruce Momjian writes:
> Should we be using entab -s 3?
IIUC, that wouldn't affect leading whitespace at all. What it would
affect I think (outside of comment blocks) is whitespace between code
and a same-line /* ... */ comment. Personally I'd prefer that a
tab-stop-aligned /* ... */ comment alw
On Thu, Jun 27, 2013 at 05:31:54PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Noah Misch wrote:
> >> Note that emacs and pgindent remain at odds over interior tabs in comments.
> >> When pgindent finds a double-space (typically after a sentence) ending at a
> >> tab stop, it replaces the
> 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 function's implementation so that (e.g.) lead(5)
means the 5th non-null value away in
On Fri, Jun 28, 2013 at 12:47 AM, Fujii Masao wrote:
>
> Another corner case is, for example, pg_ctl -D test1 -o "-D test2",
> that is, multiple -D specifications appear in the command-line.
The patch handles this case properly. Sorry for noise..
Regards,
--
Fujii Masao
--
Sent via pgs
On Thu, Jun 27, 2013 at 6:20 PM, Jeff Janes wrote:
> On Wed, Jun 26, 2013 at 11:14 AM, Claudio Freire
> wrote:
>>
>>
>> Now I just have two indices. One that indexes only hot tuples, it's
>> very heavily queried and works blazingly fast, and one that indexes by
>> (hotness, key). I include the ho
On Sat, Jun 22, 2013 at 12:46 AM, Stephen Frost wrote:
> Noah,
>
> * Noah Misch (n...@leadboat.com) wrote:
> > This patch introduces MemoryContextAllocHuge() and repalloc_huge() that
> check
> > a higher MaxAllocHugeSize limit of SIZE_MAX/2.
>
> Nice! I've complained about this limit a few diffe
On 27 June 2013 17:47, Peter Eisentraut wrote:
> On 6/27/13 4:19 AM, Dean Rasheed wrote:
>> I'd say there are clearly people who want it, and the nature of some
>> of those answers suggests to me that we ought to have a better answer
>> in core.
>
> It's not clear what these people wanted this fun
Peter Eisentraut wrote:
> On 6/27/13 10:20 AM, Robert Haas wrote:
>> So I'd like to endorse Josh's idea: subject to appropriate review,
>> let's add these test cases. Then, if it really turns out to be too
>> burdensome, we can take them out, or figure out a sensible way to
>> split the suit
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 SQL standard. DATATYPE_NAME does not; I think we should call it
PG_DATATYPE_NAME in line with our other extensio
On Thu, Jun 27, 2013 at 9:51 AM, Atri Sharma wrote:
> >
> > commit_delay exists to artificially increase the window in which the
> > leader backend waits for more group commit followers. At higher client
> > counts, that isn't terribly useful because you'll naturally have
> > enough clients anywa
Tom Lane wrote:
> Andres Freund writes:
>
> > Being at least one of the persons having mentioned astyle to Alvaro, I
> > had tested that once and I thought the results were resembling something
> > reasonable after an hour of fiddling or so. But there were certain
> > things that I could not be m
Alvaro Herrera 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 mapper, and uses
> a new syscache underneath for performance.
> One questio
Andres Freund wrote:
> On 2013-06-27 17:33:04 -0400, Alvaro Herrera wrote:
> > One question about this patch, originally, was about the usage of
> > that relfilenode syscache. It is questionable because it would be the
> > only syscache to apply on top of a non-unique index. It is said that
> >
Andres Freund writes:
> I think before doing any serious testing we would need to lay out how
> many changes and what changes in formatting we would allow and what kind
> of enforced formatting rules we think are required.
Well, we certainly never applied any such analysis to pgindent. I
persona
Hi,
On 2013-06-27 17:33:04 -0400, Alvaro Herrera wrote:
> One question about this patch, originally, was about the usage of
> that relfilenode syscache. It is questionable because it would be the
> only syscache to apply on top of a non-unique index. It is said that
> this doesn't matter because
On 06/27/2013 11:13 PM, Jeff Janes wrote:
> Wouldn't any IO system being used on a high-end system be fairly good
> about making this work through interleaved read-ahead algorithms?
To some extent, certainly. It cannot possibly get better than a fully
sequential load, though.
> That sounds like i
On 2013-06-27 17:31:54 -0400, Tom Lane wrote:
> > Really, we should get out of patched BSD indent entirely already. How
> > about astyle, for instance? I'm told that with some sensible options,
> > the diff to what we have now is not very large, and several things
> > actually become sensible (su
On Thu, Jun 27, 2013 at 9:35 AM, Nicolas Barbier
wrote:
>
> My reasoning was: To determine which index block to update (typically
> one in both the partitioned and non-partitioned cases), one needs to
> walk the index first, which supposedly causes one additional (read)
> I/O in the non-partitione
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 mapper, and uses
a new syscache underneath for performance.
One question about this patch, originally, wa
Alvaro Herrera writes:
> Noah Misch wrote:
>> Note that emacs and pgindent remain at odds over interior tabs in comments.
>> When pgindent finds a double-space (typically after a sentence) ending at a
>> tab stop, it replaces the double-space with a tab. c-fill-paragraph will
>> convert that tab
On Thu, Jun 27, 2013 at 2:12 AM, Nicolas Barbier
wrote:
> 2013/6/26 Heikki Linnakangas :
>
> > On 26.06.2013 16:41, Yuri Levinsky wrote:
> >
> >> Heikki,
> >> As far as I understand the height of the btree will affect the number of
> >> I/Os necessary. The height of the tree does not increase line
Hello
2013/6/27 Jeevan Chalke :
> 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 -p1 command.
> 2. make/make install/make check were smooth.
> 3. My own testing didn't find any issue.
> 4. I had a code w
On Wed, Jun 26, 2013 at 11:14 AM, Claudio Freire wrote:
>
> Now I just have two indices. One that indexes only hot tuples, it's
> very heavily queried and works blazingly fast, and one that indexes by
> (hotness, key). I include the hotness value on the query, and still
> works quite fast enough.
On Wed, Jun 26, 2013 at 8:55 AM, Markus Wanner wrote:
> On 06/26/2013 05:46 PM, Heikki Linnakangas wrote:
> > We could also allow a large query to search a single table in parallel.
> > A seqscan would be easy to divide into N equally-sized parts that can be
> > scanned in parallel. It's more dif
On 06/27/2013 11:11 AM, Tom Lane wrote:
> AFAICS, the threshold question here is whether the patch helps usefully
> for tables with typical numbers of columns (ie, not 800 ;-)), and
I wouldn't expect it to help at all for < 50 columns, and probably not
measurably below 200.
> doesn't hurt materia
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Josh Berkus wrote:
> I wasn't thinking about doing it every year -- just for 9.3, in order to
> encourage more reviewers, and encourage reviewers to do more reviews.
- -1. It's not cool to set it up and then stop it the next go round.
You wan
On Thu, Jun 27, 2013 at 03:51:15PM -0400, Alvaro Herrera wrote:
> Noah Misch wrote:
>
> > Note that emacs and pgindent remain at odds over interior tabs in comments.
> > When pgindent finds a double-space (typically after a sentence) ending at a
> > tab stop, it replaces the double-space with a ta
On 06/27/2013 02:49 AM, Chris Farmiloe wrote:
> So I would think that if this was to go further then "channels" would need
> to be more of a first class citizen and created explicitly, with CREATE
> CHANNEL, DROP CHANNEL etc:
>
> CREATE CHANNEL channame;
> GRANT LISTEN ON CHANNEL channame
Noah Misch wrote:
> Note that emacs and pgindent remain at odds over interior tabs in comments.
> When pgindent finds a double-space (typically after a sentence) ending at a
> tab stop, it replaces the double-space with a tab. c-fill-paragraph will
> convert that tab to a *single* space, and that
On 06/27/2013 06:35 PM, Nicolas Barbier wrote:
> I am assuming that this (comparatively very small and super-hot) index
> is cached all the time, while for the other indexes (that are
> supposedly super-huge) only the top part stays cached.
>
> I am mostly just trying to find out where Yuri’s “par
On Wed, Jun 26, 2013 at 03:48:23PM -0700, Jeff Janes wrote:
> On Mon, May 13, 2013 at 7:26 AM, Noah Misch wrote:
> > This patch introduces MemoryContextAllocHuge() and repalloc_huge() that
> > check
> > a higher MaxAllocHugeSize limit of SIZE_MAX/2. Chunks don't bother
> > recording
> > whether t
Peter Eisentraut wrote:
> It was introduced in 0ac5ad5134f2769ccbaefec73844f8504c4d6182 "Improve
> concurrency of foreign key locking", but there is also no explanation
> there. It is apparently needed in pg_upgrade.
>
> This should be documented, and I think the help line should be changed
> to
Amit Langote escribió:
> Looking at the attlen == -1 value in tupDescriptor of the
> ResultTupleSlot, VARSIZE_ANY() is used to calculate the length and
> added to offset, but I find no way to calculate that while I am
> dubugging.
I guess you could just add a few "macro define" lines to your .gdb
Andrew Dunstan escribió:
>
> On 06/27/2013 02:38 PM, Josh Berkus wrote:
> >>If we're going to try harder to ensure that reviewers are credited,
> >>it'd probably be better to take both the commit log and the release
> >>notes out of that loop.
> >I'd pull the reviewers out of the CF app. Even in
On Thu, Jun 27, 2013 at 02:17:25PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Jun 27, 2013 at 10:10:23AM -0700, Josh Berkus wrote:
> >> What I would be opposed to is continuing to list the original authors in
> >> the release notes and putting reviewers, testers, co-authors, etc. o
On 06/27/2013 02:38 PM, Josh Berkus wrote:
If we're going to try harder to ensure that reviewers are credited,
it'd probably be better to take both the commit log and the release
notes out of that loop.
I'd pull the reviewers out of the CF app. Even in its current
implementation, that's the e
> If we're going to try harder to ensure that reviewers are credited,
> it'd probably be better to take both the commit log and the release
> notes out of that loop.
I'd pull the reviewers out of the CF app. Even in its current
implementation, that's the easiest route.
--
Josh Berkus
PostgreS
On Thu, Jun 27, 2013 at 12:54 PM, Atri Sharma wrote:
>> Well, it does take longer to fsync a larger byte range to disk than a
>> smaller byte range, in some cases. But it's generally more efficient
>> to write one larger range than many smaller ranges, so you come out
>> ahead on the whole.
>
> R
Please find attached a v12, which under timer_exceeded interrupts
clients which are being throttled instead of waiting for the end of the
transaction, as the transaction is not started yet.
Please find attached a v13 which fixes conflicts introduced by the long
options patch committed by Rob
On Mon, Jun 17, 2013 at 7:48 AM, Simon Riggs wrote:
>> I am told, one of the very popular setups for DR is to have one
>> local sync standby and one async (may be cascaded by the local sync). Since
>> this new feature is more useful for DR because taking a fresh backup on a
>> slower link is even
Bruce Momjian writes:
> On Thu, Jun 27, 2013 at 10:10:23AM -0700, Josh Berkus wrote:
>> What I would be opposed to is continuing to list the original authors in
>> the release notes and putting reviewers, testers, co-authors, etc. on a
>> separate web page. If we're gonna move people, let's move
Otherwise, he simplest possible adaptation, if it is required to have the
progress feature under fork emulation to pass it, is that under "fork
emulation" each processus reports its current progress instead of having a
collective summing.
Perhaps that's worth doing. I agree with Fabien that f
Fabien COELHO escribió:
> For the text formatting, I tried to keep the screen width under 80
> characters, because if the line is too wide it is harder to read as
> the eye may loose the alignment. But being homogeneous with other
> commands is fine with me as well.
The format chosen by Robert fi
Josh Berkus writes:
> So, is this patch currently depending on performance testing, or not?
> Like I said, it'll be a chunk of time to set up what I beleive is a
> realistic performance test, so I don't want to do it if the patch is
> likely to be bounced for other reasons.
AFAICS, the threshold
Maciej Gajewski escribió:
> > Those issues aside - I think it's a great feature! I can add the
> > grammatical fixes I made whenever the final patch is ready. Or earlier,
> > whatever works for you. Also, this is my first time reviewing a patch, so
> > please let me know if I can improve on anythi
On 2013-06-26 18:52:30 +0300, Heikki Linnakangas wrote:
> There's this in the comment near the top of the file:
Btw, I find the 'you' used in the comment somewhat irritating. Not badly
so, but reading something like:
* When you are about to write
* out WAL, it is important to call WaitXLogInser
On Thu, Jun 27, 2013 at 10:10:23AM -0700, Josh Berkus wrote:
> On 06/27/2013 08:56 AM, Bruce Momjian wrote:> Adding the names to each
> release note item is not a problem; the
> > problem is the volume of names that overwhelms the release note text. If
> > we went that direction, I predict we wou
All,
So, is this patch currently depending on performance testing, or not?
Like I said, it'll be a chunk of time to set up what I beleive is a
realistic performance test, so I don't want to do it if the patch is
likely to be bounced for other reasons.
--
Josh Berkus
PostgreSQL Experts Inc.
http:
On 06/27/2013 08:56 AM, Bruce Momjian wrote:> Adding the names to each
release note item is not a problem; the
> problem is the volume of names that overwhelms the release note text. If
> we went that direction, I predict we would just remove _all_ names from
> the release notes.
That's not a re
Fabien COELHO writes:
>>> Here is a v4 that takes into account most of your points: The report is
>>> performed for all threads by thread 0, however --progress is not supported
>>> under thread fork emulation if there are more than one thread. The report
>>> time does not slip anymore.
>> I don't
On 2013-06-27 09:17:10 -0700, Hitoshi Harada wrote:
> On Thu, Jun 27, 2013 at 6:08 AM, Robert Haas wrote:
>
> > On Wed, Jun 19, 2013 at 3:27 AM, Andres Freund
> > wrote:
> > > There will be a newer version of the patch coming today or tomorrow, so
> > > there's probably no point in looking at th
[...] So I changed that, and committed this, with some further cosmetic
changes. [...]
Thanks for the commit & the style improvements.
For the text formatting, I tried to keep the screen width under 80
characters, because if the line is too wide it is harder to read as the
eye may loose the
Hi,
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 adjustments
Greetings,
Andres Freund
--
Andres Freund http://w
On 6/25/13 2:44 PM, Josh Berkus wrote:
On the other hand, I will point out that we currently have a shortage of
reviewers, and we do NOT have a shortage of patch submitters.
That's because reviewing is harder than initial development. The only
people who think otherwise are developers who don
> Well, it does take longer to fsync a larger byte range to disk than a
> smaller byte range, in some cases. But it's generally more efficient
> to write one larger range than many smaller ranges, so you come out
> ahead on the whole.
Right, that does make sense.
So, the overhead of writing a lo
>
> commit_delay exists to artificially increase the window in which the
> leader backend waits for more group commit followers. At higher client
> counts, that isn't terribly useful because you'll naturally have
> enough clients anyway, but at lower client counts particularly where
> fsyncs have h
On 6/27/13 4:19 AM, Dean Rasheed wrote:
> I'd say there are clearly people who want it, and the nature of some
> of those answers suggests to me that we ought to have a better answer
> in core.
It's not clear what these people wanted this functionality for. They
all wanted to analyze a table to c
Andres Freund writes:
> On 2013-06-26 20:07:40 -0400, Tom Lane wrote:
>> I still want to delete the test for SOCK_ERRNO == 0. I traced that back
>> to commit da9501bddb4dc33c031b1db6ce2133bcee7b, but I can't find
>> anything in the mailing list archives to explain that. I have an
>> inquiry
Dear Robert,
Here is a v4 that takes into account most of your points: The report is
performed for all threads by thread 0, however --progress is not supported
under thread fork emulation if there are more than one thread. The report
time does not slip anymore.
I don't believe that to be an a
2013/6/27 Markus Wanner :
> On 06/27/2013 11:12 AM, Nicolas Barbier wrote:
>
>> Imagine that there are a lot of indexes, e.g., 50. Although a lookup
>> (walking one index) is equally fast, an insertion must update al 50
>> indexes. When each index requires one extra I/O (because each index is
>> o
On Thu, Jun 27, 2013 at 12:56 AM, Atri Sharma wrote:
> Now, with group commits, do we see a spike in that disk write latency,
> especially in the cases where the user has set wal_buffers to a high
> value?
commit_delay exists to artificially increase the window in which the
leader backend waits f
Bruce Momjian writes:
> On Thu, Jun 27, 2013 at 11:50:07AM -0400, Christopher Browne wrote:
>> It could be pretty satisfactory to have a simple listing, in the
>> release notes, of the set of reviewers. That's a lot less
>> bookkeeping than tracking this for each and every change.
> Adding the n
On 06/27/2013 12:12 PM, Tom Lane wrote:
Bruce Momjian writes:
On Thu, Jun 27, 2013 at 11:50:07AM -0400, Christopher Browne wrote:
It could be pretty satisfactory to have a simple listing, in the
release notes, of the set of reviewers. That's a lot less
bookkeeping than tracking this for each
On Thu, Jun 27, 2013 at 6:08 AM, Robert Haas wrote:
> On Wed, Jun 19, 2013 at 3:27 AM, Andres Freund
> wrote:
> > There will be a newer version of the patch coming today or tomorrow, so
> > there's probably no point in looking at the one linked above before
> > that...
>
> This patch is marked a
On Thu, Jun 27, 2013 at 9:22 AM, Andres Freund wrote:
> On 2013-06-27 15:11:26 +0200, Magnus Hagander wrote:
> > On Thu, Jun 27, 2013 at 2:16 PM, Peter Eisentraut
> wrote:
> > > On 6/27/13 6:34 AM, Magnus Hagander wrote:
> > >> Is there a reason why we have set the min allowed value for port to 1
On Thu, Jun 27, 2013 at 11:50:07AM -0400, Christopher Browne wrote:
> b) It would be a pretty good thing to mention reviewers within commit notes;
> that provides some direct trace-back as to who it was that either validated
> that the change was good, or that let a bad one slip through.
>
> c) Th
On Thu, Jun 27, 2013 at 10:37 AM, Robert Haas wrote:
> On Tue, Jun 25, 2013 at 2:27 PM, Andrew Dunstan
> wrote:
> > I'd like to see prizes each release for "best contribution" and "best
> > reviewer" - I've thought for years something like this would be worth
> > trying. Committers and core memb
On Thu, Jun 27, 2013 at 10:36 AM, Josh Kupershmidt wrote:
> On Wed, Jun 26, 2013 at 12:22 PM, Fujii Masao wrote:
>> On Wed, Jun 26, 2013 at 2:36 PM, Hari Babu wrote:
>>> On June 26, 2013 5:02 AM Josh Kupershmidt wrote:
Thanks for the feedback. Attached is a rebased version of the patch with
On Thu, Jun 27, 2013 at 5:49 AM, Dimitri Fontaine
wrote:
> I think that's a limitation of the old model and we don't want to turn
> templates for extensions into being shared catalogs. At least that's my
> understanding of the design consensus.
I agree.
--
Robert Haas
EnterpriseDB: http://www.e
On Thu, Jun 27, 2013 at 7:29 AM, Marko Kreen wrote:
> On Thu, Jun 27, 2013 at 11:28 AM, Dean Rasheed
> wrote:
>> On 26 June 2013 21:46, Peter Eisentraut wrote:
>>> On 6/26/13 4:04 PM, Dean Rasheed wrote:
A quick google search reveals several people asking for something like
this, and
On Thu, Jun 27, 2013 at 7:27 AM, Amit Kapila wrote:
> Now I can look into it further, I have still not gone through in detail
> about your new approach to calculate the reltuples, but I am wondering
> whether there can be anyway with which estimates can be improved with
> different calculation in
On 6/27/13 10:57 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 6/26/13 12:17 PM, Tom Lane wrote:
>>> (I like to
>>> point at mysql's regression tests, which take well over an hour even on
>>> fast machines. If lots of tests are so helpful, why is their bug rate
>>> no better than ours?)
>
On Thu, Jun 27, 2013 at 5:29 AM, Magnus Hagander wrote:
>> The functionality of materialized views will (over time) totally swamp
>> that of normal views, so mixing all the corresponding documentation
>> with the documentation for normal views probably doesn’t make things
>> easier for people that
On Thu, Jun 27, 2013 at 3:56 AM, Atri Sharma wrote:
> When we do a commit, WAL buffers are written to the disk. This has a
> disk latency for the required I/O.
Check.
> Now, with group commits, do we see a spike in that disk write latency,
> especially in the cases where the user has set wal_buf
On Wed, Jun 26, 2013 at 7:16 AM, Fabien COELHO wrote:
> Here is a v4 that takes into account most of your points: The report is
> performed for all threads by thread 0, however --progress is not supported
> under thread fork emulation if there are more than one thread. The report
> time does not s
2013-06-27 17:03 keltezéssel, Fujii Masao írta:
On Thu, Jun 27, 2013 at 2:22 PM, Boszormenyi Zoltan wrote:
Hi,
I just realized that in the original incarnation of lock_timeout,
I used ERRCODE_LOCK_NOT_AVAILABLE (to be consistent with NOWAIT)
but the patch that was accepted into 9.3 contained E
On Tue, Jun 25, 2013 at 4:28 PM, Heikki Linnakangas
wrote:
>> The only feedback we have on how bad things are is how long it took
>> the last fsync to complete, so I actually think that's a much better
>> way to go than any fixed sleep - which will often be unnecessarily
>> long on a well-behaved
> Looking around the 9.3 doc, I found a small, but not-insignificant
> error in the documentation.
Thanks for finding and fixing. Patch committed.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postg
On Thu, Jun 27, 2013 at 2:22 PM, Boszormenyi Zoltan wrote:
> Hi,
>
> I just realized that in the original incarnation of lock_timeout,
> I used ERRCODE_LOCK_NOT_AVAILABLE (to be consistent with NOWAIT)
> but the patch that was accepted into 9.3 contained ERRCODE_QUERY_CANCELED
> which is the same
Peter Eisentraut writes:
> On 6/26/13 12:17 PM, Tom Lane wrote:
>> (I like to
>> point at mysql's regression tests, which take well over an hour even on
>> fast machines. If lots of tests are so helpful, why is their bug rate
>> no better than ours?)
> Tests are not (primarily) there to prevent
Andres Freund wrote:
> I don't think I actually found any workload where the bgwriter
> actually wroute out a relevant percentage of the necessary pages.
I had one at Wisconsin Courts. The database which we targeted with
logical replication from the 72 circuit court databases (plus a few
others
On 6/26/13 12:17 PM, Tom Lane wrote:
> (I like to
> point at mysql's regression tests, which take well over an hour even on
> fast machines. If lots of tests are so helpful, why is their bug rate
> no better than ours?)
Tests are not (primarily) there to prevent bugs.
--
Sent via pgsql-hacker
On 6/27/13 10:20 AM, Robert Haas wrote:
> So I'd like to endorse Josh's idea: subject to appropriate review,
> let's add these test cases. Then, if it really turns out to be too
> burdensome, we can take them out, or figure out a sensible way to
> split the suite. Pushing all of Robins work into
Robins Tharakan writes:
> 2. Should I assume that all database objects that get created, need to be
> dropped explicitly? Or is this point specifically about ROLES?
It's about any global objects (that wouldn't get dropped by dropping the
regression database). As far as local objects go, there ar
On 6/23/13 10:50 PM, Tom Lane wrote:
> It'd sure be interesting to know what the SQL committee's target parsing
> algorithm is.
It's whatever Oracle and IBM implement.
> Or maybe they really don't give a damn about breaking
> applications every time they invent a new reserved word?
Well, yes, I
On Tue, Jun 25, 2013 at 2:27 PM, Andrew Dunstan wrote:
> I'd like to see prizes each release for "best contribution" and "best
> reviewer" - I've thought for years something like this would be worth
> trying. Committers and core members should not be eligible - this is about
> encouraging new peop
On Thu, Jun 27, 2013 at 10:24 AM, Fujii Masao wrote:
> On Thu, Jun 27, 2013 at 10:02 PM, Robert Haas wrote:
>> On Tue, Jun 25, 2013 at 3:09 PM, Fabien COELHO wrote:
I think --quiet-log should be spelled --quiet.
>>>
>>> ISTM that --quiet usually means "not verbose on stdout", so I added log
On Wed, Jun 26, 2013 at 5:49 PM, Jeff Janes wrote:
> On Tue, Jun 18, 2013 at 12:09 AM, Heikki Linnakangas
> wrote:
>> Jeff's patch seems to somewhat alleviate the huge fall in performance I'm
>> otherwise seeing without the nonlocked-test patch. With the nonlocked-test
>> patch, if you squint you
On 2013-06-27 09:50:32 -0400, Robert Haas wrote:
> On Thu, Jun 27, 2013 at 9:01 AM, Andres Freund wrote:
> > Contention wise I aggree. What I have seen is that we have a huge
> > amount of cacheline bouncing around the buffer header spinlocks.
>
> How did you measure that?
perf record -e cache-m
1 - 100 of 160 matches
Mail list logo
