On 01/26/2013 12:38 AM, Craig Ringer wrote:
On 01/25/2013 08:25 PM, Noah Misch wrote:
That should be clearer, that 64-bit support exists but is absent (AFAIK)
from Express editions.
Build farm member "chough" builds 64-bit using VS 2008 Express.
Huh. My 2008 doesn't appear to have 64-bit comp
On Friday, January 25, 2013 8:36 PM Bruce Momjian wrote:
> On Fri, Sep 14, 2012 at 02:04:51PM +, Amit kapila wrote:
> > On Thu, 6 Sep 2012 14:50:05 -0400 Robert Hass wrote:
> >
> > On Tue, Aug 28, 2012 at 6:40 AM, Amit Kapila
> > com> wrote:
> > >> AFAICT during Update also, it doesn't conta
On 01/25/2013 08:25 PM, Noah Misch wrote:
>> That should be clearer, that 64-bit support exists but is absent (AFAIK)
>> from Express editions.
> Build farm member "chough" builds 64-bit using VS 2008 Express.
Huh. My 2008 doesn't appear to have 64-bit compilers or cross-compilers
and didn't offer
On Fri, Jan 25, 2013 at 11:08:56PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > ! ereport(ERROR,
> > !
> > (ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE,
> > ! errmsg("cannot perform FR
On 01/24/2013 01:13 PM, Craig Ringer wrote:
> On 01/24/2013 11:28 AM, Craig Ringer wrote:
>> On 01/24/2013 09:38 AM, Noah Misch wrote:
>>> The most notable difference is that I have no pre-VS2012 Microsoft
>>> compilers installed and no SDKs installed by my explicit action. I
>>> suggest assessing
Bruce Momjian writes:
> ! ereport(ERROR,
> !
> (ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE,
> ! errmsg("cannot perform FREEZE
> because of previous table activity in the current tran
On Fri, Jan 25, 2013 at 05:30:58PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > OK, updated patch attached that throws an error with a more specific
> > message.
>
>
> > *
> > * As noted above rd_newRelfilenodeSubid is not set in all cases
> > * where
Hello Tom
you did comment
! <><--><--> * Non-null argument had better be an array.
The parser doesn't
! <><--><--> * enforce this for VARIADIC ANY functions
(maybe it should?), so
! <><--><--> * that check uses ereport not just elog.
! <><--><--> */
Pavel Stehule writes:
> [ gset_13.diff ]
I looked at this a bit. I think you need to reconsider when and how the
\gset state gets cleaned up. Doing it inside StoreQueryResult is not
very good because that only gets reached upon successful execution.
Consider for example
select 1/0 \gse
On Fri, 2013-01-25 at 15:29 -0500, Robert Haas wrote:
> I thought Simon had the idea, at some stage, of writing a WAL record
> to cover hint-bit changes only at the time we *write* the buffer and
> only if no FPI had already been emitted that checkpoint cycle. I'm
> not sure whether that approach
On Fri, Jan 25, 2013 at 05:10:14PM -0500, Peter Eisentraut wrote:
> On 1/25/13 1:59 PM, Bruce Momjian wrote:
> > On Fri, Jan 25, 2013 at 01:46:46PM -0500, Peter Eisentraut wrote:
> >> This matter was already closed:
> >> https://commitfest.postgresql.org/action/patch_view?id=949
> >>
> >> It looks
Bernd Helmle writes:
> So i've saved the index file (normal BTree index with a single bigint
> column), did a REINDEX and the problem was gone. Looking at the index file
> with pg_filedump and pgbtreecheck from Alvaro gave me the following output:
> ...
Don't know how careful pgbtreecheck is.
On Sat, Jan 26, 2013 at 2:42 AM, Robert Haas wrote:
> On Fri, Jan 25, 2013 at 11:59 AM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
> >>> FWIW, and I won't annoy anyone further after this email, now that its
> >>> deterministic,
David Fetter writes:
> Please find attached a patch which implements approach 3. The vast
> majority of it is changes to the regression tests. The removed
> regression tests in join.{sql,out} are no longer errors, although some
> of them are pretty standard DoS attacks, hence they're all removed
> On Fri, Jan 25, 2013 at 03:24:27PM -0500, Robert Haas wrote:
>> On Fri, Jan 25, 2013 at 2:33 PM, Bruce Momjian wrote:
>> > On Fri, Jan 25, 2013 at 02:02:39PM -0500, Robert Haas wrote:
>> >> On Fri, Jan 25, 2013 at 1:28 PM, Bruce Momjian wrote:
>> >> > On Mon, Oct 1, 2012 at 02:04:00PM +0900, T
On Fri, Jan 25, 2013 at 9:38 AM, Francois Tigeot wrote:
>> On Fri, Jan 25, 2013 at 8:40 AM, Bruce Momjian
>> wrote:
>>>
>>> Just a reminder we might have *BSD performance issues with our use
>>> of Posix shared memory in Postgres 9.3. I am attaching the PDF the
>>> user posted.
>>
>> This is a g
Bruce Momjian writes:
> OK, updated patch attached that throws an error with a more specific
> message.
>*
>* As noted above rd_newRelfilenodeSubid is not set in all cases
>* where we can apply the optimization, so in those rare cases
> !
On Mon, Oct 15, 2012 at 12:06:27AM +0100, Greg Stark wrote:
> On Sat, Oct 13, 2012 at 3:13 AM, Stephen Frost wrote:
> > Josh's concern is about autovacuum causing lots of stats churn, which is
> > understandable, we don't want it constantly rescanning a table
>
> I don't think rescanning the tabl
On 1/25/13 1:59 PM, Bruce Momjian wrote:
> On Fri, Jan 25, 2013 at 01:46:46PM -0500, Peter Eisentraut wrote:
>> This matter was already closed:
>> https://commitfest.postgresql.org/action/patch_view?id=949
>>
>> It looks like your patch reverts part of that.
>
> Uh, I am confused because the patch
On Fri, Jan 25, 2013 at 04:55:48PM -0500, Peter Eisentraut wrote:
> On 1/24/13 6:25 PM, Bruce Momjian wrote:
> > On Thu, Aug 30, 2012 at 07:59:02PM -0700, Joe Conway wrote:
> >> On 08/30/2012 07:23 PM, Bruce Momjian wrote:
> >>> On Thu, Jul 12, 2012 at 06:01:00PM -0700, Joe Conway wrote:
> I'l
On Fri, Oct 12, 2012 at 04:42:46PM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Fri, Oct 12, 2012 at 03:57:15PM -0400, Stephen Frost wrote:
> > > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > > There was also some discussion of fixing the name-check to be indexable,
On 1/24/13 6:25 PM, Bruce Momjian wrote:
> On Thu, Aug 30, 2012 at 07:59:02PM -0700, Joe Conway wrote:
>> On 08/30/2012 07:23 PM, Bruce Momjian wrote:
>>> On Thu, Jul 12, 2012 at 06:01:00PM -0700, Joe Conway wrote:
I'll take a look at the latter option sometime in the next few weeks and
s
On Sat, Oct 20, 2012 at 12:27:16PM +0100, Simon Riggs wrote:
> On 20 October 2012 07:43, Abhijit Menon-Sen wrote:
> > At 2012-10-15 10:28:17 -0400, robertmh...@gmail.com wrote:
> >>
> >> > Is there any concise description that applies? […]
> >>
> >> I don't think there is. I think we need to repl
Jeff Janes writes:
> A hashed SubPlan will not be used if it would need more than one
> batch. Is there a fundamental reason for that, or just that no one
> got around to adding it?
It can't, really. Batching a hash join requires freedom to reorder the
rows on both sides of the join. A SubPlan
On Thu, Oct 11, 2012 at 07:06:15PM -0400, Tom Lane wrote:
> Markus Wanner writes:
> > On 10/11/2012 03:11 PM, Tom Lane wrote:
> >> The original design intention was that rm_desc should not attempt to
> >> print any such data, but obviously some folks didn't get the word.
>
> > FWIW: in case the s
On 1/25/13 12:24 PM, Andres Freund wrote:
> On 2013-01-26 02:21:00 +0900, Fujii Masao wrote:
>> The process which deletes the old WAL files is the checkpointer. The
>> checkpointer can access to the shared memory and know the location
>> of the WAL record which has been already replicated to the st
On Wed, Oct 10, 2012 at 11:49:50AM -0700, Josh Berkus wrote:
>
> >> Assuming that's how 9.2 ships, we might as well wait to see if there
> >> are any real complaints from the field before we decide whether any
> >> changing is needed.
>
> So, here's a complaint: 9.2 is breaking our code for check
FYI, the FET timezone abbeviation was added in this commit:
http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=7127293a5d9f655ce3ec7e009f18bac8d3d0bc1c
---
On Sat, Oct 6, 2012 at 11:15:49AM +0200, M
2013/1/15 Peter Eisentraut :
> On Tue, 2012-10-09 at 20:45 -0400, Peter Eisentraut wrote:
>> About that plugins directory ($libdir/plugins) ... I don't think we
>> ever
>> really got that to work sensibly. I don't remember the original
>> design
>> discussion, but I have seen a number of explanati
A hashed SubPlan will not be used if it would need more than one
batch. Is there a fundamental reason for that, or just that no one
got around to adding it?
A small decrease in work_mem leads to a 38000 fold change in estimated
query execution (and that might be accurate, as the actual change in
On Fri, Jan 25, 2013 at 03:35:59PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> >> diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
> >> index 6b202e0..0677059 100644
> >> --- a/src/backend/utils/misc/guc.c
> >> +++ b/src/backend/utils/misc/guc.c
> >> @@ -5150,7 +5150,7
Bruce Momjian writes:
>> diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
>> index 6b202e0..0677059 100644
>> --- a/src/backend/utils/misc/guc.c
>> +++ b/src/backend/utils/misc/guc.c
>> @@ -5150,7 +5150,7 @@ set_config_option(const char *name, const char *value,
>> elevel =
On Fri, Jan 25, 2013 at 03:29:17PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Oops, thanks. Here is the right paragraph, same issue:
>
> > If successfully created, a named portal object lasts till the end of the
> > current transaction, unless explicitly destroyed. An unnamed po
On Thu, Jan 10, 2013 at 1:06 AM, Jeff Davis wrote:
> On Tue, 2012-12-04 at 01:03 -0800, Jeff Davis wrote:
>> For now, I rebased the patches against master, and did some very minor
>> cleanup.
>
> I think there is a problem here when setting PD_ALL_VISIBLE. I thought I
> had analyzed that before, b
Bruce Momjian writes:
> Oops, thanks. Here is the right paragraph, same issue:
> If successfully created, a named portal object lasts till the end of the
> current transaction, unless explicitly destroyed. An unnamed portal is
> destroyed at the end of the transaction, or as soon as
On Fri, Jan 25, 2013 at 03:24:27PM -0500, Robert Haas wrote:
> On Fri, Jan 25, 2013 at 2:33 PM, Bruce Momjian wrote:
> > On Fri, Jan 25, 2013 at 02:02:39PM -0500, Robert Haas wrote:
> >> On Fri, Jan 25, 2013 at 1:28 PM, Bruce Momjian wrote:
> >> > On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> SELECT ... FROM a WHERE a.x IN (SELECT ... FROM b, srf(y) WHERE ...)
> Actually, this appears to fail already, at least in 9.2.2:
> => select * from (values (1)) v(a) where v.a in (select x from (values (2))
> v2(a),
> ->
On Fri, Jan 25, 2013 at 2:33 PM, Bruce Momjian wrote:
> On Fri, Jan 25, 2013 at 02:02:39PM -0500, Robert Haas wrote:
>> On Fri, Jan 25, 2013 at 1:28 PM, Bruce Momjian wrote:
>> > On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote:
>> >> > Tatsuo Ishii writes:
>> >> >> From the manual:
On Fri, Jan 25, 2013 at 11:55:12AM -0800, Jeff Janes wrote:
> On Fri, Jan 25, 2013 at 9:42 AM, Robert Haas wrote:
> > On Fri, Jan 25, 2013 at 11:59 AM, Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
> FWIW, and I won't annoy a
On 01/25/2013 12:35:49 PM, Tom Lane wrote:
> Bruce Momjian writes:
> > I have applied a modified version of your patch that creates
> separate
> > secondary index references for search_path.
>
> This patch seems pretty bizarre. What is the difference between a
> "configuration parameter" and a "
2013/1/20 Tom Lane :
> Robert Haas writes:
>> Yeah. We'd need to think a little bit about how to make this work,
>> since I think that adding a gajillion booleans to pg_authid will not
>> make anyone very happy. But I like the idea. GRANT
>> kill_sessions_of_other_users TO bob? GRANT install_u
On Fri, Jan 25, 2013 at 9:42 AM, Robert Haas wrote:
> On Fri, Jan 25, 2013 at 11:59 AM, Tom Lane wrote:
>> Bruce Momjian writes:
>>> On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
FWIW, and I won't annoy anyone further after this email, now that its
deterministic, I sti
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> SELECT ... FROM a WHERE a.x IN (SELECT ... FROM b, srf(y) WHERE ...)
Actually, this appears to fail already, at least in 9.2.2:
=> select * from (values (1)) v(a) where v.a in (select x from (values (2))
v2(a),
-> generate_series(1,a)
On Sat, Oct 6, 2012 at 02:20:53PM -0700, Selena Deckelmann wrote:
> On Mon, Oct 1, 2012 at 2:28 PM, Selena Deckelmann wrote:
> > On Mon, Oct 1, 2012 at 1:37 PM, Selena Deckelmann
> > wrote:
> >> On Mon, Oct 1, 2012 at 1:00 PM, Tom Lane wrote:
> >>> Selena Deckelmann writes:
> The check_t
On Fri, Jan 25, 2013 at 02:02:39PM -0500, Robert Haas wrote:
> On Fri, Jan 25, 2013 at 1:28 PM, Bruce Momjian wrote:
> > On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote:
> >> > Tatsuo Ishii writes:
> >> >> From the manual:
> >> >> "An unnamed portal is destroyed at the end of the tra
On Fri, Jan 25, 2013 at 1:17 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 25, 2013 at 12:35 PM, Andres Freund
>> wrote:
>>> I don't think the first part is problematic. Which scenario do you have
>>> in mind where that would really cause adverse behaviour? autovacuum
>>> seldomly do
On Fri, Jan 25, 2013 at 1:28 PM, Bruce Momjian wrote:
> On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote:
>> > Tatsuo Ishii writes:
>> >> From the manual:
>> >> "An unnamed portal is destroyed at the end of the transaction"
>> >
>> > Actually, all portals are destroyed at end of trans
On Fri, Jan 25, 2013 at 01:46:46PM -0500, Peter Eisentraut wrote:
> On 1/25/13 12:50 PM, Bruce Momjian wrote:
> > On Fri, Sep 28, 2012 at 12:40:38PM -0500, Karl O. Pinc wrote:
> >> Hi,
> >>
> >> The attached patch (against git head)
> >> normalizes "search_path" as the thing indexed
> >> and uses a
On 1/12/13 3:30 PM, Aaron W. Swenson wrote:
> The Linux Standard Base Core Specification 3.1 says this should return
> '3'. [1]
>
> [1]
> http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
The LSB spec doesn't say anything about a "promote" action.
An
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> However ... David is wrong to claim that it's zero-risk. It's true that
> an SRF can't contain any side-references today, but it can contain an
> outer reference. Consider a case like
>
> SELECT ... FROM a WHERE a.x IN (SELECT ... FROM b, srf(y) WHERE ...
On 1/25/13 12:50 PM, Bruce Momjian wrote:
> On Fri, Sep 28, 2012 at 12:40:38PM -0500, Karl O. Pinc wrote:
>> Hi,
>>
>> The attached patch (against git head)
>> normalizes "search_path" as the thing indexed
>> and uses a secondary index term to distinguish
>> the configuration parameter from the run
On Fri, Jan 25, 2013 at 01:42:48PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, Jan 25, 2013 at 01:35:49PM -0500, Tom Lane wrote:
> >> This patch seems pretty bizarre. What is the difference between a
> >> "configuration parameter" and a "run-time setting"? Why would you
> >> point
Bruce Momjian writes:
> On Fri, Jan 25, 2013 at 01:35:49PM -0500, Tom Lane wrote:
>> This patch seems pretty bizarre. What is the difference between a
>> "configuration parameter" and a "run-time setting"? Why would you
>> point people to two different places for those two terms?
> Should I mak
On Fri, Jan 25, 2013 at 01:35:49PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I have applied a modified version of your patch that creates separate
> > secondary index references for search_path.
>
> This patch seems pretty bizarre. What is the difference between a
> "configuration param
Don't think the attachment made it in the last mail. Attaching now.
On 25 January 2013 18:33, Dhruv Ahuja wrote:
> May I propose the attached patch.
>
> Points to note and possibly discuss:
> (a) Only exit codes in do_* functions have been changed.
> (b) The link to, and the version of, LSB spe
Bruce Momjian writes:
> I have applied a modified version of your patch that creates separate
> secondary index references for search_path.
This patch seems pretty bizarre. What is the difference between a
"configuration parameter" and a "run-time setting"? Why would you
point people to two dif
May I propose the attached patch.
Points to note and possibly discuss:
(a) Only exit codes in do_* functions have been changed.
(b) The link to, and the version of, LSB specifications has been updated.
(c) A significant change is the exit code of do_stop() on stopping a
stopped server. Previous re
Stephen Frost writes:
> * David Fetter (da...@fetter.org) wrote:
>> 3. Make all cases of SRFs in the FROM-clause implicitly LATERAL.
>>
>> (As far as I can tell, those cases whose behaviour would be changed by
>> this actually produce errors in versions prior to 9.3, so no working
>> code should
On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote:
> > Tatsuo Ishii writes:
> >> From the manual:
> >> "An unnamed portal is destroyed at the end of the transaction"
> >
> > Actually, all portals are destroyed at end of transaction (unless
> > they're from holdable cursors). Named or
Robert Haas writes:
> On Fri, Jan 25, 2013 at 12:35 PM, Andres Freund
> wrote:
>> I don't think the first part is problematic. Which scenario do you have
>> in mind where that would really cause adverse behaviour? autovacuum
>> seldomly does full table vacuums on tables otherwise these days so
>
* David Fetter (da...@fetter.org) wrote:
> As I see it, the current options are:
>
> 1. Do nothing, and insist on non-standard use of the LATERAL keyword.
I'm not a big fan of this. Providing a good error message saying "you
need to use LATERAL for this query to work" makes it slightly better,
b
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 25, 2013 at 11:59 AM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
> >>> FWIW, and I won't annoy anyone further after this email, now that its
> >>> deterministic, I still t
On Fri, Jan 25, 2013 at 11:58 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> OK, but can we lay the issue of a *normalized* command string to the
>> side for just one minute, and talk about exposing the *raw* command
>> string? It seems to me that this would be (1) very easy to do, (2)
>>
On Fri, Jan 25, 2013 at 12:35 PM, Andres Freund wrote:
>> I think that to do this right, we need to consider not only the status
>> quo but the trajectory. For example, suppose we have two tables to
>> process, one of which needs a wraparound vacuum and the other one of
>> which needs dead tuples
On 2013-01-25 12:52:46 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I think if we backpatch this we should only prefer wraparound tables and
> > leave the rest unchanged.
>
> That's not a realistic option, at least not with anything that uses this
> approach to sorting the tables. You'd ha
On Fri, Jan 25, 2013 at 12:00 PM, Andres Freund wrote:
> On 2013-01-25 11:51:33 -0500, Tom Lane wrote:
>> Alvaro Herrera writes:
>> > 2. for other tables, consider floor(log(size)). This makes tables of
>> > sizes in the same ballpark be considered together.
>>
>> > 3. For tables of similar size
Andres Freund writes:
> I think if we backpatch this we should only prefer wraparound tables and
> leave the rest unchanged.
That's not a realistic option, at least not with anything that uses this
approach to sorting the tables. You'd have to assume that qsort() is
stable which it probably isn'
On Fri, Sep 28, 2012 at 12:40:38PM -0500, Karl O. Pinc wrote:
> Hi,
>
> The attached patch (against git head)
> normalizes "search_path" as the thing indexed
> and uses a secondary index term to distinguish
> the configuration parameter from the run-time
> setting.
>
> "search path" the concept r
On Fri, Jan 25, 2013 at 11:59 AM, Tom Lane wrote:
> Bruce Momjian writes:
>> On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
>>> FWIW, and I won't annoy anyone further after this email, now that its
>>> deterministic, I still think that this should be an ERROR not a WARNING.
>
>> A
On 2013-01-25 12:19:25 -0500, Robert Haas wrote:
> On Fri, Jan 25, 2013 at 11:51 AM, Tom Lane wrote:
> > The floor(log(size)) part seems like it will have rather arbitrary
> > behavioral shifts when a table grows just past a log boundary. Also,
> > I'm not exactly sure whether you're proposing sm
On Thu, Jan 24, 2013 at 09:12:41PM -0800, David Fetter wrote:
> On Thu, Jan 24, 2013 at 09:51:46AM -0800, David Fetter wrote:
> > Folks,
> >
> > Andrew Gierth asked me to send this out as his email is in a parlous
> > state at the moment. My comments will follow in replies. Without
> > further a
On 2013-01-26 02:21:00 +0900, Fujii Masao wrote:
> On Sat, Jan 5, 2013 at 11:11 PM, Magnus Hagander wrote:
> > On Fri, Jan 4, 2013 at 7:13 PM, Peter Eisentraut wrote:
> >> On 1/3/13 12:30 PM, Robert Haas wrote:
> >>> On Thu, Jan 3, 2013 at 11:32 AM, Magnus Hagander
> >>> wrote:
> Any parti
On Sat, Jan 5, 2013 at 11:11 PM, Magnus Hagander wrote:
> On Fri, Jan 4, 2013 at 7:13 PM, Peter Eisentraut wrote:
>> On 1/3/13 12:30 PM, Robert Haas wrote:
>>> On Thu, Jan 3, 2013 at 11:32 AM, Magnus Hagander
>>> wrote:
Any particular reason? It goes pretty tightly together with
pg_re
On Fri, Jan 25, 2013 at 11:51 AM, Tom Lane wrote:
> The floor(log(size)) part seems like it will have rather arbitrary
> behavioral shifts when a table grows just past a log boundary. Also,
> I'm not exactly sure whether you're proposing smaller tables first or
> bigger tables first, nor that eit
On 2013-01-25 11:51:33 -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > 2. for other tables, consider floor(log(size)). This makes tables of
> > sizes in the same ballpark be considered together.
>
> > 3. For tables of similar size, consider
> > (n_dead_tuples - threshold) / threshold.
> > "th
Bruce Momjian writes:
> On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
>> FWIW, and I won't annoy anyone further after this email, now that its
>> deterministic, I still think that this should be an ERROR not a WARNING.
> As the FREEZE is just an optimization, I thought NOTICE, vs
Robert Haas writes:
> OK, but can we lay the issue of a *normalized* command string to the
> side for just one minute, and talk about exposing the *raw* command
> string? It seems to me that this would be (1) very easy to do, (2)
> reasonable to slip into 9.3, and (3) useful to some people. Argu
On 25 January 2013 15:24, Bruce Momjian wrote:
> pg_restore --single-transaction has the setup to make use of the new
> COPY FREEZE optimization.
>
> However, I don't see us using COPY FREEZE for pg_restore
> --single-transaction. Shouldn't we do that? The problem is we would
> need to have pg_d
Alvaro Herrera writes:
> So if we're to discuss this, here's what I had in mind:
> 1. for-wraparound tables always go first; oldest age(relfrozenxid) are
> sorted earlier. For tables of the same age, consider size as below.
It seems unlikely that age(relfrozenxid) will be identical for multiple
Alvaro Herrera writes:
> Peter Eisentraut escribió:
>> Autovacuum has existed for N years and nobody complained about this
>> until just now, so I don't see a strong justification for backpatching.
> I disagree about people not complaining. Maybe the complaints have not
> been specifically about
On Fri, Jan 25, 2013 at 4:10 AM, Phil Sorber wrote:
> On Thu, Jan 24, 2013 at 1:12 PM, Fujii Masao wrote:
>> set_pglocale_pgservice() should be called?
>>
>> I think that the command name (i.e., pg_isready) should be given to
>> PQpingParams() as fallback_application_name. Otherwise, the server
>
On 25 January 2013 12:15, Heikki Linnakangas wrote:
>> 1) an immediate checkpoint can cause a disk/resource usage spike,
>> which is definitely not what you need just when a spike of connections
>> and new SQL hits the system.
>
>
> It doesn't need to be an "immediate" checkpoint, ie. you don't n
Peter Eisentraut escribió:
> On 1/25/13 10:29 AM, Alvaro Herrera wrote:
> > And I do want to get something back-patchable.
>
> Autovacuum has existed for N years and nobody complained about this
> until just now, so I don't see a strong justification for backpatching.
I disagree about people not
On Fri, Jan 25, 2013 at 10:30:40AM -0500, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
> > > On 2013-01-23 14:02:46 -0500, Bruce Momjian wrote:
> > > > As a reminder, COPY FREEZE still does not issue any warning/
--On 25. Januar 2013 16:28:16 +0100 Andres Freund
wrote:
Did you reindex after upgrading to 9.1.6? Did you ever have any crashes
or failovers before upgrading to 9.1.6?
I have seen pretty similar symptoms caused by "Fix persistence marking
of shared buffers during WAL replay" in 9.1.6.
Hm
On 1/25/13 10:29 AM, Alvaro Herrera wrote:
> And I do want to get something back-patchable.
Autovacuum has existed for N years and nobody complained about this
until just now, so I don't see a strong justification for backpatching.
Or is this a regression from an earlier release?
In general, I t
On Thu, Jan 24, 2013 at 4:36 AM, Xi Wang wrote:
> icc optimizes away the overflow check x + y < x (y > 0), because
> signed integer overflow is undefined behavior in C. Instead, use
> a safe precondition test x > INT_MAX - y.
As you post these patches, please add them to:
https://commitfest.pos
On Thu, Jan 24, 2013 at 5:43 AM, Dimitri Fontaine
wrote:
>> But I wonder: wouldn't it be better to just expose the raw string the
>> user typed? I mean, in all the cases we really care about, the
>> information we can *reliably* expose at this point is going to be
>> pretty nearly the same as ext
On 01/25/2013 10:26 AM, Peter Eisentraut wrote:
On 1/24/13 4:04 PM, Andrew Dunstan wrote:
On 01/24/2013 11:19 AM, Noah Misch wrote:
On Thu, Jan 24, 2013 at 08:50:36AM -0500, Andrew Dunstan wrote:
On 01/24/2013 03:42 AM, Craig Ringer wrote:
On 01/24/2013 01:06 AM, Alexander Law wrote:
Hello,
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
> > On 2013-01-23 14:02:46 -0500, Bruce Momjian wrote:
> > > As a reminder, COPY FREEZE still does not issue any warning/notice if
> > > the freezing does not happen:
> >
> > FWIW, and I won'
2013/1/25 Kohei KaiGai :
> 2013/1/24 Magnus Hagander :
>> On Thu, Jan 24, 2013 at 10:11 AM, Kohei KaiGai wrote:
>>> 2013/1/24 Tom Lane :
John R Pierce writes:
> On 1/23/2013 8:32 PM, Tom Lane wrote:
>> FWIW, in Fedora-land I see: ...
> I'd be far more interested in what is i
Tom Lane escribió:
> As posted, what we've got here is sorting on a boolean condition, with
> the behavior within each group totally up to the whims of qsort(). That
> seems especially dangerous since the priority order is mostly undefined.
>
> I was a bit surprised that Alvaro didn't propose so
On 2013-01-25 16:24:52 +0100, Bernd Helmle wrote:
> We are currently analyzing an issue at one of our customers PostgreSQL
> database.
>
> The current version is 9.1.6 (update to 9.1.7 is scheduled for next monday,
> no downtime possible before). It runs on POWER7 (pSeries 740) on an RHEL6.3
> 64-
On 23.01.2013 07:31, Jon Erdman wrote:
Done. Attached.
Thanks, committed.
On 29.12.2012 20:56, Stephen Frost wrote:
> No biggie, and to get the bike-shedding started, I don't really like the
> column name or the values.. :) I feel like something clearer would be
> "Runs_As" with "caller" or "
On 1/24/13 4:04 PM, Andrew Dunstan wrote:
>
> On 01/24/2013 11:19 AM, Noah Misch wrote:
>> On Thu, Jan 24, 2013 at 08:50:36AM -0500, Andrew Dunstan wrote:
>>> On 01/24/2013 03:42 AM, Craig Ringer wrote:
On 01/24/2013 01:06 AM, Alexander Law wrote:
> Hello,
> Please let me know if I ca
We are currently analyzing an issue at one of our customers PostgreSQL
database.
The current version is 9.1.6 (update to 9.1.7 is scheduled for next monday,
no downtime possible before). It runs on POWER7 (pSeries 740) on an RHEL6.3
64-bit LPAR. The packages are built from PGDG SVN sources, no
pg_restore --single-transaction has the setup to make use of the new
COPY FREEZE optimization.
However, I don't see us using COPY FREEZE for pg_restore
--single-transaction. Shouldn't we do that? The problem is we would
need to have pg_dump emit the FREEZE, which would cause it not to load
in ea
Heikki Linnakangas writes:
> There's no hard correctness reason here for any particular behavior, I
> just feel that that would make most sense. It seems prudent to initiate
> a checkpoint right after timeline switch, so that you get a new
> checkpoint on the new timeline fairly soon - it could
On Fri, Sep 14, 2012 at 02:04:51PM +, Amit kapila wrote:
> On Thu, 6 Sep 2012 14:50:05 -0400 Robert Hass wrote:
>
> On Tue, Aug 28, 2012 at 6:40 AM, Amit Kapila com> wrote:
> >> AFAICT during Update also, it doesn't contain useful. The only chance it
> >> would have contain something useful
[ changing subject line to keep threads of discussion separate ]
On Thu, Jan 24, 2013 at 5:51 AM, Dimitri Fontaine
wrote:
> Something like this part:
>
> + -- now try something crazy to ensure we don't crash the backend
> + create function test_event_trigger_drop_function()
> + returns event_tri
1 - 100 of 120 matches
Mail list logo
