On Fri, May 11, 2012 at 10:03 PM, Tom Lane wrote:
>
> Well, the question to me is exactly how much good it will do to stop
> deletion of the pg_tablespace entry, if the underlying files are gone.
> I'm having a hard time getting excited about expending cycles on that.
>
There could be multiple r
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of vie may 11 20:28:28 -0400 2012:
>> I'm astonished we don't do that already. Seems inconsistent with
>> other SQL object types - most obviously, schemas - and a potentially
>> giant foot-gun.
> The original patch did contain tablespa
Excerpts from Robert Haas's message of vie may 11 20:28:28 -0400 2012:
> On Fri, May 11, 2012 at 7:55 PM, Tom Lane wrote:
> > A larger question is whether we should start making pg_shdepend entries
> > for table/index usage of non-default tablespaces, so that you couldn't
> > DROP a tablespace th
On Fri, May 11, 2012 at 2:03 PM, Jeff Janes wrote:
> On Thu, May 10, 2012 at 10:44 AM, Bruce Momjian wrote:
>> On Thu, May 10, 2012 at 01:11:54PM +0100, Peter Geoghegan wrote:
>>
>>> Why can't we call group commit group commit (and for that matter,
>>> index-only scans index-only scans), so that
On Fri, May 11, 2012 at 7:55 PM, Tom Lane wrote:
> A larger question is whether we should start making pg_shdepend entries
> for table/index usage of non-default tablespaces, so that you couldn't
> DROP a tablespace that the catalogs think still has tables/indexes in
> it.
I'm astonished we don't
On Fri, May 11, 2012 at 2:17 PM, Tom Lane wrote:
> The merit would be in keeping the function's definition simple.
True. It's not *much* simpler, but it is simpler.
> Anyway, let's see if breaking this down by cases clarifies anything.
> As I see it, there are three possible cases:
>
> 1. On ma
"Albe Laurenz" writes:
> Michael Nolan wrote:
>> I see one potential difference between your results and mine.
>> When I rebuild the tablespace, I wind up with the same filename/OID as
>> before, I'm not sure you do.
> Right. That's strange.
> Usually OIDs get incremented, so you shouldn't end up
Hello,
following this short discussion
http://archives.postgresql.org/message-id/4f5aa202.9020...@gmail.com
I gave it one more try and hacked the optimizer so that function can
become an inner relation in NL join, parametrized with values from the
outer relation.
I tried to explain my thoughts
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of vie may 11 16:50:01 -0400 2012:
>> I'm confused about what you did here and whether this isn't just pilot
>> error.
> The sequence of events is:
> postmaster -T
> crash a backend
> SIGINT postmaster
> SIGCONT all child processes
> My e
Excerpts from Tom Lane's message of vie may 11 16:50:01 -0400 2012:
> > Yep, it's still there as far as I can tell. A backtrace from the
> > checkpointer shows it's waiting on the latch.
>
> I'm confused about what you did here and whether this isn't just pilot
> error. If you run with -T then
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of jue may 10 02:27:32 -0400 2012:
>> Alvaro Herrera writes:
>>> I noticed while doing some tests that the checkpointer process does not
>>> recover very nicely after a backend crashes under postmaster -T (after
>>> all processes have been
On 11 May 2012 19:45, Tom Lane wrote:
> Andres Freund writes:
>> Its the only place though which knows whether its actually sensible to wakeup
>> the walsender. We could make it return whether it wrote anything and do the
>> wakeup at the callers. I count 4 different callsites which would be an
>
Andres Freund writes:
> Its the only place though which knows whether its actually sensible to wakeup
> the walsender. We could make it return whether it wrote anything and do the
> wakeup at the callers. I count 4 different callsites which would be an
> annoying duplication but I don't really
On Friday, May 11, 2012 08:36:24 PM Tom Lane wrote:
> Robert Haas writes:
> > That definitely doesn't seem ideal - a lot of things can pile up
> > behind WALWriteLock. I'm not sure how big a problem it would be in
> > practice, but we generally make a practice of avoiding sending signals
> > whil
Robert Haas writes:
> That definitely doesn't seem ideal - a lot of things can pile up
> behind WALWriteLock. I'm not sure how big a problem it would be in
> practice, but we generally make a practice of avoiding sending signals
> while holding LWLocks whenever possible...
There's a good reason
Hackers, Replicators, Clusterers:
The agenda and the list of attendees for the cluster-hackers summit has
been set:
http://wiki.postgresql.org/wiki/PgCon2012CanadaClusterSummit
Please send me any corrections, changes or additions ASAP.
Thanks you!
--
Josh Berkus
PostgreSQL Experts Inc.
http:/
Robert Haas writes:
> ... I don't really see any particular merit in removing our own
> XID from the picture entirely: that changes the behavior more
> significantly for no particular benefit.
The merit would be in keeping the function's definition simple.
Anyway, let's see if breaking this down
On fre, 2012-05-11 at 11:32 +0200, Magnus Hagander wrote:
> > You are misinterpreting this. The reason Bruce's link was removed was
> > that the other (official) build was set to run at the same frequency, so
> > Bruce's build was exactly redundant. The requirement/aspiration to have
> > a few mi
On Thu, May 10, 2012 at 10:44 AM, Bruce Momjian wrote:
> On Thu, May 10, 2012 at 01:11:54PM +0100, Peter Geoghegan wrote:
>
>> Why can't we call group commit group commit (and for that matter,
>> index-only scans index-only scans), so that people will understand
>> that we are now competitive with
On Friday, May 11, 2012 07:20:26 PM Robert Haas wrote:
> On Fri, May 11, 2012 at 1:09 PM, Fujii Masao wrote:
> > Calling WalSndWakeup() while WALWriteLock is being held might cause
> > another performance degradation. No?
>
> That definitely doesn't seem ideal - a lot of things can pile up
> behi
On Fri, May 11, 2012 at 6:16 PM, Kevin Grittner
wrote:
>> MaxHeapTuplesPerPage?
>
> What about dead line pointers without corresponding tuples?
Actually we don't allow there to be more than MaxHeapTuplesPerPage
line pointers even if some of them are dead line pointers.
I think the argument then
On Fri, May 11, 2012 at 1:28 PM, Tom Lane wrote:
> I'm not convinced this is the best thing, and I'm definitely not happy
> with changing the behavior of working cases (ie, behavior on the master)
> in the back branches.
>
> Anybody else have an opinion on this?
I agree with you. Essentially, if
Simon Riggs writes:
> On 11 May 2012 17:13, Tom Lane wrote:
>> Hm. This fixes the stability-within-transaction problem, but it's also
>> introduced a change in the definition of age(), no?
> Yeh, I thought about that.
> The likely difference between the old and the new result is likely to
> be
On Fri, May 11, 2012 at 1:09 PM, Fujii Masao wrote:
> Calling WalSndWakeup() while WALWriteLock is being held might cause another
> performance degradation. No?
That definitely doesn't seem ideal - a lot of things can pile up
behind WALWriteLock. I'm not sure how big a problem it would be in
pra
"David E. Wheeler" writes:
> On May 11, 2012, at 9:51 AM, David E. Wheeler wrote:
>> \set ON_ERROR_ROLLBACK interactive
>>
>> So I guess it transparently rolls back a savepoint for the previous
>> statement. I had forgotten I turned that on. Apologies for the noise.
Ah-hah.
> OTOH, might it be
Robert Haas wrote:
> On Fri, May 11, 2012 at 11:36 AM, Kevin Grittner
> wrote:
>> Robert Haas wrote:
>>> The trouble is, AFAICS, that you can't bound M very well without
>>> scanning the whole table. I mean, it's bounded by theoretical
>>> limit, but that's it.
>>
>> What would the theoretical
On May 11, 2012, at 9:51 AM, David E. Wheeler wrote:
>\set ON_ERROR_ROLLBACK interactive
>
> So I guess it transparently rolls back a savepoint for the previous
> statement. I had forgotten I turned that on. Apologies for the noise.
OTOH, might it be useful to have psql show some sort of st
On Fri, May 11, 2012 at 4:51 AM, Andres Freund wrote:
> diff --git a/src/backend/access/transam/xlog.c
> b/src/backend/access/transam/xlog.c
> index ecb71b6..7a3224b 100644
> --- a/src/backend/access/transam/xlog.c
> +++ b/src/backend/access/transam/xlog.c
> @@ -1906,6 +1906,10 @@ XLogWrite(XLogwr
> A key requirement is to be able to drop in new config files without
> needing to $EDIT anything.
Yes, absolutely. I want to move towards the idea that the majority of
our users never edit postgresql.conf by hand.
> OK, its possible to put in lots of includeifexists for non-existent
> files ju
On Fri, May 11, 2012 at 11:36 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> The trouble is, AFAICS, that you can't bound M very well without
>> scanning the whole table. I mean, it's bounded by theoretical
>> limit, but that's it.
>
> What would the theoretical limit be?
MaxHeapTuplesPerPag
On May 11, 2012, at 9:39 AM, Tom Lane wrote:
>> Hrm∑I've also just replicated it on CentOS 6.2 with Perl 5.10.1:
>
> Interesting.
Ah, it’s a psql configuration issue. I had replicated it on that box by
connecting with psql on my Mac. When I SSHed to the box and used the psql
there, I was *not*
On 11 May 2012 17:13, Tom Lane wrote:
> Simon Riggs writes:
>> Ensure age() returns a stable value rather than the latest value
>
> Hm. This fixes the stability-within-transaction problem, but it's also
> introduced a change in the definition of age(), no? Previously, in an
> xact that had an X
"David E. Wheeler" writes:
> Hrm
I've also just replicated it on CentOS 6.2 with Perl 5.10.1:
Interesting.
> Perhaps there is something funky in my configuration, though I tried a
> few different things and couldn't get it to change.
Yeah. If Bruce and I don't see it on a couple of configurati
On May 10, 2012, at 6:18 PM, Tom Lane wrote:
> I also tried this on a Fedora 16 box, which has
>
> $ perl -v
> This is perl 5, version 14, subversion 2 (v5.14.2) built for
> x86_64-linux-thread-multi
>
> Works fine there too...
Hrm…I've also just replicated it on CentOS 6.2 with Perl 5.10.1:
Simon Riggs writes:
> Ensure age() returns a stable value rather than the latest value
Hm. This fixes the stability-within-transaction problem, but it's also
introduced a change in the definition of age(), no? Previously, in an
xact that had an XID, the age was measured relative to that XID.
I'
On Sat, May 12, 2012 at 12:44 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> How common *is* it to have a build that doesn't have integer timestamps
>> these days? Does any of the binary builds do that at all, for example? If
>> it's uncommon enough, I think we should just go with the easy way
On May11, 2012, at 16:03 , Kevin Grittner wrote:
>> [more complex alternatives]
>
> I really think your first suggestion covers it perfectly; these more
> complex techniques don't seem necessary to me.
The point of the more complex techniques (especially the algorithm in
my second mail, the "repl
On Fri, May 11, 2012 at 4:11 AM, Tom Lane wrote:
> Fujii Masao writes:
>> On Fri, May 11, 2012 at 12:07 AM, MauMau wrote:
>>> Thanks for your explanation. Although I haven't understood it well yet, I'll
>>> consider what you taught. And I'll consider if the tentative measure of
>>> removing KEEP
Tom Lane wrote:
> "Kevin Grittner" writes:
>> [ uniformly sample the TID space defined as (1..P, 1..M) ]
>
>> Shouldn't that get us the randomly chosen sample we're looking
>> for? Is there a problem you think this ignores?
>
> Not sure. The issue that I'm wondering about is that the line
> n
On May11, 2012, at 17:20 , Robert Haas wrote:
> On Fri, May 11, 2012 at 11:04 AM, Kevin Grittner
>> Since T cancels out of that equation, we don't need to worry about
>> estimating it. Results will be correct for any value of M which is
>> *at least* as large as the maximum tuple index in the tabl
On 05/11/2012 05:32 AM, Magnus Hagander wrote:
But in the interest of actually being productive - what *is* the
usecase for needing a 5 minute turnaround time? I don't buy the "check
what a patch looks like", because that should be done *before* the
commit, not after - so it's best verified by
Magnus Hagander writes:
> How common *is* it to have a build that doesn't have integer timestamps
> these days? Does any of the binary builds do that at all, for example? If
> it's uncommon enough, I think we should just go with the easy way out...
+1 for just rejecting a mismatch.
"Kevin Grittner" writes:
> Robert Haas wrote:
>> The trouble is, AFAICS, that you can't bound M very well without
>> scanning the whole table. I mean, it's bounded by theoretical
>> limit, but that's it.
> What would the theoretical limit be? (black size - page header size
> - minimum size of
Robert Haas wrote:
> The trouble is, AFAICS, that you can't bound M very well without
> scanning the whole table. I mean, it's bounded by theoretical
> limit, but that's it.
What would the theoretical limit be? (black size - page header size
- minimum size of one tuple) / item pointer size?
"Kevin Grittner" writes:
> [ uniformly sample the TID space defined as (1..P, 1..M) ]
> Shouldn't that get us the randomly chosen sample we're looking for?
> Is there a problem you think this ignores?
Not sure. The issue that I'm wondering about is that the line number
part of the space is not
On Fri, May 11, 2012 at 11:04 AM, Kevin Grittner
wrote:
> We
> will be probing random page numbers 1..P for random tuple indexes
> 1..M. So how many random probes by ctid does that require? The
> chance of a hit on each probe is ((T/P)/M) -- the average number of
> tuples per page divided by the
Tom Lane wrote:
> If you're willing to accept that the quality of the results
> depends on having up-to-date stats, then I'd suggest (1) use the
> planner's existing technology to estimate the number of rows in
> the table; (2) multiply by sampling factor you want to get a
> desired number of sa
On Thursday, May 10, 2012, Fujii Masao wrote:
> On Thu, May 10, 2012 at 11:51 PM, Magnus Hagander
> >
> wrote:
> > And taking this a step further - we *already* send these GUCs.
> > Previous references to us not doing that were incorrect :-)
> >
> > So this should be a much easier fix than we tho
Bruce Momjian writes:
> Let me add that I am concerned about the lack of objectivity in many of
> the suggestions in this thread. This has prompted me to think that the
> temptation of having names on these release note items is just too
> great, and that the names should be removed.
Er, what?
On 05/11/2012 10:15 AM, Bruce Momjian wrote:
On Fri, May 11, 2012 at 10:01:32AM -0400, Bruce Momjian wrote:
On Fri, May 11, 2012 at 09:51:49AM -0400, Andrew Dunstan wrote:
On 05/11/2012 08:56 AM, Bruce Momjian wrote:
On Thu, May 10, 2012 at 08:46:56PM -0700, Robert Haas wrote:
On May 10, 2
"Kevin Grittner" writes:
> Florian Pflug wrote:
>> Maybe one can get rid of these sorts of problems by factoring in
>> the expected density of the table beforehand and simply accepting
>> that the results will be inaccurate if the statistics are
>> outdated?
> Unless I'm missing something, I th
On 5/11/12, Michael Nolan wrote:
> On 5/11/12, Albe Laurenz wrote:
>> Michael Nolan wrote:
>>> I see one potential difference between your results and mine.
>>>
>>> When I rebuild the tablespace, I wind up with the same filename/OID as
>>> before, I'm not sure you do.
>>
>> Right. That's strange.
On 5/11/12, Albe Laurenz wrote:
> Michael Nolan wrote:
>> I see one potential difference between your results and mine.
>>
>> When I rebuild the tablespace, I wind up with the same filename/OID as
>> before, I'm not sure you do.
>
> Right. That's strange.
> Usually OIDs get incremented, so you sho
On Fri, May 11, 2012 at 10:01:32AM -0400, Bruce Momjian wrote:
> On Fri, May 11, 2012 at 09:51:49AM -0400, Andrew Dunstan wrote:
> >
> >
> > On 05/11/2012 08:56 AM, Bruce Momjian wrote:
> > >On Thu, May 10, 2012 at 08:46:56PM -0700, Robert Haas wrote:
> > >>On May 10, 2012, at 4:19 PM, Andrew Dun
Florian Pflug writes:
> This all hinges on the ability to produce a sufficient accurate estimate of
> the
> TID density p_tup/p_tid, of course.
I think that's the least of its problems. AFAICS this analysis ignores
(1) the problem that the TID space is nonuniform, ie we don't know how
many tupl
Florian Pflug wrote:
> Maybe one can get rid of these sorts of problems by factoring in
> the expected density of the table beforehand and simply accepting
> that the results will be inaccurate if the statistics are
> outdated?
>
> One could, for example, simply pick
>
> N := SamplingPercent
On Fri, May 11, 2012 at 09:51:49AM -0400, Andrew Dunstan wrote:
>
>
> On 05/11/2012 08:56 AM, Bruce Momjian wrote:
> >On Thu, May 10, 2012 at 08:46:56PM -0700, Robert Haas wrote:
> >>On May 10, 2012, at 4:19 PM, Andrew Dunstan wrote:
> >>>On 05/10/2012 06:15 PM, Tom Lane wrote:
> How about a
On Thu, May 10, 2012 at 02:30:35PM -0400, Robert Haas wrote:
> On Thu, May 10, 2012 at 2:07 PM, Kevin Grittner
> wrote:
> > Ants Aasma wrote:
> >> It seems to me that the simplest thing to do would be to lift the
> >> sampling done in analyze.c (acquire_sample_rows) and use that to
> >> implement
[ Sorry for the self-reply ]
On May11, 2012, at 13:17 , Florian Pflug wrote:
> Actually, thinking more about this, if the approach sketched above
> turns out to work, then one might be able to get away without remembering
> previously computed TIDs, thus removing a lot of complexity.
>
> Say, for
On 05/11/2012 08:56 AM, Bruce Momjian wrote:
On Thu, May 10, 2012 at 08:46:56PM -0700, Robert Haas wrote:
On May 10, 2012, at 4:19 PM, Andrew Dunstan wrote:
On 05/10/2012 06:15 PM, Tom Lane wrote:
How about a hybrid: we continue to identify patch authors as now, that is with names
attached
Michael Nolan wrote:
> I see one potential difference between your results and mine.
>
> When I rebuild the tablespace, I wind up with the same filename/OID as
> before, I'm not sure you do.
Right. That's strange.
Usually OIDs get incremented, so you shouldn't end up with the same
OID for the new
Magnus Hagander writes:
> On Thu, May 10, 2012 at 6:52 PM, Tom Lane wrote:
>> Oh ... while hacking win32 PGSemaphoreLock I saw that it has a *seriously*
>> nasty bug: it does not reset ImmediateInterruptOK before returning.
>> How is it that Windows machines aren't falling over constantly?
> Hmm
From: "Kevin Grittner"
"MauMau" wrote:
For information, what kind of breakage would occur?
I imagined removing KEEPONLYALNUM would just accept
non-alphanumeric characters and cause no harm to those who use
only alphanumeric characters.
This would break our current usages because of the ha
On Thu, May 10, 2012 at 08:46:56PM -0700, Robert Haas wrote:
> On May 10, 2012, at 4:19 PM, Andrew Dunstan wrote:
> > On 05/10/2012 06:15 PM, Tom Lane wrote:
> >> How about a hybrid: we continue to identify patch authors as now, that is
> >> with names attached to the feature/bugfix descriptions,
> Florian Pflug wrote:
>> On May10, 2012, at 18:36 , Kevin Grittner wrote:
>>> Robert Haas wrote:
>>>
I wonder if you could do this with something akin to the Bitmap
Heap Scan machinery. Populate a TID bitmap with a bunch of
randomly chosen TIDs, fetch them all in physical order
>
On 10 May 2012 05:44, Josh Berkus wrote:
>
>> I expect to revisit config directories before the first 9.3 CF, it will
>> help multiple things I'd like to see happen. Then we can circle back to
>> the main unification job with a fairly clear path forward from there.
>
> Yeah, let's discuss this ne
Le jeudi 10 mai 2012 22:18:30, Alvaro Herrera a écrit :
> It's been said elsewhere that adding all this to the release notes as
> found on the official docs would be too bulky. How about having a
> second copy of the release notes that contains authorship info as
> proposed by Andrew? Then the do
On 10 May 2012 16:14, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Tom Lane's message of jue may 10 02:27:32 -0400 2012:
>>> Alvaro Herrera writes:
>> I noticed while doing some tests that the checkpointer process does not
>> recover very nicely after a backend crashes under postmas
On Thu, May 10, 2012 at 6:52 PM, Tom Lane wrote:
> I wrote:
>> Hence I think we oughta swap the order of those two array
>> elements. (Same issue in PGSemaphoreLock, btw, and I'm suspicious of
>> pgwin32_select.)
>
> Oh ... while hacking win32 PGSemaphoreLock I saw that it has a *seriously*
> nas
On 10 May 2012 20:51, Andres Freund wrote:
> I noticed that when synchronous_commit=off were not waking up the wal sender
> latch in xact.c:RecordTransactionCommit which leads to ugly delays of approx 7
> seconds (1 + replication_timeout/10) with default settings.
> Given that were flushing the w
On Fri, May 11, 2012 at 9:55 AM, Peter Eisentraut wrote:
> On fre, 2012-05-11 at 09:26 +0200, Magnus Hagander wrote:
>> On Thu, May 10, 2012 at 6:28 PM, Peter Eisentraut wrote:
>> > On tor, 2012-05-10 at 17:31 +0200, Magnus Hagander wrote:
>> >> If people want the main docs building more often th
On 10/05/12 19:45, Peter Eisentraut wrote:
On lör, 2012-05-05 at 22:45 +0200, Jan Urbański wrote:
Apparently once you implement PyMappingMethods.mp_subscript you can
drop PySequenceMethods.sq_slice, but I guess there's no harm in
keeping it (and I'm not sure it'd work on Python 2.3 with only
mp_
On fre, 2012-05-11 at 09:26 +0200, Magnus Hagander wrote:
> On Thu, May 10, 2012 at 6:28 PM, Peter Eisentraut wrote:
> > On tor, 2012-05-10 at 17:31 +0200, Magnus Hagander wrote:
> >> If people want the main docs building more often that's not really a
> >> problem other than time - we just need t
On Thu, May 10, 2012 at 6:28 PM, Peter Eisentraut wrote:
> On tor, 2012-05-10 at 17:31 +0200, Magnus Hagander wrote:
>> If people want the main docs building more often that's not really a
>> problem other than time - we just need to decouple it from the
>> buildfarm and run a separate job for it.
74 matches
Mail list logo
