On Sat, Sep 6, 2008 at 2:29 AM, Euler Taveira de Oliveira <[EMAIL PROTECTED]
> wrote:
> Martin Pihlak escreveu:
> > I suspected that, but somehow managed to overlook it :( I guess it was
> > too tempting to use it. I'll start looking for alternatives.
> >
> If you can't afford a 500 msec pgstat ti
Hi,
Fujii Masao wrote:
Pavan re-designed the sync replication based on the prototype
and I posted that design doc on wiki. Please check it if you
are interested in it.
http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects
I've read that wiki page and allow myself to comment from a Postg
On Thu, 4 Sep 2008, Simon Riggs wrote:
I think this should be organised with different kinds of reviewer...
Great post. Rewrote the intro a bit and turned it into a first bit of
reviewer training material at
http://wiki.postgresql.org/wiki/Reviewing_a_Patch
--
* Greg Smith [EMAIL PROTECTE
On Fri, 5 Sep 2008, Marko Kreen wrote:
I think we have better results and more relaxed atmospere if we
use following task description for reviewers:
I assimilated this and some of your later comments into
http://wiki.postgresql.org/wiki/Reviewing_a_Patch as well. I disagree
with your feelin
2008/8/5 ITAGAKI Takahiro <[EMAIL PROTECTED]>:
> Here is a patch to user NDirectFileRead/Write counters to get I/O counts
> in BufFile module. We can see the counters when log_statement_stats is on.
>
> The information is different from trace_sort; trace_sort shows used blocks
> in external sort, a
On Sat, 2008-09-06 at 04:03 -0400, Greg Smith wrote:
> On Thu, 4 Sep 2008, Simon Riggs wrote:
>
> > I think this should be organised with different kinds of reviewer...
>
> Great post. Rewrote the intro a bit and turned it into a first bit of
> reviewer training material at
> http://wiki.post
2008/9/5 Heikki Linnakangas <[EMAIL PROTECTED]>:
> Heikki Linnakangas wrote:
>>
>> I'll review the parser/planner changes from the current patch.
>
> Looks pretty sane to me. Few issues:
>
> Is it always OK to share a window between two separate window function
> invocations, if they both happen to
On Fri, 5 Sep 2008, Heikki Linnakangas wrote:
All in all, though. I find it a bit hard to see the big picture.
I've been working on trying to see that myself lately, have been dumping
links to all the interesting material at
http://wiki.postgresql.org/wiki/In-place_upgrade if there's any of
Hi,
this is my first "official" review. I've tried to follow the "Review a
patch" guidelines from the wiki - thanks Simon, that was pretty helpful.
This review covers only the intagg additions.
Dmitry Koterov wrote:
Here are these functions with detailed documentation:
http://en.dklab.ru/lib/d
What is the state of the following items? I'm a little confused about
whether or not work is being done on them.
. splitting pg_dump/pg_restore schema dumps into pre-data and post-data
sections
. parallel pg_restore
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
Hello Robert,
On Fri, Sep 5, 2008 at 8:13 PM, Robert Haas <[EMAIL PROTECTED]> wrote:
> Updated patch attached, based on comments from Ryan Bradetich and Tom
> Lane, and sync'd to latest CVS version.
Thanks for the update. I am out of town until tomorrow evening.
I will re-review this patch when
On Fri, 2008-09-05 at 15:23 -0400, Tom Lane wrote:
> How necessary is this given the recent fixes to allow the stats file to
> be kept on a ramdisk?
I would prefer this approach and back-out the other change.
On-demand is cheaper and easier to use.
> > Attached is a WIP patch, which basically
On Fri, 2008-09-05 at 23:21 +0900, Fujii Masao wrote:
> Pavan re-designed the sync replication based on the prototype
> and I posted that design doc on wiki. Please check it if you
> are interested in it.
> http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects
It's good to see the detaile
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2008-09-05 at 15:23 -0400, Tom Lane wrote:
>> How necessary is this given the recent fixes to allow the stats file to
>> be kept on a ramdisk?
> I would prefer this approach and back-out the other change.
Even if we get on-demand done, I wouldn't
Tom Lane escribió:
> (In fact, maybe this patch ought to include some sort of maximum update
> rate tunable? The worst case behavior could actually be WORSE than now.)
Some sort of "if stats were requested in the last 500 ms, just tell the
requester to read the existing file".
Things that come
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Some sort of "if stats were requested in the last 500 ms, just tell the
> requester to read the existing file".
Hmm, I was thinking of delaying both the write and the reply signal
until 500ms had elapsed. But the above behavior would certainly be
easie
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Sat, 2008-09-06 at 13:06 +0100, Gregory Stark wrote:
>> Is that right? The materialize is just doing the same writing that the final
>> pass of the sort would have been doing. Did we discount the costs for sort
>> for
>> that skipping writing that final
I wrote:
> ... define
> \ef with no argument as being the command that presents an empty CREATE
> FUNCTION command template to fill in.
No complaints? I'll go make that happen.
What about the general issue that neither \e nor \ef leave you with a
presentation of what's in the query buffer? I ha
At 2008-09-06 14:58:25 -0400, [EMAIL PROTECTED] wrote:
>
> I wrote:
> > ... define
> > \ef with no argument as being the command that presents an empty
> > CREATE FUNCTION command template to fill in.
>
> No complaints? I'll go make that happen.
No complaints, it sounds fine to me.
> What about
Too frequent read protection is already handled in the patch but these
comments might lead it into new directions. Current implementation had this
same limit that file was written no more than once per 500 ms.
On Sat, Sep 6, 2008 at 9:12 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera <[
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Thu, Sep 04, 2008 at 09:54:02PM +0100, Simon Riggs wrote:
> > * coding review - does it follow standard code guidelines? Are there
> > portability issues? Will it work on Windows/BSD etc? Are there
> > sufficient comments?
> >
> >
Heikki Linnakangas wrote:
> > 4) This patch contains more topics for decision. First is general if
> > this approach is acceptable.
>
> I don't like the invasiveness of this approach. It's pretty invasive
> already, and ISTM you'll need similar switch-case handling of all data
> types that have
So according to
http://wiki.postgresql.org/index.php?title=CommitFest&action=history
there's been rather a lot of confusion about where the CommitFest
redirect page should point when.
I think the problem is that we need two redirect pages: one for "the
place where you should submit a new patch" an
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Some sort of "if stats were requested in the last 500 ms, just tell the
> requester to read the existing file".
> Things that come to mind:
> - autovacuum could use a more frequent stats update in certain cases
BTW, we could implement that by, instead
Tom Lane wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > On Sat, Sep 6, 2008 at 10:10 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> ... I changed
> >> the exit code to PSQL_CMD_NEWEDIT instead of PSQL_CMD_SEND, which causes
> >> the command to wait in the query buffer.
>
> > The principle o
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> What is the state of the following items? I'm a little confused about
> whether or not work is being done on them.
> . splitting pg_dump/pg_restore schema dumps into pre-data and post-data
> sections
A patch for that was proposed and rejected in the
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > - Maybe we oughta have separate files, one for each database? That way
> > we'd reduce unnecessary I/O traffic for both the reader and the writer.
>
> The signaling would become way too complex, I think. Also what do you
> do a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
>>> The principle of least astonishment suggests that \ef should behave in
>>> the same way as \e.
>>
>> Quite.
> So, are they consistent now or do we need another patch?
They are consistent
Tom Lane wrote:
> So according to
> http://wiki.postgresql.org/index.php?title=CommitFest&action=history
> there's been rather a lot of confusion about where the CommitFest
> redirect page should point when.
>
> I think the problem is that we need two redirect pages: one for "the
> place where you
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> As for signalling, maybe we could implement something like we do for the
> postmaster signal stuff: the requestor stores a dbid in shared memory
> and sends a SIGUSR2 to pgstat or some such.
No, no, no. Martin already had a perfectly sane design for th
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I suggest two redirects CommitFestInProgress and CommitFestOpen, and
> turning CommitFest into a plain page with suitable text pointing to both
> redirects.
> We'd also need a page saying "there is no commitfest currently in
> progress; maybe you wanted
Abhijit Menon-Sen wrote:
> At 2008-09-06 14:58:25 -0400, [EMAIL PROTECTED] wrote:
> > What about the general issue that neither \e nor \ef leave you with a
> > presentation of what's in the query buffer?
>
> I don't know how that can be fixed; but I agree with Brendan that it's
> behaviour that p
I wrote:
> No, no, no. Martin already had a perfectly sane design for that
> direction of signalling: send a special stats message to the collector.
Actually ... given that the stats message mechanism is designed to be
lossy under high load, maybe that isn't so sane. At the very least
there woul
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> On Thu, Aug 7, 2008 at 3:08 AM, Abhijit Menon-Sen <[EMAIL PROTECTED]> wrote:
>> I just noticed, to my dismay, that has_table_privilege() does not allow
>> me to check for usage privileges on sequences.
> Maybe we want a new function has_sequence_privi
Alvaro Herrera wrote:
> Abhijit Menon-Sen wrote:
> > At 2008-09-06 14:58:25 -0400, [EMAIL PROTECTED] wrote:
>
> > > What about the general issue that neither \e nor \ef leave you with a
> > > presentation of what's in the query buffer?
> >
> > I don't know how that can be fixed; but I agree with
Markus Wanner <[EMAIL PROTECTED]> writes:
> Submission review: we generally prefer having patches archived on our
> mailing lists, so please just send future patches or revisions of this
> patch to our lists (I prefer -hackers, but probably -patches is still
> the official one).
Please. But -patc
<<>>
Tom Lane wrote:
> I wrote:
> > I looked this over a bit and was immediately confused by one thing:
> > the introductory comment says that the skip table size ought to be based
> > on the length of the haystack, which makes sense to me, but the code is
> > actually initializing it on the basis
Markus Wanner wrote:
> > Hook for WALSender
> > --
> > This hook is for introducing WALSender. There are the following
> > three ideas of how to introduce WALSender. A required hook
> > differs by which idea is adopted.
> >
> > a) Use WALWriter as WALSender
> >
> >This idea ne
> On Thu, 2008-09-04 at 10:45 -0700, Josh Berkus wrote:
> > We currently have 38 patches pending, and only nine people reviewing
> them.
> > At this rate, the September commitfest will take three months.
>
> > If you are a postgresql hacker at all, or even want to be one, we need
> your
> > help
"David Rowley" <[EMAIL PROTECTED]> writes:
> I've made the discussed changes. Also updated the benchmark results.
> http://www.unixbeast.com/~fat/8.3_test_v1.3.xls
Applied with revisions; mostly cosmetic except for one point. I
realized after studying the code a bit more that B-M cannot possibly
When I build from CVS I wind up with this in my CVS update email in the
morning:
? GNUmakefile
? config.log
? config.status
? src/Makefile.global
? src/backend/postgres
? src/backend/bootstrap/bootstrap_tokens.h
? src/backend/catalog/postgres.bki
? src/backend/catalog/postgres.description
? src/ba
41 matches
Mail list logo
