On 26.05.2011 06:19, Kevin Grittner wrote:
Dan and I went around a couple times chasing down all code, comment,
and patch changes needed, resulting in the attached patch. We found
and fixed the bug which originally manifested in a way which I
confused with a need for row locks, as well as anothe
On Wed, May 25, 2011 at 3:11 PM, Jaime Casanova wrote:
> On Wed, May 25, 2011 at 12:28 AM, Fujii Masao wrote:
>> On Wed, May 25, 2011 at 2:16 PM, Heikki Linnakangas
>>> By the time the standby has received that message, it might not be caught-up
>>> anymore because new WAL might've been generated
On Wed, May 25, 2011 at 11:07 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 25.05.2011 07:42, Fujii Masao wrote:
>>> To achieve that, I'm thinking to change walsender so that, when the standby
>>> has caught up with the master, it sends back the message indicating that to
>>> the standby
I'm a bit disappointed that no one has commented on this yet. I would
have appreciated some preliminary feedback.
Anyway, I've added it to CommitFest 2011-06.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hack
On 24.05.2011 23:43, Peter Geoghegan wrote:
Attached is the latest revision of the latch implementation that
monitors postmaster death, plus the archiver client that now relies on
that new functionality and thereby works well without a tight
PostmasterIsAlive() polling loop.
The Unix-stuff look
On Thu, May 26, 2011 at 9:40 AM, Robert Haas wrote:
> On Wed, May 25, 2011 at 11:51 PM, Pavan Deolasee
> Having said that, it doesn't excite me too much because I
>> think we should do the dead line pointer reclaim operation during page
>> pruning and we are already holding cleanup lock at that ti
Just a trivia. I remember spending weeks on reading the ARIES paper
during my post graduation and I loved the depth of knowledge in that
paper. In fact, if I re-read it again now, I would appreciate it even
more. Are there other papers in the same league, especially which are
more closely related
On 26 May 2011 11:22, Heikki Linnakangas
wrote:
> The Unix-stuff looks good to me at a first glance.
Good.
> There's one reference left to "life sign" in comments. (FWIW, I don't have a
> problem with that terminology myself)
Should have caught that one. Removed.
> Looking at the MSDN docs aga
On Thu, May 26, 2011 at 11:58 AM, Peter Geoghegan wrote:
> Attached revision doesn't use any threads or pipes on win32. It's far
> neater there. I'm still seeing that "lagger" process (which is an
> overstatement) at times, so I guess it is normal. On Windows, there is
> no detailed PS output, so
On tis, 2011-05-24 at 23:26 -0400, Robert Haas wrote:
> On Tue, May 24, 2011 at 4:44 PM, Tom Lane wrote:
> > There's a complaint here
> > http://archives.postgresql.org/pgsql-general/2011-05/msg00714.php
> > about the fact that 9.1 pg_dump always dumps CREATE EXTENSION commands
> > for all loaded
On Thu, May 26, 2011 at 4:10 PM, Pavan Deolasee
wrote:
> On Thu, May 26, 2011 at 9:40 AM, Robert Haas wrote:
>
>> Currently, I believe the only way a page can get marked all-visible is
>> by vacuum. But if we make this change, then it would be possible for
>> a HOT cleanup to encounter a situati
On Thu, May 26, 2011 at 6:40 AM, Pavan Deolasee
wrote:
>>> There are some other issues that we should think about too. Like
>>> recording free space and managing visibility map. The free space is
>>> recorded in the second pass pass today, but I don't see any reason why
>>> that can't be moved to
On Thu, May 26, 2011 at 8:57 AM, Pavan Deolasee
wrote:
> On Thu, May 26, 2011 at 4:10 PM, Pavan Deolasee
> wrote:
>> On Thu, May 26, 2011 at 9:40 AM, Robert Haas wrote:
>>
>>> Currently, I believe the only way a page can get marked all-visible is
>>> by vacuum. But if we make this change, then
Peter Eisentraut writes:
> On tis, 2011-05-24 at 23:26 -0400, Robert Haas wrote:
>> On Tue, May 24, 2011 at 4:44 PM, Tom Lane wrote:
>>> There's a complaint here
>>> http://archives.postgresql.org/pgsql-general/2011-05/msg00714.php
>>> about the fact that 9.1 pg_dump always dumps CREATE EXTENSION
Hello,
I wrote and attached a patch for the TODO item below (which I proposed).
Allow multiple Postgres clusters running on the same machine to distinguish
themselves in the event log
http://archives.postgresql.org/pgsql-hackers/2011-03/msg01297.php
http://archives.postgresql.org/pgsql-hackers
Greg Stark writes:
> On Wed, May 25, 2011 at 9:41 AM, Tom Lane wrote:
>> ... What I'm currently imagining is
>> to do a smoothed moving average, where we factor in the new density
>> estimate with a weight dependent on the percentage of the table we did
>> scan. That is, the calculation goes som
On Thu, May 26, 2011 at 11:25 AM, Tom Lane wrote:
> I'm still of the opinion that an incremental estimation process like
> the above is a lot saner than what we're doing now, snarky Dilbert
> references notwithstanding. The only thing that seems worthy of debate
> from here is whether we should t
Ibrar Ahmed writes:
> Please find the updated patch. I have added this "+Olibmerrno" compile flag
> check in configure/configure.in file.
I tried this on my HP-UX 10.20 box, and it didn't work very nicely:
configure decided that the compiler accepted +Olibmerrno, so I got a
compile full of
Robert Haas writes:
> I would feel a lot better about something that is deterministic, like,
> I dunno, if VACUUM visits more than 25% of the table, we use its
> estimate. And we always use ANALYZE's estimate. Or something.
This argument seems to rather miss the point. The data we are working
On Thu, May 19, 2011 at 04:13:12PM -0400, Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of jue may 19 15:32:57 -0400 2011:
> >
> > That's a bit of a self-defeating argument though, since it implies
> > that the effect of taking an exclusive lock via LockSharedObject()
> > will not si
Excerpts from Stephen Frost's message of mar may 24 22:56:21 -0400 2011:
> Greetings,
>
> Someone (*cough*Haas*cough) made a claim over beers at PGCon that it
> would be very difficult to come up with a way to pre-allocate List
> entries and maintain the current List API. I'll admit that it
Excerpts from Tom Lane's message of mié may 25 16:07:55 -0400 2011:
> Alvaro Herrera writes:
> > Excerpts from Tom Lane's message of mar may 24 17:11:17 -0400 2011:
> >> Right. It would also increase the cognitive load on the user to have
> >> to remember the command-line go-to-line-number switch
* Alvaro Herrera (alvhe...@commandprompt.com) wrote:
> I think what this patch is mainly missing is a description of how the
> new allocation is supposed to work, so that we can discuss the details
> without having to reverse-engineer them from the code.
Sure, sorry I didn't include something more
On Thu, May 26, 2011 at 12:23 PM, Tom Lane wrote:
>> Another thought: Couldn't relation_needs_vacanalyze() just scale up
>> reltuples by the ratio of the current number of pages in the relation
>> to relpages, just as the query planner does?
>
> Hmm ... that would fix Florian's immediate issue, an
On Thu, May 26, 2011 at 12:28 PM, Ross J. Reedstrom wrote:
> Perhaps the approach to restricting connections should not be a database
> object lock, but rather an admin function that does the equivalent of
> flipping datallowconn in pg_database?
To me, that seems like a better approach, although
Stephen Frost writes:
> Basically, I added a ListCell array into the List structure and then
> added a bitmap to keep track of which positions in the array were
> filled.
Hm. I've gotten the impression from previous testing that there are an
awful lot of extremely short lists (1 or 2 elements) r
Robert Haas wrote:
> I think we should really consider replacing reltuples with
> reltupledensity at some point. I continue to be afraid that using
> a decaying average in this case is going to end up overweighting
> the values from some portion of the table that's getting scanned
> repeatedly,
Excerpts from Robert Haas's message of dom may 22 23:09:47 -0400 2011:
> On Sun, May 22, 2011 at 10:24 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Sun, May 22, 2011 at 9:54 PM, Tom Lane wrote:
> >>> But also, 99.999% of the time
> >>> it would be completely wasted effort because the DBA
On Thu, May 26, 2011 at 1:28 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> I think we should really consider replacing reltuples with
>> reltupledensity at some point. I continue to be afraid that using
>> a decaying average in this case is going to end up overweighting
>> the values from so
On Tue, May 24, 2011 at 10:56 PM, Stephen Frost wrote:
> Someone (*cough*Haas*cough) made a claim over beers at PGCon that it
> would be very difficult to come up with a way to pre-allocate List
> entries and maintain the current List API. I'll admit that it wasn't
> quite as trivial as I had
Robert Haas wrote:
> Kevin Grittner wrote:
>> Given how trivial it would be to adjust reltuples to keep its
>> ratio to relpages about the same when we don't have a new "hard"
>> number, but some evidence that we should fudge our previous
>> value, I don't see where this change buys us much. I
Hello,
The CFP for #PgWest is now open. We are holding it at the San Jose
Convention Center from September 27th - 30th. We look forward to seeing
your submissions.
http://www.postgresqlconference.org/
Joshua D. Drake
--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I'm worried that this type of approach would
> bloat the storage required in those cases to a degree that would make
> the patch unattractive.
While I agree that there is some bloat that'll happen with this
approach, we could reduce it by just having a 4-
Heikki Linnakangas wrote:
> Could you explain in the README, why it is safe to only take the
> lock on the visible row version, please?
Sure. I actually intended to do this last night but ran out of
steam and posted what I had, planning on following up with that.
The place it seemed to fit
On tis, 2011-05-24 at 15:34 -0400, Tom Lane wrote:
> I would argue that -Z ought to turn on "gzip" without my having to
> write
> -z as well (at least when the argument is greater than zero; possibly
> -Z0 should be allowed as meaning "no compression").
My concern with that is that if we ever add
On Thu, May 26, 2011 at 2:05 PM, Kevin Grittner
wrote:
>> I'm a bit confused by this - what the current design obfuscates is
>> the fact that reltuples and relpages are not really independent
>> columns; you can't update one without updating the other, unless
>> you want screwy behavior. Replacin
Robert Haas writes:
> Except that's not how it works. At least in the case of ANALYZE, we
> *aren't* counting all the tuples in the table. We're selecting a
> random sample of pages and inferring a tuple density, which we then
> extrapolate to the whole table and store. Then when we pull it bac
Robert Haas writes:
> On Thu, May 26, 2011 at 12:23 PM, Tom Lane wrote:
>>> Another thought: Couldn't relation_needs_vacanalyze() just scale up
>>> reltuples by the ratio of the current number of pages in the relation
>>> to relpages, just as the query planner does?
>> Hmm ... that would fix Flo
Peter Eisentraut writes:
> On tis, 2011-05-24 at 15:34 -0400, Tom Lane wrote:
>> I would argue that -Z ought to turn on "gzip" without my having to write
>> -z as well (at least when the argument is greater than zero; possibly
>> -Z0 should be allowed as meaning "no compression").
> My concern w
pg_basebackup currently doesn't allow compressed tar to stdout. That
should be added to make the interface consistent, and specifically to
allow common idoms like
pg_basebackup -Ft -z -D - | ssh tar -x -z -f -
Small patch attached.
diff --git i/doc/src/sgml/ref/pg_basebackup.sgml w/doc/src/sgml/
On tor, 2011-05-26 at 16:54 -0400, Tom Lane wrote:
> But if you want to take such an extension into account right now,
> maybe we ought to design that feature now. What are you seeing it as
> looking like?
>
> My thought is that "-z" should just mean "give me compression; a good
> default compres
Peter Eisentraut writes:
> pg_basebackup currently doesn't allow compressed tar to stdout. That
> should be added to make the interface consistent, and specifically to
> allow common idoms like
> pg_basebackup -Ft -z -D - | ssh tar -x -z -f -
> Small patch attached.
I have not bothered to read
On tor, 2011-05-26 at 17:06 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > pg_basebackup currently doesn't allow compressed tar to stdout. That
> > should be added to make the interface consistent, and specifically to
> > allow common idoms like
>
> > pg_basebackup -Ft -z -D - | ssh tar -
Peter Eisentraut writes:
> On tor, 2011-05-26 at 16:54 -0400, Tom Lane wrote:
>> But if you want to take such an extension into account right now,
>> maybe we ought to design that feature now. What are you seeing it as
>> looking like?
>>
>> My thought is that "-z" should just mean "give me comp
On tor, 2011-05-26 at 12:14 -0400, Tom Lane wrote:
> Ibrar Ahmed writes:
> > Please find the updated patch. I have added this "+Olibmerrno" compile flag
> > check in configure/configure.in file.
>
> I tried this on my HP-UX 10.20 box, and it didn't work very nicely:
> configure decided that the c
Robert Haas wrote:
> Kevin Grittner wrote:
>> By storing the ratio and one count you make changes to the
>> other count implied and less visible. It seems more
>> understandable and less prone to error (to me, anyway) to keep
>> the two "raw" numbers and calculate the ratio -- and when you
>>
Peter Eisentraut writes:
> On tor, 2011-05-26 at 12:14 -0400, Tom Lane wrote:
>> I tried this on my HP-UX 10.20 box, and it didn't work very nicely:
>> configure decided that the compiler accepted +Olibmerrno, so I got a
>> compile full of
>> cc: warning 450: Unrecognized option +Olibmerrno.
"Kevin Grittner" writes:
> When we prune or vacuum a page, I don't suppose we have enough
> information about that page's previous state to calculate a tuple
> count delta, do we? That would allow a far more accurate number to
> be maintained than anything suggested so far, as long as we tweak
>
Hi all,
On Fri, May 27, 2011 at 2:13 AM, Robert Haas wrote:
> On Thu, May 26, 2011 at 12:28 PM, Ross J. Reedstrom
> wrote:
> > Perhaps the approach to restricting connections should not be a database
> > object lock, but rather an admin function that does the equivalent of
> > flipping datallow
On 05/07/2011 03:32 AM, Mitsuru IWASAKI wrote:
For 1, I've just finish my work. The latest patch is available at:
http://people.freebsd.org/~iwasaki/postgres/buffer-cache-hibernation-postgresql-20110507.patch
Reminder here--we can't accept code based on it being published to a web
page.
On Thu, May 26, 2011 at 11:57 AM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I'm worried that this type of approach would
>> bloat the storage required in those cases to a degree that would make
>> the patch unattractive.
>
> While I agree that there is some bloat that'll hap
OK, I ran a GDB trace into ExecScan and here is a part of it:
#
(gdb) finish
Run till exit from #0 ExecScanFetch (node=0x1d5c3c0,
accessMtd=0x55dd10 , recheckMtd=0x55db70 )
at execScan.c:44
194 if (TupIsNull(slot))
(gdb) s
205 econtext->ecxt_scantuple = slot;
(gdb
On Thu, May 26, 2011 at 11:57 AM, Stephen Frost wrote:
> Handling the 1-entry case would likely be pretty
> straight-forward, but you need book-keeping as soon as you go to two,
> and all that book-keeping feels like overkill for just a 2-entry cache
> to me.
Incidentally what if I call nconc and
Vaibhav Kaushal writes:
> Why do these lines:
> ...
> repeat twice?
Hm, you're new to using gdb, no? That's pretty normal: gdb is just
reflecting back the fact that the compiler rearranges individual
instructions as it sees fit. You could eliminate most, though perhaps
not all, of that noise if
* Greg Stark (gsst...@mit.edu) wrote:
> On Thu, May 26, 2011 at 11:57 AM, Stephen Frost wrote:
> > Handling the 1-entry case would likely be pretty
> > straight-forward, but you need book-keeping as soon as you go to two,
> > and all that book-keeping feels like overkill for just a 2-entry cache
>
Thanks Tom. Comparing to you people, I am definitely new to almost
everything here. I did debug a few smaller programs and never seen anything
as such. So asked. Moreover, those programs I compiled never used any
optimization.
While everything seems to be working, it looks like the slot values do
On Thu, May 26, 2011 at 8:52 PM, Stephen Frost wrote:
> list_concat() does explicitly say that cells will
> be shared afterwards and that you can't pfree() either list (note that
> there's actually a couple cases currently that I discovered which were
> also addressed in the original patch where
* Greg Stark (gsst...@mit.edu) wrote:
> On Thu, May 26, 2011 at 11:57 AM, Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > While I agree that there is some bloat that'll happen with this
> > approach, we could reduce it by just having a 4-entry cache instead of
> > an 8-entry ca
Greg,
* Greg Stark (gsst...@mit.edu) wrote:
> On Thu, May 26, 2011 at 8:52 PM, Stephen Frost wrote:
> > list_concat() does explicitly say that cells will
> > be shared afterwards and that you can't pfree() either list (note that
> > there's actually a couple cases currently that I discovered whi
Hi
I would like to develop function for 'Online base backup from the
hot-standby' in PostgreSQL 9.2.
Todo : Allow hot file system backups on standby servers
(http://wiki.postgresql.org/wiki/Todo)
[GOAL]
* Make pg_basebackup to execute to the hot-standby server
and acquire online-base-backu
60 matches
Mail list logo
