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
From: "David Johnston"
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 what is going o
From: "David Johnston"
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 a totally sepa
From: "Amit Kapila"
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
http://www.postgresql.org/message-id/503a879c.6070...@dunslan
From: "Michael Paquier"
On Sat, Dec 7, 2013 at 9:06 AM, MauMau 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 time?
Please feel free. I might as well partic
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:
http://www.postgresql.org/mailp
On Sat, Dec 7, 2013 at 12:27 AM, David Johnston 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 client d
MauMau wrote
> From: "David Johnston" <
> polobo@
> >
>>> 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
>> int
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 o
On Sat, Dec 7, 2013 at 3:56 PM, Andres Freund 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 without context if
On Sat, Dec 7, 2013 at 6:31 AM, Peter Geoghegan wrote:
> On Fri, Dec 6, 2013 at 12:24 PM, Tom Lane 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 ID, i.e., unsigned 32-b
* 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 giv
On Sun, Nov 17, 2013 at 1:15 PM, Peter Geoghegan wrote:
> On Sat, Nov 16, 2013 at 4:36 PM, Peter Geoghegan 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 lot of pressure with a
On Wed, Nov 20, 2013 at 3:18 AM, Atri Sharma wrote:
> On Tue, Nov 19, 2013 at 11:43 PM, Mike Blackwell
> 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. I don't
>> consider myself a code ex
Sent from my iPad
> On 07-Dec-2013, at 23:47, Fujii Masao wrote:
>
>> On Wed, Nov 20, 2013 at 3:18 AM, Atri Sharma wrote:
>>> On Tue, Nov 19, 2013 at 11:43 PM, Mike Blackwell
>>> wrote:
>>> This patch looks good to me. It applies, builds, and runs the regression
>>> tests. Documentation i
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 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 each of
> tho
On Tue, Dec 3, 2013 at 6:30 PM, Greg Stark 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 shocked but th
On Fri, Dec 6, 2013 at 5:02 AM, Etsuro Fujita
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 (peak) memory
> space
On Fri, Dec 6, 2013 at 8:12 AM, Andres Freund wrote:
> On 2013-12-05 14:07:39 -0500, Robert Haas wrote:
>> On Thu, Dec 5, 2013 at 8:29 AM, Andres Freund wrote:
>> > Hm. The API change of on_shmem_exit() is going to cause a fair bit of
>> > pain. There are a fair number of extensions out there usi
On 7 December 2013 19:41, Tom Lane wrote:
> Thom Brown 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 determ
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 anot
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 gen
Andrew Gierth writes:
> "Tom" == Tom Lane 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 this more closely, ISTM that the dire
Thom Brown 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. What I was
>
On 7 December 2013 20:44, Tom Lane wrote:
> Thom Brown 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 think that would be reaso
On Sat, Dec 7, 2013 at 8:25 PM, Josh Berkus 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% sample is going t
> "Tom" == Tom Lane 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 examining the
T
Hello
thank you for review
2013/12/7 Steve Singer
> 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 ne
Andrew Gierth writes:
> "Tom" == Tom Lane 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_argument
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 U
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 size
> "Tom" == Tom Lane 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> chan
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 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 b/contrib/pg_stat_statements/pg_stat_statements.c
new fi
* 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 b
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 tha
-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 abo
On Sat, Dec 7, 2013 at 11:07 PM, Joe Conway 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 part of
On Sun, Dec 8, 2013 at 10:16 AM, Fabrízio de Royes Mello
wrote:
>
>
>
> On Sat, Dec 7, 2013 at 11:07 PM, Joe Conway 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 t
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:
http://ww
On Sat, Dec 7, 2013 at 11:20 PM, Michael Paquier
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 we can just crea
-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
> mailto:michael.paqu...@gmail.com>>
> wrote:
>>>
>>> IMHO is more elegant create a procedure to encapsulate the code
>>> to avoid redundancy
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, perha
> On 2013/12/08, at 10:50, Joe Conway 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
>> mailto:michael.paqu...@gmail.com>>
>> wrote:
IMHO is more elegant c
On 08/12/13 10:27, Greg Stark wrote:
On Sat, Dec 7, 2013 at 8:25 PM, Josh Berkus 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
From: "MauMau"
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 users.
I've done a
On Sat, Dec 7, 2013 at 6:02 PM, MauMau wrote:
> From: "Amit Kapila"
>
>> 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 li
On Fri, Dec 6, 2013 at 10:31 AM, Peter Eisentraut 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 administrator.
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 accel
52 matches
Mail list logo
