On Sat, May 28, 2011 at 09:33:09PM -0400, Robert Haas wrote:
On Fri, May 27, 2011 at 6:19 AM, Noah Misch n...@leadboat.com wrote:
So, it's ok to have a log item that is replayed only if
WalRcvInProgress()
is true?
No, that checks for WAL streaming in particular. ?A log-shipping
2011/5/29 Tom Lane t...@sss.pgh.pa.us:
Greg Stark gsst...@mit.edu writes:
On Sat, May 28, 2011 at 12:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I also found that Greg was right in thinking that it would help if we
tweaked lazy_scan_heap to not always scan the first
SKIP_PAGES_THRESHOLD-1 pages
On 05/29/2011 06:04 AM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, May 28, 2011 at 11:23 PM, Greg Sabino Mullane g...@turnstep.com
wrote:
My own bare bones wish list for such a tracker is:
* Runs on Postgres
* Has an email interface
Make no mistake, whichever we
On Sat, May 28, 2011 at 01:44:20PM -0400, Josh Kupershmidt wrote:
Anssi and I posted some initial feedback on the patch's goals earlier.
I would like to ultimately see users have the capability to
pg_cancel_backend() their own queries. But I could at least conceive
of others not wanting this
On sön, 2011-05-29 at 00:04 -0400, Tom Lane wrote:
Many, many, many bug issues are not associated with a bug report
submitted through the web interface. People mail stuff to pgsql-bugs
manually, or issues turn up in threads on other lists. If a tracker
can only find things submitted through
On sön, 2011-05-29 at 03:23 +, Greg Sabino Mullane wrote:
My own bare bones wish list for such a tracker is:
* Runs on Postgres
* Has an email interface
I will add
* Free/open source software
to that.
Here is a list to choose from:
On Wed, May 25, 2011 at 10:07:45PM +0300, Peter Eisentraut wrote:
On ons, 2011-04-27 at 18:14 -0400, Noah Misch wrote:
Enthusiastic +1 for this concept. There's at least one rough edge: it
fails if
you have another postmaster running on port 5432.
This has now been addressed:
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com writes:
2011/5/29 Tom Lane t...@sss.pgh.pa.us:
OK, do you like the attached version of that logic? (Other fragments
of the patch as before.)
The idea was that remove only one page from the VACUUM will prevent
relfrozenxid
On Sun, May 29, 2011 at 5:04 AM, Noah Misch n...@leadboat.com wrote:
What risks arise from unconditionally allowing these calls for the same user's
backends? `pg_cancel_backend' ought to be safe enough; the user always has
access to the standard cancellation protocol, making the SQL interface
Peter Eisentraut pete...@gmx.net writes:
That doesn't mean that better integration cannot be worked on later, but
this illusion that a bug tracker must have magical total awareness of
the entire flow of information in the project from day one is an
illusion and has blocked this business for
On Sun, May 29, 2011 at 8:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com
writes:
2011/5/29 Tom Lane t...@sss.pgh.pa.us:
OK, do you like the attached version of that logic? (Other fragments
of the patch as before.)
The idea
Pavan Deolasee pavan.deola...@gmail.com writes:
On Sun, May 29, 2011 at 8:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That would require proof, not just suggestion. Skipping pages will
defeat the OS read-ahead algorithm, and so could easily cost more than
reading them.
My worry is what we
On Fri, May 27, 2011 at 8:40 PM, Greg Stark gsst...@mit.edu wrote:
Separately it's a bit strange that we actually have to visit the
pages. We have all the information we need in the VM to determine
whether there's a run of 32 vacuum-clean pages. Why can't we look at
the next 32 pages and if
On Sun, May 29, 2011 at 9:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
On Sun, May 29, 2011 at 8:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That would require proof, not just suggestion. Skipping pages will
defeat the OS read-ahead algorithm, and so
Hi Tom,
On 05/29/2011 11:05 AM, Tom Lane wrote:
In the end, I think that requests for a tracker mostly come from people
who are not part of this community, or at least not part of its mailing
lists (which is about the same thing IMO).
I think that's a bit harsh. I assume you consider GSM a
Pavan Deolasee pavan.deola...@gmail.com writes:
I am sorry if I sounded terse above. But my gripe is that sometimes we
are too reluctant to listen to ideas and insist on producing some hard
numbers first which might take significant efforts. But we are not
equally strict when such changes are
On Sun, May 29, 2011 at 10:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
I am sorry if I sounded terse above. But my gripe is that sometimes we
are too reluctant to listen to ideas and insist on producing some hard
numbers first which might take
On 05/29/2011 05:47 PM, Joe Abbate wrote:
Hi Tom,
On 05/29/2011 11:05 AM, Tom Lane wrote:
In the end, I think that requests for a tracker mostly come from people
who are not part of this community, or at least not part of its mailing
lists (which is about the same thing IMO).
I think
If you use pgbench -S -M prepared at a scale where all data fits in
memory, most of what you are benchmarking is network/IPC chatter, and
table locking. Which is fine if that is what you want to do. This
patch adds a new transaction type of -P, which does the same thing as
-S but it moves the
On 05/29/2011 02:01 PM, Stefan Kaltenbrunner wrote:
feel free to reuse/edit the page as you like it(I have just removed the
notice) - the don't edit thingy was added because people started to
find the page via google (while searching for a tracker/bugreporting
tool) and considered it official
2011/5/29 Tom Lane t...@sss.pgh.pa.us:
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com
writes:
2011/5/29 Tom Lane t...@sss.pgh.pa.us:
OK, do you like the attached version of that logic? (Other fragments
of the patch as before.)
The idea was that remove only one page
On 05/29/2011 03:11 PM, Jeff Janes wrote:
If you use pgbench -S -M prepared at a scale where all data fits in
memory, most of what you are benchmarking is network/IPC chatter, and
table locking.
If you profile it, you'll find a large amount of the time is actually
spent doing more mundane
On Sun, May 29, 2011 at 3:36 PM, Joe Abbate j...@freedomcircle.com wrote:
Anyone interested in the tracker, please visit
http://wiki.postgresql.org/wiki/TrackerDiscussion and add your
feedback/input.
I think this illustrates exactly what we *don't* want to happen with a
bug tracker. We want
23 matches
Mail list logo
