On Wed, 2013-12-04 at 14:54 -0500, Tom Lane wrote:
I think Stephen has already argued why it could be a good idea here.
But in a nutshell: it seems like there are two use-cases to be
supported, one where you want CREATE EXTENSION hstore to give you
some appropriate version of hstore, and one
From: David Johnston pol...@yahoo.com
5. FATAL: terminating walreceiver process due to administrator command
6. FATAL: terminating background worker \%s\ due to administrator
command
5 and 6: I don't fully understand when they would happen but likely fall
into the same the DBA should know
From: David Johnston pol...@yahoo.com
PITR/Failover is not generally that frequent an occurrence but I will
agree
that these events are likely common during such.
Maybe PITR/Failover mode can output something in the logs to alleviate
user
angst about these frequent events? I'm doubting that
From: Amit Kapila amit.kapil...@gmail.com
Today, I had again gone through all the discussion that happened at
that time related to this problem
and I found that later in discussion it was discussed something on
lines as your Approach-2,
please see the link
From: Michael Paquier michael.paqu...@gmail.com
On Sat, Dec 7, 2013 at 9:06 AM, MauMau maumau...@gmail.com wrote:
Recovery target 'immediate'
http://www.postgresql.org/message-id/51703751.2020...@vmware.com
May I implement this feature and submit a patch for the next commitfest
if I have
Committed your v2 patch (with default to on). I added a small snippet
of documentation explaining that this setting is mainly for backward
compatibility.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Sat, Dec 7, 2013 at 12:27 AM, David Johnston pol...@yahoo.com wrote:
1. FATAL: the database system is starting up
How about altering the message to tone down the severity by a half-step...
FATAL: (probably) not! - the database system is starting up
Well it is fatal, the backend for that
MauMau wrote
From: David Johnston lt;
polobo@
gt;
5. FATAL: terminating walreceiver process due to administrator command
6. FATAL: terminating background worker \%s\ due to administrator
command
5 and 6: I don't fully understand when they would happen but likely fall
into the same the
On 2013-12-07 13:58:11 +, Greg Stark wrote:
FATAL means a backend died. It is kind of vague how FATAL and PANIC
differ.
I don't really see much vagueness there. FATAL is an unexpected but
orderly shutdown. PANIC is for the situations where we can't handle the
problem that occurred in any
On Sat, Dec 7, 2013 at 3:56 PM, Andres Freund and...@2ndquadrant.com wrote:
I don't really see much vagueness there. FATAL is an unexpected but
orderly shutdown. PANIC is for the situations where we can't handle the
problem that occurred in any orderly way.
Sorry, I was unclear. I meant that
On Sat, Dec 7, 2013 at 6:31 AM, Peter Geoghegan p...@heroku.com wrote:
On Fri, Dec 6, 2013 at 12:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There seems to be no problem even if we use bigint as the type of
unsigned 32-bit integer like queryid. For example, txid_current()
returns the transaction
* Jeff Davis (pg...@j-davis.com) wrote:
On Wed, 2013-12-04 at 14:54 -0500, Tom Lane wrote:
I think Stephen has already argued why it could be a good idea here.
But in a nutshell: it seems like there are two use-cases to be
supported, one where you want CREATE EXTENSION hstore to give you
On Sun, Nov 17, 2013 at 1:15 PM, Peter Geoghegan p...@heroku.com wrote:
On Sat, Nov 16, 2013 at 4:36 PM, Peter Geoghegan p...@heroku.com wrote:
I'll post a revision with fixes for those. Another concern is that I
see some race conditions that only occur when pg_stat_statements cache
is under a
On Wed, Nov 20, 2013 at 3:18 AM, Atri Sharma atri.j...@gmail.com wrote:
On Tue, Nov 19, 2013 at 11:43 PM, Mike Blackwell mike.blackw...@rrd.com
wrote:
This patch looks good to me. It applies, builds, and runs the regression
tests. Documentation is included and it seems to do what it says.
Sent from my iPad
On 07-Dec-2013, at 23:47, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Nov 20, 2013 at 3:18 AM, Atri Sharma atri.j...@gmail.com wrote:
On Tue, Nov 19, 2013 at 11:43 PM, Mike Blackwell mike.blackw...@rrd.com
wrote:
This patch looks good to me. It applies, builds,
Hi,
I was wondering whether anyone has any insight with regards to
measuring and reporting the overhead of maintaining indexes on
relations. If an UPDATE is issued to a table with, say, 6 indexes, it
would be useful to determine how much time is spent updating each of
those indexes. And perhaps
Thom Brown t...@linux.com writes:
I was wondering whether anyone has any insight with regards to
measuring and reporting the overhead of maintaining indexes on
relations. If an UPDATE is issued to a table with, say, 6 indexes, it
would be useful to determine how much time is spent updating
On Tue, Dec 3, 2013 at 6:30 PM, Greg Stark st...@mit.edu wrote:
I always gave the party line that ANALYZE only takes a small
constant-sized sample so even very large tables should be very quick.
But after hearing the same story again in Heroku I looked into it a
bit further. I was kind of
On Fri, Dec 6, 2013 at 5:02 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Though at first I agreed on this, while working on this I start to think
information about (2) is enough for tuning work_mem. Here are examples using
a version under development, where Bitmap Memory Usage means
On Fri, Dec 6, 2013 at 8:12 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-12-05 14:07:39 -0500, Robert Haas wrote:
On Thu, Dec 5, 2013 at 8:29 AM, Andres Freund and...@2ndquadrant.com wrote:
Hm. The API change of on_shmem_exit() is going to cause a fair bit of
pain. There are a
On 7 December 2013 19:41, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown t...@linux.com writes:
I was wondering whether anyone has any insight with regards to
measuring and reporting the overhead of maintaining indexes on
relations. If an UPDATE is issued to a table with, say, 6 indexes, it
On Thu, 2013-11-07 at 01:59 +0200, Marko Kreen wrote:
This sets up ECDH key exchange, when compiling against OpenSSL
that supports EC. Then ECDHE-RSA and ECDHE-ECDSA ciphersuites
can be used for SSL connections. Latter one means that EC keys
are now usable.
Committed v2.
--
Sent via
On 08/22/2013 02:02 AM, Pavel Stehule wrote:
rebased
Regards
Pavel
This patch again needs a rebase, it no longer applies cleanly.
plpgsql_estate_setup now takes a shared estate parameter and the call in
pl_check needs that. I passed NULL in and things seem to work.
I think this is
On 12/07/2013 11:46 AM, Robert Haas wrote:
Maybe there's some highly-principled statistical approach which could
be taken here, and if so that's fine, but I suspect not. So what I
think we should do is auto-tune the statistics target based on the
table size. If, say, we think that the
Andrew Gierth and...@tao11.riddles.org.uk writes:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I believe that the spec requires that the direct arguments of
Tom an inverse or hypothetical-set aggregate must not contain any
Tom Vars of the current query level.
False.
After examining
Thom Brown t...@linux.com writes:
Perhaps I may have misunderstood, or not explained my question with
enough detail, but you appear to be including activity that would, in
all likelihood, occur after the DML has returned confirmation to the
user that it has completed; in particular, VACUUM.
On 7 December 2013 20:44, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown t...@linux.com writes:
So in essence, I'd only be looking for a breakdown of anything that
adds to the duration of the DML statement. However, it sounds like
even that isn't straightforward from what you've written.
I
On Sat, Dec 7, 2013 at 8:25 PM, Josh Berkus j...@agliodbs.com wrote:
The only approach which makes sense is to base it on a % of the table.
In fact, pretty much every paper which has examined statistics
estimation for database tables has determined that any estimate based on
a less-than-5%
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom After examining this more closely, ISTM that the direct
Tom arguments are supposed to be processed as if they weren't inside
Tom an aggregate call at all. That being the case, isn't it flat
Tom out wrong for check_agg_arguments() to be
Hello
thank you for review
2013/12/7 Steve Singer st...@ssinger.info
On 08/22/2013 02:02 AM, Pavel Stehule wrote:
rebased
Regards
Pavel
This patch again needs a rebase, it no longer applies cleanly.
plpgsql_estate_setup now takes a shared estate parameter and the call in
pl_check
Andrew Gierth and...@tao11.riddles.org.uk writes:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom After examining this more closely, ISTM that the direct
Tom arguments are supposed to be processed as if they weren't inside
Tom an aggregate call at all. That being the case, isn't it flat
On Sat, 2013-12-07 at 12:27 -0500, Stephen Frost wrote:
* Jeff Davis (pg...@j-davis.com) wrote:
The behavior of an extension should not depend on how it was installed.
The kind of extension being described by Stephen will:
* Not be updatable by doing ALTER EXTENSION foo UPDATE TO
On 08/12/13 09:25, Josh Berkus wrote:
On 12/07/2013 11:46 AM, Robert Haas wrote:
Maybe there's some highly-principled statistical approach which could
be taken here, and if so that's fine, but I suspect not. So what I
think we should do is auto-tune the statistics target based on the
table
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Hmm... yes, you're probably right; but we'd still have to check
somewhere for improper nesting, no? since not even the direct args
are allowed to contain nested aggregate calls.
Tom Yeah, I had come to that same conclusion while making the
Tom
On Sun, 2013-12-08 at 02:08 +0900, Fujii Masao wrote:
Attached revision displays signed 64-bit integers instead.
Thanks! Looks good to me. Committed!
32-bit buildfarm members are having problems with this patch.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Sat, Dec 7, 2013 at 3:50 PM, Peter Eisentraut pete...@gmx.net wrote:
32-bit buildfarm members are having problems with this patch.
This should fix that problem. Thanks.
--
Peter Geoghegan
diff --git a/contrib/pg_stat_statements/pg_stat_statements.c
* Jeff Davis (pg...@j-davis.com) wrote:
I understand there are reasons, but I'm having a hard time getting past
the idea that I have extension foo v1.2 now needs to be qualified with
installed using SQL or installed using the filesystem to know what
you actually have and how it will behave.
I
On 08/12/13 12:27, Mark Kirkwood wrote:
On 08/12/13 09:25, Josh Berkus wrote:
On 12/07/2013 11:46 AM, Robert Haas wrote:
Maybe there's some highly-principled statistical approach which could
be taken here, and if so that's fine, but I suspect not. So what I
think we should do is auto-tune the
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
aware of 'z' flags for this to work.
It just checks that the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/05/2013 07:05 PM, Joe Conway wrote:
On 12/05/2013 06:53 PM, Tom Lane wrote:
I seem to remember that at some point we realized that the
encoding ID assignments are part of libpq's ABI and so can't
practically be changed ever, so the above may
On Sat, Dec 7, 2013 at 11:07 PM, Joe Conway m...@joeconway.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/05/2013 07:05 PM, Joe Conway wrote:
On 12/05/2013 06:53 PM, Tom Lane wrote:
I seem to remember that at some point we realized that the
encoding ID assignments are
On Sun, Dec 8, 2013 at 10:16 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Sat, Dec 7, 2013 at 11:07 PM, Joe Conway m...@joeconway.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/05/2013 07:05 PM, Joe Conway wrote:
On 12/05/2013 06:53 PM, Tom Lane wrote:
All,
I tested out Joe's original patch, and it does eliminate the 8%
performance regression.
Will try the new one.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Sat, Dec 7, 2013 at 11:20 PM, Michael Paquier michael.paqu...@gmail.com
wrote:
IMHO is more elegant create a procedure to encapsulate the code to avoid
redundancy.
Yep, perhaps something like PQsetClientEncodingIfDifferent or similar
would make sense.
Well I think at this first moment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/07/2013 05:41 PM, Fabrízio de Royes Mello wrote:
On Sat, Dec 7, 2013 at 11:20 PM, Michael Paquier
michael.paqu...@gmail.com mailto:michael.paqu...@gmail.com
wrote:
IMHO is more elegant create a procedure to encapsulate the code
to
On Sat, Dec 7, 2013 at 11:41 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Sat, Dec 7, 2013 at 11:20 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
IMHO is more elegant create a procedure to encapsulate the code to
avoid
redundancy.
Yep, perhaps something like
On 2013/12/08, at 10:50, Joe Conway m...@joeconway.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/07/2013 05:41 PM, Fabrízio de Royes Mello wrote:
On Sat, Dec 7, 2013 at 11:20 PM, Michael Paquier
michael.paqu...@gmail.com mailto:michael.paqu...@gmail.com
wrote:
On 08/12/13 10:27, Greg Stark wrote:
On Sat, Dec 7, 2013 at 8:25 PM, Josh Berkus j...@agliodbs.com wrote:
The only approach which makes sense is to base it on a % of the table.
In fact, pretty much every paper which has examined statistics
estimation for database tables has determined that any
From: MauMau maumau...@gmail.com
I've removed a limitation regarding event log on Windows with the attached
patch. I hesitate to admit this is a bug fix and want to regard this an
improvement, but maybe it's a bug fix from users' perspective. Actually,
I
received problem reports from some
On Sat, Dec 7, 2013 at 6:02 PM, MauMau maumau...@gmail.com wrote:
From: Amit Kapila amit.kapil...@gmail.com
Today, I had again gone through all the discussion that happened at
that time related to this problem
and I found that later in discussion it was discussed something on
lines as your
On Fri, Dec 6, 2013 at 10:31 AM, Peter Eisentraut pete...@gmx.net wrote:
On Wed, 2013-11-20 at 11:23 -0500, Christopher Browne wrote:
I note that similar (with not quite identical behaviour) issues apply
to the user name. Perhaps the
resolution to this is to leave quoting issues to the
I know that all invalid cache messages are stored in the
shmInvalidationBuffer ring buffer and that they should be consumed by all
other backends to keep their own cache fresh. Since there may be some
stragglers which process the SI message quite slow, we use *catchup*
interrupt(signal) to
52 matches
Mail list logo
