On Thu, Apr 17, 2014 at 10:33 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Any objections to changing those two?
Not here. I've always suspected #2 was going to bite us someday anyway.
+1
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Nicolas Barbier wrote:
2014-04-17 Michael Paquier michael.paqu...@gmail.com:
Is there no equivalent in German? For example in French there is ssi.
gdw (genau dann, wenn)
Sorry, but I as a German native speaker and mathematitian have never
encountered this abbreviation. I am familiar with
Bruce Momjian wrote:
I suggest the attached documentation fix.
Patch applied and backpatched to 9.3. Thanks.
What would PostgreSQL do without Bruce who undertakes the
Herculean task of making sure that nothing gets forgotten
and slips through the cracks?
Thanks!
Yours,
Laurenz Albe
--
On Thu, Apr 17, 2014 at 04:14:55PM -0400, Tom Lane wrote:
Perhaps the #ifndef could be placed in a nicer spot in the patch, but the
attached should at least describe where the problem lies...
Yeah, I thought it better to make a separate declaration to wrap in
#ifndef. pgindent is probably
Hello,
I don't think we should consider changing long-established behavior in
the back-branches. The old behavior may not be ideal, but that
doesn't mean it's a bug.
Ok, I understand that. I give it up.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via
The attached improves a document in src/backend/access/gin/README.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/src/backend/access/gin/README b/src/backend/access/gin/README
index 3f0c3e2..8a71d28 100644
--- a/src/backend/access/gin/README
+++ b/src/backend/access/gin/README
@@ -181,7 +181,7
The attached improves a comment in gin_private.h a little bit.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/src/include/access/gin_private.h b/src/include/access/gin_private.h
index 81a3bee..3aa4276 100644
--- a/src/include/access/gin_private.h
+++ b/src/include/access/gin_private.h
@@
Hello,
I thought some more about this patch, and realized that it's more or less
morally equivalent to allowing references to ungrouped variables when the
query has a GROUP BY clause listing all the columns of the primary key.
In that case the parser is effectively pretending that the GROUP
Hi,
Attached fixes a minor typo in src/backend/access/transam/recovery.conf.sample.
--
Amit
recovery-conf-sample-typo-fix.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Fri, Apr 18, 2014 at 12:24 PM, Amit Langote amitlangot...@gmail.comwrote:
Hi,
Attached fixes a minor typo in
src/backend/access/transam/recovery.conf.sample.
Applied, except I also rewrapped the line to make it shorter. Thanks!
--
Magnus Hagander
Me: http://www.hagander.net/
Work:
On Fri, Apr 18, 2014 at 7:50 PM, Magnus Hagander mag...@hagander.net wrote:
On Fri, Apr 18, 2014 at 12:24 PM, Amit Langote amitlangot...@gmail.com
wrote:
Hi,
Attached fixes a minor typo in
src/backend/access/transam/recovery.conf.sample.
Applied, except I also rewrapped the line to make
On Fri, Apr 18, 2014 at 7:27 AM, Peter Geoghegan p...@heroku.com wrote:
A way I have in mind about eviction policy is to introduce a way to have an
ageing factor in each buffer and take the ageing factor into consideration
when evicting a buffer.
Consider a case where a table is pretty huge and
From: Amit Kapila amit.kapil...@gmail.com
Currently -e option is accepted with all the options that can be provided
in pg_ctl. Shouldn't we accept it only with options related to service,
because that is only when it will be used. Basically write_stderr() will
write to event log only incase of
From: Josh Berkus j...@agliodbs.com
How can we make beta testing better and more effective? How can we get
more users to actually throw serious workloads at new versions and share
the results?
I've tried a couple of things over the last two years and they haven't
worked all that well. Since
Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp writes:
Ok, I am convinced that your suggestion - truncating
query_pathkeys by removing eventually no-op entries - seems
preferable and will have wider effect naturally - more promised.
I won't persist with the way this patch currently does
On Thu, Apr 17, 2014 at 10:47 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-04-17 17:40:01 -0300, Alvaro Herrera wrote:
For once, this looks more like a problem in logical decoding, which is
trying to assert about the tuple being updated; the assertion failing is
the one added a week
Robert Haas wrote:
On Thu, Apr 17, 2014 at 10:47 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-04-17 17:40:01 -0300, Alvaro Herrera wrote:
For once, this looks more like a problem in logical decoding, which is
trying to assert about the tuple being updated; the assertion failing
On 2014-04-18 16:44:55 +0200, Robert Haas wrote:
On Thu, Apr 17, 2014 at 10:47 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-04-17 17:40:01 -0300, Alvaro Herrera wrote:
For once, this looks more like a problem in logical decoding, which is
trying to assert about the tuple being
On 4/17/14, 8:24 PM, Tom Lane wrote:
We could in fact implement #2, I imagine, by destroying and recreating
the entire language interpreter. So I could imagine implementing a
DISCARD INTERPRETERS kind of command that would zap the current
interpreter(s) for whichever PL languages happened to
On 4/17/14, 4:44 PM, Joshua D. Drake wrote:
That we should also release the GD?
In some cases, SD or GD are used to cache things. Having the connection
pooler blow that away would defeat the point.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Andres Freund wrote:
On 2014-04-18 11:50:55 -0300, Alvaro Herrera wrote:
It's a bit painful that HeapTupleHeaderGetUpdateXid allocates memory,
but to fix that we would have to remove all allocations from
GetMultiXactIdMembers which doesn't sound feasible.
I was thinking for a second we
On 2014-04-18 11:50:55 -0300, Alvaro Herrera wrote:
It's a bit painful that HeapTupleHeaderGetUpdateXid allocates memory,
but to fix that we would have to remove all allocations from
GetMultiXactIdMembers which doesn't sound feasible.
I was thinking for a second we could just allocate
Peter Eisentraut pete...@gmx.net writes:
On 4/17/14, 8:24 PM, Tom Lane wrote:
We could in fact implement #2, I imagine, by destroying and recreating
the entire language interpreter. So I could imagine implementing a
DISCARD INTERPRETERS kind of command that would zap the current
On Thu, Apr 17, 2014 at 5:00 PM, Greg Stark st...@mit.edu wrote:
On Thu, Apr 17, 2014 at 10:18 AM, Robert Haas robertmh...@gmail.com wrote:
Because all the usage counts are the same, the eviction at
this point is completely indiscriminate. We're just as likely to kick
out a btree root page or
MauMau wrote:
From: Josh Berkus j...@agliodbs.com
How can we make beta testing better and more effective? How can we get
more users to actually throw serious workloads at new versions and share
the results?
I've tried a couple of things over the last two years and they haven't
worked all
On Fri, Apr 18, 2014 at 4:14 PM, Robert Haas robertmh...@gmail.com wrote:
I am a bit confused by this remark. In *any* circumstance when you
evict you're incurring precisely one page fault I/O when the page is
read back in. That doesn't mean that the choice of which page to
evict is
On 04/17/2014 10:15 AM, Andrew Dunstan wrote:
On 04/16/2014 10:28 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 04/16/2014 07:19 PM, Tom Lane wrote:
Yeah, it would be real nice to see a self-contained test case for
this.
Well, that might be hard to put together, but I
On Fri, Apr 18, 2014 at 4:15 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
There was no reply, which I took as this isn't a
new feature and isn't user visible anyway, so what would be the point?
To be fair the list was pretty long already. And like regression
testing, coming up with a
On 04/18/2014 08:01 AM, Peter Eisentraut wrote:
On 4/17/14, 4:44 PM, Joshua D. Drake wrote:
That we should also release the GD?
In some cases, SD or GD are used to cache things. Having the connection
pooler blow that away would defeat the point.
Not on a per session basis. Although I can
On 04/18/2014 08:15 AM, Alvaro Herrera wrote:
and see whether it still works at all for you. I asked Josh
specifically to mention it in a followup to this message which you can
see in that thread. There was no reply, which I took as this isn't a
new feature and isn't user visible anyway, so
On 04/18/2014 09:42 AM, Andrew Dunstan wrote:
There definitely seems to be something going on involving these two
pre-loaded modules. With both auto_explain and pg_stat_statements
preloaded I can reproduce the error fairly reliably. I have also
reproduced it, but less reliably, with
On Fri, Apr 18, 2014 at 04:46:31PM +0530, Atri Sharma wrote:
This can be changed by introducing an ageing factor that sees how much time
the
current buffer has spend in shared buffers. If the time that the buffer has
spent is large enough (relatively) and it is not hot currently, that means
On Sat, Apr 19, 2014 at 1:07 AM, Bruce Momjian br...@momjian.us wrote:
On Fri, Apr 18, 2014 at 04:46:31PM +0530, Atri Sharma wrote:
This can be changed by introducing an ageing factor that sees how much
time the
current buffer has spend in shared buffers. If the time that the buffer
has
On Apr 18, 2014, at 1:51 PM, Atri Sharma atri.j...@gmail.com wrote:
Counting clock sweeps is an intersting idea. I think one concern was
tracking hot buffers in cases where there is no memory pressure, and
hence the clock sweep isn't running --- I am not sure how this would
help in that
Yes, we obviously want a virtual clock. Focusing on the use of gettimeofday
seems silly to me: it was something quick for the prototype.
The problem with the clocksweeps is they don’t actually track the
progression of “time” within the PostgreSQL system.
What’s wrong with using a transaction
On Fri, Apr 18, 2014 at 1:11 PM, Jason Petersen ja...@citusdata.com wrote:
Yes, we obviously want a virtual clock. Focusing on the use of gettimeofday
seems silly to me: it was something quick for the prototype.
The gettimeofday() call doesn't need to happen in a tight loop. It can
be
On Sat, Apr 19, 2014 at 01:21:29AM +0530, Atri Sharma wrote:
I feel that if there is no memory pressure, frankly it doesnt matter much
about
what gets out and what not. The case I am specifically targeting is when the
clocksweep gets to move about a lot i.e. high memory pressure workloads. Of
Noah Misch n...@leadboat.com writes:
Interesting bug.
On Fri, Mar 28, 2014 at 04:34:41PM -0400, Tom Lane wrote:
I think we might be better off to get rid of toast_flatten_tuple_attribute
and instead insist that composite Datums never contain any external toast
pointers in the first place.
38 matches
Mail list logo
