On Tue, Jan 14, 2014 at 2:29 PM, Tom Lane wrote:
>
> One reason I'm thinking this is that whatever we do to ameliorate
> the semantic issues is going to slow down the forward transition
> function --- to no benefit unless the aggregate is being used as a
> window function in a moving window. So
On Thu, Jan 16, 2014 at 9:45 AM, Florian Pflug wrote:
> BTW, AVG() and STDDEV() have the same issue. The problem is just partially
> masked by the division by N (or N-1) at the end, because we always emit as
> least 16 fractional digits when dividing. So you have to have an input
> value with a l
On Wed, Jan 15, 2014 at 8:23 PM, Peter Geoghegan wrote:
> I have an idea of what I could do to fix this, but I don't have time
> to make sure that my hunch is correct.
It might just be a matter of:
@@ -186,6 +186,13 @@ ExecLockHeapTupleForUpdateSpec(EState *estate,
switch (test)
On Thu, Jan 16, 2014 at 3:47 PM, Florian Pflug wrote:
> BTW, as it stands, the patch currently uses the inverse transition
> function only when *all* the aggregates belonging to one window clause
> provide one. After working with the code a bit, I think that a bit of
> reshuffling would allow tha
On 01/16/2014 02:53 AM, Josh Berkus wrote:
> Hackers,
>
> ALTER SYSTEM SET has been committed and recovery.conf GUCs are being
> reviewed. I'm going to make a last case for conf.d in relation to these
> two patches before 9.4 goes out the door.
Personally, I'd find conf.d greatly more useful whe
On Thu, Jan 16, 2014 at 1:31 AM, Josh Berkus wrote:
> On 01/15/2014 11:10 AM, Stephen Frost wrote:
>
>> Independent of the above, I don't agree with that. postgresql.auto.conf
>> is a special thing and should have its own special place. For once
>> thing, when putting configuration files in a se
Hi MauMau,
Ah. Sorry, I missed that part. As NTFS junctions and symbolic links are
different (although they behave similarly), there seems only a minor
inconvenience related to misleading error message i.e.
+ #ifdef WIN32
> + if (rmdir(linkloc) < 0 && errno != ENOENT)
> + #else
>if (unlink(l
On Thu, Jan 16, 2014 at 12:49 AM, Robert Haas wrote:
> On Wed, Jan 15, 2014 at 7:28 AM, Amit Kapila wrote:
>> Unpatched
>> ---
>> testname | wal_generated |
>> duration
>> --+--
On Tue, Jan 14, 2014 at 3:07 AM, Heikki Linnakangas
wrote:
>> Right, but with your approach, can you really be sure that you have
>> the right rejecting tuple ctid (not reject)? In other words, as you
>> wait for the exclusion constraint to conclusively indicate that there
>> is a conflict, minute
* Peter Eisentraut (pete...@gmx.net) wrote:
> In my mind, a conf.d directory is an extension of a single-file
> configuration, and so it should be handled that way.
I'm apparently out on some funny limb with this thought, but I'll throw
it out there anyway- in my head, the 'postgresql.auto.conf' t
On Jan16, 2014, at 02:32 , Florian Pflug wrote:
> On Jan14, 2014, at 17:39 , Florian Pflug wrote:
>> On Jan14, 2014, at 11:06 , David Rowley wrote:
>>> Here's a patch which removes sum(numeric) and changes the documents a
>>> little to remove a reference to using sum(numeric) to workaround the
On Wed, Jan 15, 2014 at 8:41 PM, Jan Kara wrote:
> On Wed 15-01-14 10:12:38, Robert Haas wrote:
>> On Wed, Jan 15, 2014 at 4:35 AM, Jan Kara wrote:
>> > Filesystems could in theory provide facility like atomic write (at least up
>> > to a certain size say in MB range) but it's not so easy and whe
On Jan14, 2014, at 17:39 , Florian Pflug wrote:
> On Jan14, 2014, at 11:06 , David Rowley wrote:
>> Here's a patch which removes sum(numeric) and changes the documents a little
>> to remove a reference to using sum(numeric) to workaround the fact that
>> there's no inverse transitions for sum(f
On 28 November 2013 22:17, Robert Haas wrote:
> The fact that you've needed to modify SetHintBits() to make this work
> is pretty nasty. I'm not exactly sure what to do about that, but it
> doesn't seem good.
That makes me feel bad also.
I think we should be looking for some special case routi
On Tue, Jan 14, 2014 at 3:25 PM, Heikki Linnakangas
wrote:
> Attached is a patch doing that, to again demonstrate what I mean. I'm not
> sure if setting xmin to invalid is really the best way to mark the tuple
> dead; I don't think a tuple's xmin can currently be InvalidTransaction under
> any oth
On Wed, Jan 15, 2014 at 07:08:18PM -0500, Tom Lane wrote:
> Dave Chinner writes:
> > On Wed, Jan 15, 2014 at 10:12:38AM -0500, Tom Lane wrote:
> >> What we'd really like for checkpointing is to hand the kernel a boatload
> >> (several GB) of dirty pages and say "how about you push all this to disk
On Wed, Jan 15, 2014 at 10:12:38AM -0500, Robert Haas wrote:
> On Wed, Jan 15, 2014 at 4:35 AM, Jan Kara wrote:
> > Filesystems could in theory provide facility like atomic write (at least up
> > to a certain size say in MB range) but it's not so easy and when there are
> > no strong usecases fs p
On Wed, Jan 15, 2014 at 07:13:27PM -0500, Tom Lane wrote:
> Dave Chinner writes:
> > On Wed, Jan 15, 2014 at 02:29:40PM -0800, Jeff Janes wrote:
> >> And most importantly, "Also, please don't freeze up everything else in the
> >> process"
>
> > If you hand writeback off to the kernel, then writeb
On Wed, Jan 15, 2014 at 02:29:40PM -0800, Jeff Janes wrote:
> On Wed, Jan 15, 2014 at 7:12 AM, Tom Lane wrote:
>
> > Heikki Linnakangas writes:
> > > On 01/15/2014 07:50 AM, Dave Chinner wrote:
> > >> FWIW [and I know you're probably sick of hearing this by now], but
> > >> the blk-io throttling
On Wed, Jan 15, 2014 at 10:12:38AM -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 01/15/2014 07:50 AM, Dave Chinner wrote:
> >> FWIW [and I know you're probably sick of hearing this by now], but
> >> the blk-io throttling works almost perfectly with applications that
> >> use direct IO
Robert Haas writes:
> I don't see that as a problem. What we're struggling with today is
> that, until we fsync(), the system is too lazy about writing back
> dirty pages. And then when we fsync(), it becomes very aggressive and
> system-wide throughput goes into the tank. What we're aiming to
Dave Chinner writes:
> On Wed, Jan 15, 2014 at 07:08:18PM -0500, Tom Lane wrote:
>> No, we'd be happy to re-request it during each checkpoint cycle, as
>> long as that wasn't an unduly expensive call to make. I'm not quite
>> sure where such requests ought to "live" though. One idea is to tie
>>
On Wed, Jan 15, 2014 at 7:22 PM, Dave Chinner wrote:
> No, I meant the opposite - in low memory situations, the system is
> going to go to hell in a handbasket because we are going to cause a
> writeback IO storm cleaning memory regardless of these IO
> priorities. i.e. there is no way we'll let "
On 01/16/2014 01:21 AM, Tom Lane wrote:
> Vik Fearing writes:
>>> I am marking this patch as 'returned with feedback' in the commitfest app.
>> It looks like this patch got left behind in the previous commitfest.
>> What is the policy for moving it? Is it too late and will have to wait
>> until
Vik Fearing writes:
>> I am marking this patch as 'returned with feedback' in the commitfest app.
> It looks like this patch got left behind in the previous commitfest.
> What is the policy for moving it? Is it too late and will have to wait
> until the next commitfest?
> https://commitfest.po
On Thu, Jan 16, 2014 at 01:07:50AM +0100, Vik Fearing wrote:
> On 11/24/2013 02:03 AM, Vik Fearing wrote:
> > On 10/15/2013 07:50 AM, David Fetter wrote:
> >> On Mon, Oct 07, 2013 at 11:16:56PM -0700, David Fetter wrote:
> >>> Folks,
> >>>
> >>> Please find attached a patch implementing and documen
On 1/15/14, 12:00 AM, Claudio Freire wrote:
My completely unproven theory is that swapping is overwhelmed by
near-misses. Ie: a process touches a page, and before it's actually
swapped in, another process touches it too, blocking on the other
process' read. But the second process doesn't account
Dave Chinner writes:
> On Wed, Jan 15, 2014 at 02:29:40PM -0800, Jeff Janes wrote:
>> And most importantly, "Also, please don't freeze up everything else in the
>> process"
> If you hand writeback off to the kernel, then writeback for memory
> reclaim needs to take precedence over "metered writeb
Dave Chinner writes:
> On Wed, Jan 15, 2014 at 10:12:38AM -0500, Tom Lane wrote:
>> What we'd really like for checkpointing is to hand the kernel a boatload
>> (several GB) of dirty pages and say "how about you push all this to disk
>> over the next few minutes, in whatever way seems optimal given
On 11/24/2013 02:03 AM, Vik Fearing wrote:
> On 10/15/2013 07:50 AM, David Fetter wrote:
>> On Mon, Oct 07, 2013 at 11:16:56PM -0700, David Fetter wrote:
>>> Folks,
>>>
>>> Please find attached a patch implementing and documenting, to some
>>> extent, $subject. I did this in aid of being able to i
On 01/15/2014 03:07 AM, Michael Paquier wrote:
> I just had a quick look at this patch, no testing at all.
Thank you for looking at it.
> I am seeing that regression tests are still missing here, they should be
> added in
> src/test/regress/input/tablespace.source.
New patch attached, with re
Alexander Korotkov writes:
> Revised version of patch with necessary comments.
I looked at this patch a bit. It seems like this:
+ *BLANK_COLOR_SIZE - How much blank character is more frequent than
+ * other character in average
+ #define BLANK_COLOR_SIZE 32
is
Alvaro Herrera escribió:
> Antonin Houska escribió:
> > Thanks for checking. The new version addresses your findings.
>
> I gave this patch a look.
BTW I also moved the patch the commitfest currently running, and set it
waiting-on-author.
Your move.
--
Álvaro Herrerahttp://www.
On Wed, Jan 15, 2014 at 7:12 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 01/15/2014 07:50 AM, Dave Chinner wrote:
> >> FWIW [and I know you're probably sick of hearing this by now], but
> >> the blk-io throttling works almost perfectly with applications that
> >> use direct IO.
>
On 15 January 2014 16:47, Robert Haas wrote:
>>> There would be a postgresql.conf parameter prune_cost_limit, as well
>>> as a table level parameter that would prevent pruning except via
>>> VACUUM.
>>>
>>> This will help in these ways
>>> * Reduce write I/O from SELECTs and pg_dump - improving b
On 1/15/14, 3:01 PM, Josh Berkus wrote:
> Three issues:
>
> a) if postgresql is still going to look for a recovery.conf file in the
> usual place, but we are changing the names and meaning of some of the
> parameters, then aren't we making the upgrade problem much worse?
That assumes that we are
On 1/15/14, 4:35 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 1/15/14, 1:53 PM, Josh Berkus wrote:
>>> Yes, I'm also arguing that postgresql.auto.conf should go into conf.d.
>>> I said I'd bring that up again after ALTER SYSTEM SET was committed, and
>>> here it is.
>
>> Independent of th
Peter Eisentraut writes:
> On 1/15/14, 1:53 PM, Josh Berkus wrote:
>> Yes, I'm also arguing that postgresql.auto.conf should go into conf.d.
>> I said I'd bring that up again after ALTER SYSTEM SET was committed, and
>> here it is.
> Independent of the above, I don't agree with that. postgresql.
Florian Pflug writes:
> I'm currently thinking the best way forward is to get a basic patch
> without any NUMERIC stuff committed, and to revisit this after that's done.
+1. I liked Robert's suggestion that the "fast" aggregates be implemented
as a contrib module rather than directly in core, to
On Jan15, 2014, at 19:56 , Robert Haas wrote:
> It strikes me that for numeric what you really need is to just tell
> the sum operation, whether through a parameter or otherwise, how many
> decimal places to show in the output. Obviously that's not a
> practical change for sum() itself, but if we
Hi,
On 2014-01-15 13:28:25 -0500, Robert Haas wrote:
> - I think you should just regard ReplicationSlotCtlLock as protecting
> the "name" and "active" flags of every slot. ReplicationSlotCreate()
> would then not need to mess with the spinlocks at all, and
> ReplicationSlotAcquire and Replication
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
> However, Debian is *never* going to add conf.d to the packages if we
> don't recommend it as an upstream project. And, frankly, I use the
> apt.postgresql.org packages anyway, which would certainly include
> anything which was decided on this list.
On 01/15/2014 11:10 AM, Stephen Frost wrote:
> I don't buy this argument one bit- certainly, on Debian, the defaults
> are overridden for a number of variables already and could be done to
> enable a conf.d directory as well. Directory creation would, of
> course, also be able to be handled by the
On Wed, January 15, 2014 06:30, Peter Eisentraut wrote:
> As we all know, the client programs (src/bin/) don't have any real test
>
> So I wrote something.
>
> I chose to use Perl-based tools, prove and Test::More, because those are
> [ 0001-Add-TAP-tests-for-client-programs.patch ] 32 k
I gave
On 2013-12-08 01:32:45 +0100, Andres Freund wrote:
> On 2013-12-06 09:54:59 -0500, Peter Eisentraut wrote:
> > On 11/11/13, 12:01 PM, Tom Lane wrote:
> > > I do recall Peter saying that the infrastructure knows how to
> > > verify conversion specs in translated strings, so it would have to be
> > >
On 1/15/14, 1:53 PM, Josh Berkus wrote:
> I'm particularly thinking about this in relation to the merger of
> recovery.conf and postgresql.conf. There are several tools already
> (RepMgr, OminPITR, HandyRep, pgPool, etc.) which manage recovery.conf
> separately from postgresql.conf. These tools w
On Wed, Jan 15, 2014 at 7:28 AM, Amit Kapila wrote:
> Unpatched
> ---
> testname | wal_generated |
> duration
> --+--+--
> one short and one
On Wed 15-01-14 14:38:44, Hannu Krosing wrote:
> On 01/15/2014 02:01 PM, Jan Kara wrote:
> > On Wed 15-01-14 12:16:50, Hannu Krosing wrote:
> >> On 01/14/2014 06:12 PM, Robert Haas wrote:
> >>> This would be pretty similar to copy-on-write, except
> >>> without the copying. It would just be
> >>> f
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
> In 9.3, we added support for a config directory (conf.d), but have it
> disabled by default. For tool authors, this makes conf.d useless since
> you never know, on any given installation, whether it will be
> present/enabled or not. While we don't
On Wed, Jan 15, 2014 at 3:41 PM, Stephen Frost wrote:
> * Claudio Freire (klaussfre...@gmail.com) wrote:
>> But, still, the implementation is very similar to what postgres needs:
>> sharing a physical page for two distinct logical pages, efficiently,
>> with efficient copy-on-write.
>
> Agreed, ex
On Tue, Jan 14, 2014 at 4:16 AM, David Rowley wrote:
> On Tue, Jan 14, 2014 at 9:09 PM, David Rowley wrote:
>>
>> I think unless anyone has some objections I'm going to remove the inverse
>> transition for SUM(numeric) and modify the documents to tell the user how to
>> build their own FAST_SUM(n
Hackers,
ALTER SYSTEM SET has been committed and recovery.conf GUCs are being
reviewed. I'm going to make a last case for conf.d in relation to these
two patches before 9.4 goes out the door.
In 9.3, we added support for a config directory (conf.d), but have it
disabled by default. For tool aut
* Claudio Freire (klaussfre...@gmail.com) wrote:
> But, still, the implementation is very similar to what postgres needs:
> sharing a physical page for two distinct logical pages, efficiently,
> with efficient copy-on-write.
Agreed, except that KSM seems like it'd be slow/lazy about it and I'm
gue
On 1/15/14, 1:46 AM, Erik Rijkers wrote:
> The seems to be a dependency on IPC::Run
>
> I can install that, of course... but I suppose you want to make this work
> without that.
No, IPC::Run will be required. It looked like it was part of the
default installation where I tested, but apparently
On Wed, Jan 15, 2014 at 2:06 AM, Jaime Casanova wrote:
> On Wed, Jan 15, 2014 at 2:00 AM, Jaime Casanova wrote:
>> On Mon, Nov 18, 2013 at 12:27 PM, Andres Freund
>> wrote:
>>
>>> * Maybe we should rename names like pause_at_recovery_target to
>>> recovery_pause_at_target? Since we already fo
On Wed, Jan 15, 2014 at 1:53 AM, KONDO Mitsumasa
wrote:
> I create patch that can drop duplicate buffers in OS using usage_count
> alogorithm. I have developed this patch since last summer. This feature seems
> to
> be discussed in hot topic, so I submit it more faster than my schedule.
>
> When
Review of patch 0002:
- I think you should just regard ReplicationSlotCtlLock as protecting
the "name" and "active" flags of every slot. ReplicationSlotCreate()
would then not need to mess with the spinlocks at all, and
ReplicationSlotAcquire and ReplicationSlotDrop get a bit simpler too I
think.
On Thu, Jan 9, 2014 at 2:50 PM, Robert Haas wrote:
>
> On Tue, Jan 7, 2014 at 10:55 PM, Dilip kumar
wrote:
> > Below attached patch is implementing following todo item..
> >
> > machine-readable pg_controldata?
> >
> > http://www.postgresql.org/message-id/4b901d73.8030...@agliodbs.com
> >
> > Pos
On Wed, Jan 15, 2014 at 2:52 PM, Tom Lane wrote:
> Robert Haas writes:
>> I think that the bottom line is that we're not likely to make massive
>> changes to the way that we do block caching now. Even if some other
>> scheme could work much better on Linux (and so far I'm unconvinced
>> that any
Magnus Hagander writes:
> One thing I noticed - in MSVC, the config parameter "krb5" (equivalent of
> the removed --with-krb5) enabled *both* krb5 and gssapi, and there is no
> separate config parameter for gssapi. Do we want to rename that one to
> "gss", or do we want to keep it as "krb5"? Renam
Robert Haas writes:
> I think that the bottom line is that we're not likely to make massive
> changes to the way that we do block caching now. Even if some other
> scheme could work much better on Linux (and so far I'm unconvinced
> that any of the proposals made here would in fact work much bett
On Wed, Jan 15, 2014 at 12:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 14, 2014 at 9:28 PM, Peter Eisentraut wrote:
>>> Something is causing this new compiler warning:
>>>
>>> setup.c: In function ‘setup_dynamic_shared_memory’:
>>> setup.c:102:3: error: format ‘%llu’ expects argu
This 0001 patch, to log running transactions more frequently, has been
pending for a long time now, and I haven't heard any objections, so
I've gone ahead and committed that part.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
Robert Haas writes:
> On Tue, Jan 14, 2014 at 9:28 PM, Peter Eisentraut wrote:
>> Something is causing this new compiler warning:
>>
>> setup.c: In function setup_dynamic_shared_memory:
>> setup.c:102:3: error: format %llu expects argument of type long long
>> unsigned int, but argument 2
On Wed, Jan 15, 2014 at 1:35 PM, Stephen Frost wrote:
>> And there's a nice bingo. Had forgotten about KSM. KSM could help lots.
>>
>> I could try to see of madvising shared_buffers as mergeable helps. But
>> this should be an automatic case of KSM - ie, when reading into a
>> page-aligned address
On Tue, Jan 14, 2014 at 4:13 PM, Simon Riggs wrote:
> On 8 January 2014 08:33, Simon Riggs wrote:
>> VACUUM cleans up blocks, which is nice because it happens offline in a
>> lazy manner.
>>
>> We also make SELECT clean up blocks as it goes. That is useful in OLTP
>> workloads, but it means that
* Claudio Freire (klaussfre...@gmail.com) wrote:
> Yes, that's basically zero-copy reads.
>
> It could be done. The kernel can remap the page to the physical page
> holding the shared buffer and mark it read-only, then expire the
> buffer and transfer ownership of the page if any page fault happen
On 2014-01-15 11:19:52 -0500, Robert Haas wrote:
> On Tue, Jan 14, 2014 at 7:54 AM, Andres Freund wrote:
> > On 2014-01-14 12:31:09 +0900, Michael Paquier wrote:
> >> Currently, pg_start_backup and pg_stop_backup cannot run on a standby
> >> because it is not possible to write a backup_label file
On Wed, Jan 15, 2014 at 10:53 AM, Mel Gorman wrote:
> I realise that now and sorry for the noise.
>
> I later read the parts of the thread that covered the strict ordering
> requirements and in a summary mail I split the requirements in two. In one,
> there are dirty sticky pages that the kernel s
On Tue, Jan 14, 2014 at 7:54 AM, Andres Freund wrote:
> On 2014-01-14 12:31:09 +0900, Michael Paquier wrote:
>> Currently, pg_start_backup and pg_stop_backup cannot run on a standby
>> because it is not possible to write a backup_label file to disk,
>> because of the nature of a standby server pre
On 1/15/14 3:09 PM, Pavel Stehule wrote:
You first should to say, what is warning and why it is only warning and not
error.
Personally, I'm a huge fan of the computer telling me that I might have
made a mistake. But on the other hand, I also really hate it when the
computer gets in my way wh
On Wed, Jan 15, 2014 at 10:16:27AM -0500, Robert Haas wrote:
> On Wed, Jan 15, 2014 at 4:44 AM, Mel Gorman wrote:
> > That applies if the dirty pages are forced to be kept dirty. You call
> > this pinned but pinned has special meaning so I would suggest calling it
> > something like dirty-sticky p
On 16 April 2013 14:37, Simon Riggs wrote:
> On 16 April 2013 13:57, Heikki Linnakangas wrote:
>
>> You still need to check the args, if the function is nextval, otherwise you
>> incorrectly perform the optimization for something like
>> "nextval(myvolatilefunc())".
>
> Guess so. At least its an
On 2014-01-15 10:19:32 -0500, Robert Haas wrote:
> On Tue, Jan 14, 2014 at 9:28 PM, Peter Eisentraut wrote:
> > Something is causing this new compiler warning:
> >
> > setup.c: In function ‘setup_dynamic_shared_memory’:
> > setup.c:102:3: error: format ‘%llu’ expects argument of type ‘long long
>
On Tue, Jan 14, 2014 at 9:53 PM, Kevin Grittner wrote:
> I'm not seeing that one but I am now getting these:
>
> setup.c: In function ‘test_shm_mq_setup’:
> setup.c:65:25: warning: ‘outq’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> setup.c:66:24: warning: ‘inq’ may be u
On Tue, Jan 14, 2014 at 9:28 PM, Peter Eisentraut wrote:
> Something is causing this new compiler warning:
>
> setup.c: In function ‘setup_dynamic_shared_memory’:
> setup.c:102:3: error: format ‘%llu’ expects argument of type ‘long long
> unsigned int’, but argument 2 has type ‘Size’ [-Werror=for
On Wed, Jan 15, 2014 at 4:44 AM, Mel Gorman wrote:
> That applies if the dirty pages are forced to be kept dirty. You call
> this pinned but pinned has special meaning so I would suggest calling it
> something like dirty-sticky pages. It could be the case that such hinting
> will have the pages ex
On Wed, Jan 15, 2014 at 4:35 AM, Jan Kara wrote:
> Filesystems could in theory provide facility like atomic write (at least up
> to a certain size say in MB range) but it's not so easy and when there are
> no strong usecases fs people are reluctant to make their code more complex
> unnecessarily.
Heikki Linnakangas writes:
> On 01/15/2014 07:50 AM, Dave Chinner wrote:
>> FWIW [and I know you're probably sick of hearing this by now], but
>> the blk-io throttling works almost perfectly with applications that
>> use direct IO.
> For checkpoint writes, direct I/O actually would be reasona
>> I'm confused too. Surely there are lots of ways a portal could get
>> dropped, but most of them would have left traces in the postmaster log,
>> I'd think, since you evidently have log_statement == LOGSTMT_ALL.
>> What was log_min_messages set to?
>
> I don't have it at this moment. I requeste
On 01/15/2014 07:50 AM, Dave Chinner wrote:
However, the first problem is dealing with the IO storm problem on
fsync. Then we can measure the effect of spreading those writes out
in time and determine what triggers read starvations (if they are
apparent). The we can look at whether IO scheduling
On 1 August 2013 01:53, Noah Misch wrote:
> On Mon, Jul 15, 2013 at 05:50:40PM +0100, Simon Riggs wrote:
>> On 15 July 2013 15:06, Robert Haas wrote:
>> > Generally, the question on the table is: to what extent do MVCC
>> > catalog scans make the world safe for concurrent DDL, or put
>> > negativ
From: "Asif Naeem"
As you have
followed destroy_tablespace_directories() function, Is there any specific
reason not to use same logic to detect type of the file/link i.e.
“(lstat(linkloc, &st) == 0 && S_ISDIR(st.st_mode))”, It also seems have
more appropriate error message i.e.
Thanks for revi
> One assumption would be that Postgres is perfectly happy with the current
> kernel behaviour in which case our discussion here is done.
It has been demonstrated that this statement was farcical. The thread is
massive just from interaction with the LSF/MM program committee. I'm hoping
that ther
2014/1/15 Marko Tiikkaja
> On 1/15/14 2:27 PM, Pavel Stehule wrote:
>
>> 2014/1/15 Marko Tiikkaja
>>
>>> Yeah, me neither, it's just something that needs to be communicated very
>>> clearly. So probably just a list plpgsql.warnings would be the most
>>> appropriate then.
>>>
>>>
>> I am think
On 1/15/14 2:27 PM, Pavel Stehule wrote:
2014/1/15 Marko Tiikkaja
Yeah, me neither, it's just something that needs to be communicated very
clearly. So probably just a list plpgsql.warnings would be the most
appropriate then.
I am thinking so the name is not good. Changing handling warning
On Tue, Jan 14, 2014 at 5:23 PM, Dave Chinner wrote:
> By default, background writeback doesn't start until 10% of memory
> is dirtied, and on your machine that's 25GB of RAM. That's way to
> high for your workload.
>
> It appears to me that we are seeing large memory machines much more
> commonly
On Tue, Jan 14, 2014 at 4:23 PM, James Bottomley
wrote:
> Yes, that's what I was thinking: it's a cache. About how many files
> comprise this cache? Are you thinking it's too difficult for every
> process to map the files?
No, I'm thinking that would throw cache coherency out the window.
Separa
On 01/15/2014 02:01 PM, Jan Kara wrote:
> On Wed 15-01-14 12:16:50, Hannu Krosing wrote:
>> On 01/14/2014 06:12 PM, Robert Haas wrote:
>>> This would be pretty similar to copy-on-write, except
>>> without the copying. It would just be
>>> forget-from-the-buffer-pool-on-write.
>> +1
>>
>> A version
On Fri, Jun 21, 2013 at 5:39 PM, Erik Rijkers wrote:
> On Fri, June 21, 2013 15:11, Alexander Korotkov wrote:
> > On Fri, Jun 21, 2013 at 2:40 PM, Erik Rijkers wrote:
> >
> >> On Fri, June 21, 2013 05:25, Tom Lane wrote:
> >> > "Erik Rijkers" writes:
> >> >> In a 112 MB test table (containing r
On Wed 15-01-14 12:16:50, Hannu Krosing wrote:
> On 01/14/2014 06:12 PM, Robert Haas wrote:
> > This would be pretty similar to copy-on-write, except
> > without the copying. It would just be
> > forget-from-the-buffer-pool-on-write.
>
> +1
>
> A version of this could probably already be impleme
2014/1/15 Marko Tiikkaja
> On 1/15/14 2:00 PM, Florian Pflug wrote:
>
>> On Jan15, 2014, at 13:32 , Marko Tiikkaja wrote:
>>
>>> On 1/15/14 1:23 PM, Florian Pflug wrote:
>>>
The fact that it's named plpgsql.warnings already clearly documents
that this only affects plpgsql. But whether
On Wed 15-01-14 10:27:26, Heikki Linnakangas wrote:
> On 01/15/2014 06:01 AM, Jim Nasby wrote:
> >For the sake of completeness... it's theoretically silly that Postgres
> >is doing all this stuff with WAL when the filesystem is doing something
> >very similar with it's journal. And an SSD drive (an
On Tue, Jan 14, 2014 at 09:54:20PM -0600, Jim Nasby wrote:
> On 1/14/14, 3:41 PM, Dave Chinner wrote:
> >On Tue, Jan 14, 2014 at 09:40:48AM -0500, Robert Haas wrote:
> >>On Mon, Jan 13, 2014 at 5:26 PM, Mel Gorman
> >>wrote: Whether the problem is with the system call or the
> >>programmer is hard
Hello,
Please tell me a bit about the following bug which has just been solved. I
wish this is exactly what has been annoying for a year.
Hot standby 9.2.6 -> 9.2.6 PANIC: WAL contains references to invalid pages
http://www.postgresql.org/message-id/CAL_0b1s4QCkFy_55kk_8XWcJPs7wsgVWf8vn4=jxe6
On 1/15/14 2:00 PM, Florian Pflug wrote:
On Jan15, 2014, at 13:32 , Marko Tiikkaja wrote:
On 1/15/14 1:23 PM, Florian Pflug wrote:
The fact that it's named plpgsql.warnings already clearly documents that this
only affects plpgsql. But whether a particular warning is emitted during
compilatio
Hmm, ok, this is slighly involved.
Is it important that you should do this at the execution time? At planner
level where Agg node is involved, one can look for Aggref node and traverse
down the args list to find any vars are involved in aggregation. You can
find Var nodes involved in an Aggref by
On Jan15, 2014, at 13:32 , Marko Tiikkaja wrote:
> On 1/15/14 1:23 PM, Florian Pflug wrote:
>> The fact that it's named plpgsql.warnings already clearly documents that
>> this only affects plpgsql. But whether a particular warning is emitted
>> during compilation or during execution it largely i
On Wed, Jan 15, 2014 at 3:20 AM, Simon Riggs wrote:
> We've discussed previously the negative impact of large bulk
> operations, especially wrt WAL writes. Patch here allows maintenance
> operations to have their WAL generation slowed down as a replication
> lag prevention feature.
>
> I believe
2014/1/15 Ashutosh Bapat
> Hi Cathleen,
> An aggregate can be working on more than one table e.g.
>
> select count(*) from a, b, c where a.c1 = b.c1 and b.c1 = c.c1;
>
> In such a case, which table would you like to be reported?
>
> IOW, it doesn't look to be sensible to attach and aggregate with
1 - 100 of 129 matches
Mail list logo
