On Tue, 2008-09-09 at 13:45 +0900, Tatsuo Ishii wrote:
> Thanks for the review.
>
> > The standard specifies that non-recursive WITH should be evaluated
> > once.
>
> What shall we do? I don't think there's a easy way to fix this. Maybe
> we should not allow WITH clause without RECURISVE?
My
"Fujii Masao" <[EMAIL PROTECTED]> wrote:
> 3) Patch of introducing new background process which I've called
> WALSender. It takes charge of sending WAL to the slave.
>
> Now, I assume that WALSender also listens the connection from
> the slave, i.e. only one sender process manages
On Mon, 8 Sep 2008, Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Modified as you suggested. BTW, will there be a similar i18n scenario
>> for "dropped column" you mentioned below?
>
> Yes, you need _() around those too.
For this purpose, I introduced a dropped_column_type variable in
validate_tup
Hi,
I looked some comment for the synchronous replication and understood
the consensus of the community was that the sync replication should be
added using not hooks and plug-ins but core-patches. If my understanding
is right, I will change my development plan so that the sync replication
may be p
On Mon, 8 Sep 2008, Alvaro Herrera wrote:
(I dropped the "default" stuff for now, as it doesn't seem that a
consensus has been reached on that topic.)
I have multiple GUC-related projects that are all stalled waiting for that
capability to be added. The only thing there wasn't clear consensu
>> * Single Evaluation:
>>
>> with
>> foo(i) as (select random() as i)
>> select * from foo union all select * from foo;
>>i
>> ---
>>0.233165248762816
>> 0.62126633618027
>> (2 rows)
>>
>> The standard specifies that non-recursive WITH should be ev
Thanks for the review.
[I dropped [EMAIL PROTECTED] from the Cc list since he has left our
company and the email address is being deleted.]
I'm going to look into issues which are seem to be bug (of course if
you know what to fix, patches are always welcome:-).
> These are my initial comments ab
Thanks for the review.
[I dropped [EMAIL PROTECTED] from the Cc list since he has left our
company and the email address is being deleted.]
I'm going to look into issues which are seem to be bug (of course if
you know what to fix, patches are always welcome:-).
> These are my initial comments ab
On Tue, 2008-09-09 at 01:45 +0100, Andrew Gierth wrote:
> The "contains" language in the spec is tricky. And I think there's some
> issue here with the spec confusing and expression body>; some of the language refers to "If a
> AQEk not marked as recursive is immediately contained in a expressi
On Mon, 8 Sep 2008 10:32:40 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Gregory Stark wrote:
> > "Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> >
> > > Tom Lane wrote:
> > >> My vote is to reject the patch and work on a config checker.
> > >
> > > +1
+1
Joshua D. Drake
--
The Post
Marko Kreen wrote:
Thirdly, please don't use "standard units" argument, unless you plan to
propose use of "KiB, MiB, GiB" at the same moment.
In defense of standard units, if the postgres docs say
"Postgres will round up to the nearest power of 2"
kB and MB seem very clear to me. If we want
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> > Hmm, I didn't recheck after Greg's patch, but in mine, it doesn't,
> > because the location is saved as "reset location" and restored when the
> > variable is reset. It worked fine in all cases I tested.
>
> Hmm
Greetings,
I've reviewed the patch here:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
and am happy to report that it looks to be in good order. It has
documentation and regression updates, is in context diff format,
patches against current CVS with only some minor fuzz,
> "Alvaro" == Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> so it's like this:
>>
>> select * from foo order by bar offset 5 rows fetch first 10 rows only;
Alvaro> Oh, I see -- it's just a cumbersome way to have our LIMIT
Alvaro> clause. What's the "ONLY" for?
It seems to be just a ma
Andrew Gierth wrote:
> Alvaro> This means we have to support stuff like
>
> Alvaro> declare foo cursor for select * from lists;
> Alvaro> select * from (fetch first from foo) as bar;
>
> No, that's wrong.
[...]
> so it's like this:
>
> select * from foo order by bar offset 5 rows fetch fir
> "Jeff" == Jeff Davis <[EMAIL PROTECTED]> writes:
Jeff> I am looking into the SQL standard to try to determine
Jeff> precisely how the CTE feature should behave.
Jeff> Taking a simple case like:
Jeff> with recursive
Jeff> foo(i) as
Jeff> (values(1)
Jeff> union all
Volkan YAZICI wrote:
> On Fri, 05 Sep 2008, Tom Lane <[EMAIL PROTECTED]> writes:
> > at the call sites, and then
> >
> > errmsg("%s", _(msg))
> >
> > when throwing the error.
>
> Modified as you suggested. BTW, will there be a similar i18n scenario
> for "dropped column" you mentioned below?
Martin Pihlak escribió:
> Tom Lane wrote:
> > Hmm. With the timestamp in the file, ISTM that we could put all the
> > intelligence on the reader side. Reader checks file, sends message if
> Attached is a patch that implements the described signalling.
Are we keeping the idea that the reader sen
Markus Wanner wrote:
> Hi,
>
> Bruce Momjian wrote:
> > Backends would
> > update a shared memory variable specifying how far they want the wal
> > streamer to advance and send a signal to the wal streamer if necessary.
> > Backends would monitor another shared memory variable that specifies how
Hi,
Bruce Momjian wrote:
Backends would
update a shared memory variable specifying how far they want the wal
streamer to advance and send a signal to the wal streamer if necessary.
Backends would monitor another shared memory variable that specifies how
far the wal streamer has advanced.
Tha
Alvaro Herrera wrote:
> So I just noticed that we have a description of the Pg innards in the
> sourcecode, complete with a flowchart and all, at src/tools/backend.
> I had already seen this graph years ago; what shocked me the most was
> finding out that there's a pointer to it in the Developer's
Zdenek Kotala wrote:
> You mentioned data types, but it is not a problem. You can easily extend data
> type attribute about version information and call correct in/out functions.
> Or
> use different Oid for new data type version. There are more possible easy
> solutions for data types. And for
On Mon, 2008-09-08 at 22:53 +0100, Andrew Gierth wrote:
> Yes, you've misinterpreted. When the spec says that a query "shall
> not" do such-and-such, it means that a conforming client isn't allowed
> to do that, it does NOT mean that the server is required to produce an
> error when it sees it.
>
> "Jeff" == Jeff Davis <[EMAIL PROTECTED]> writes:
Jeff> Aggregates should be blocked according to the standard.
Jeff> Also, causes an infinite loop. This should be fixed for 8.4.
>> Does the standard require anywhere that non-conforming statements
>> must be diagnosed? (seems impractical
Fujii Masao wrote:
> On Mon, Sep 8, 2008 at 8:44 PM, Markus Wanner <[EMAIL PROTECTED]> wrote:
> >>Merge into WAL writer?
> >
> > Uh.. that would mean you'd loose parallelism between WAL writing to disk and
> > WAL shipping via network. That does not sound appealing to me.
>
> That depends
Tom Lane wrote:
> Hmm. With the timestamp in the file, ISTM that we could put all the
> intelligence on the reader side. Reader checks file, sends message if
... snip ...
> remember the file timestamp it last wrote out. There are various ways
> you could design it but what comes to mind here is
On Mon, 2008-09-08 at 18:08 +0100, Andrew Gierth wrote:
> Jeff> * Mutual Recursion:
>
> This limitation isn't at all uncommon in other implementations; DB2
> docs for example say:
As with some other things in my list, this doesn't need to be supported
in 8.4. I just wanted to lay out my interpre
On Mon, 2008-09-08 at 21:13 +0100, Gregory Stark wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
>
> > * Mutual Recursion:
> >
> > with recursive
> > foo(i) as (values(1) union all select i+1 from bar where i < 10),
> > bar(i) as (values(1) union all select i+1 from foo where i < 10)
> >
Jeff Davis <[EMAIL PROTECTED]> writes:
> * Mutual Recursion:
>
> with recursive
> foo(i) as (values(1) union all select i+1 from bar where i < 10),
> bar(i) as (values(1) union all select i+1 from foo where i < 10)
> select * from foo;
> ERROR: mutual recursive call is not supporte
I've been looking at
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
and am not very happy with it. One big problem is that it has the
parser collecting the list of functions referenced by a plan, which
is quite bogus --- consider functions introduced into the tree during
rewrite, or b
[EMAIL PROTECTED] (hubert depesz lubaczewski) writes:
> On Mon, Sep 08, 2008 at 11:20:18AM -0400, Chris Browne wrote:
>> I've got a case where I need to reverse strings, and find that, oddly
>> enough, there isn't a C-based reverse() function.
>> A search turns up pl/pgsql and SQL implementations:
Heikki Linnakangas wrote:
> David Rowley wrote:
> Thanks for all the reviews and suggestions.
> David, could you re-run the performance tests you ran earlier? I'm
> curious to know what impact switching to the simpler loop for 1-byte
> pattern had.
Sure: http://www.unixbeast.com/~fat/8.3_test_v
Settings in postgresql.conf are currently case-insensitive. Except
for the units.
And, of course, filenames when you are using a case-sensitive
filesystem. Because these are things that are defined by some
convention other than the ones the PGDG made up. Since units fall
into that category, it
On Mon, 2008-09-08 at 19:19 +0900, ITAGAKI Takahiro wrote:
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > > > b) Use new background process as WALSender
> > > >
> > > >This idea needs background-process hook which enables users
> > > >to define new background processes
>
> > I think s
Simon Riggs <[EMAIL PROTECTED]> writes:
>> So thinking we should test XLogArchiveCheckDone() for both
>> stopxlogfilename and history file and then stat for the stop WAL file:
> This seems better.
Somehow I missed the 5-Apr patch that introduced this bogosity.
Next time you make a fundamental cha
On Mon, Sep 8, 2008 at 6:59 PM, ITAGAKI Takahiro
<[EMAIL PROTECTED]> wrote:
> Here is a revised version of the pgbench duration patch.
> I merged some comments from Brendan and gnari.
>
The changes look good. I tried out the new v3 patch and didn't
encounter any problems.
One last minor quibble
On Mon, Sep 8, 2008 at 6:24 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 7, 2008 at 5:58 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
>> Code review: one minor nit
>> *** a/src/backend/utils/adt/formatting.c
>> --- b/src/backend/utils/adt/formatting.c
>> ***
>> *** 781,787
> "Jeff" == Jeff Davis <[EMAIL PROTECTED]> writes:
Jeff> * Mutual Recursion:
This limitation isn't at all uncommon in other implementations; DB2
docs for example say:
"If more than one common table expression is defined in the same
statement, cyclic references between the common table expre
> "Alvaro" == Alvaro Herrera <[EMAIL PROTECTED]> writes:
Alvaro> Wow, this is really horrid:
Alvaro> # F856 through F859: FETCH FIRST clause in subqueries,
Alvaro> views, and query expressions. The SQL:2008 syntax for
Alvaro> restricting the rows of a result set is FETCH FIRST, rather
Pavel Stehule escribió:
> Hello
>
> I found one usefull article
> http://iablog.sybase.com/paulley/2008/07/sql2008-now-an-approved-iso-international-standard/
Wow, this is really horrid:
# F856 through F859: FETCH FIRST clause in subqueries, views,
and query expressions. The SQL
Simon Riggs <[EMAIL PROTECTED]> writes:
> You sound like you're in the middle of doing this yourself. Or would you
> like me to do that?
Yeah, done and committed.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
Hello
I found one usefull article
http://iablog.sybase.com/paulley/2008/07/sql2008-now-an-approved-iso-international-standard/
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgs
2008/9/8 Andrew Dunstan <[EMAIL PROTECTED]>:
>
>
> Mario Weilguni wrote:
>>>
>>> (Aside: presumably we could walk thru the string destructively,
>>> in-place, swapping bytes; I think that would be theoretically
>>> quickest...)
>>>
>>
>> Hmmm... I guess it will not work für UTF-8 or any other multi
On Mon, 2008-09-08 at 11:57 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> >> So thinking we should test XLogArchiveCheckDone() for both
> >> stopxlogfilename and history file and then stat for the stop WAL file:
>
> > This seems better.
>
> Somehow I missed the 5-Apr patch t
Mario Weilguni wrote:
(Aside: presumably we could walk thru the string destructively,
in-place, swapping bytes; I think that would be theoretically
quickest...)
Hmmm... I guess it will not work für UTF-8 or any other multibyte charset
Yes, quite.
Perl's reverse might work with UT
Hello
2008/9/8 Mario Weilguni <[EMAIL PROTECTED]>:
>> (Aside: presumably we could walk thru the string destructively,
>> in-place, swapping bytes; I think that would be theoretically
>> quickest...)
>
> Hmmm... I guess it will not work für UTF-8 or any other multibyte charset
>
it isn't problem,
On Mon, Sep 08, 2008 at 11:20:18AM -0400, Chris Browne wrote:
> I've got a case where I need to reverse strings, and find that, oddly
> enough, there isn't a C-based reverse() function.
> A search turns up pl/pgsql and SQL implementations:
just for completenes - there is also pl/perl and c version
> (Aside: presumably we could walk thru the string destructively,
> in-place, swapping bytes; I think that would be theoretically
> quickest...)
Hmmm... I guess it will not work für UTF-8 or any other multibyte charset
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
I've got a case where I need to reverse strings, and find that, oddly
enough, there isn't a C-based reverse() function.
A search turns up pl/pgsql and SQL implementations:
create or replace function reverse_string(text) returns text as $$
DECLARE
reversed_string text;
incoming alias for $1;
BEGIN
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>>> It's good as a joke, but what if the user says '1024b'? Does it mean
>>> 1024 blocks or one kilobyte? If blocks, what size are we talking, the
>>> usual 512 bytes, o
These are my initial comments about the Common Table Expressions (CTE)
patch, also known as WITH [RECURSIVE]. These comments are based on the
patch here:
http://archives.postgresql.org/pgsql-patches/2008-08/msg00021.php
This is a semantically complex feature, and the standard is fairly
complex a
Hi,
Fujii Masao wrote:
1. A backend writes WAL to disk.
2. The backend wakes up WAL sender process and sleeps.
3. WAL sender process does WAL shipping and wakes up the backend.
4. The backend issues sync command.
Right, that would work. But still, the WAL writer process would block
during wri
Gregory Stark <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> It's good as a joke, but what if the user says '1024b'? Does it mean
>> 1024 blocks or one kilobyte? If blocks, what size are we talking, the
>> usual 512 bytes, or our BLCKSZ?
> For what guc would you find
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> It's good as a joke, but what if the user says '1024b'? Does it mean
> 1024 blocks or one kilobyte? If blocks, what size are we talking, the
> usual 512 bytes, or our BLCKSZ?
For what guc would you find a unit of posix-style "blocks" relevant?!
--
Gregory Stark wrote:
> "Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
>
> > Tom Lane wrote:
> >> My vote is to reject the patch and work on a config checker.
> >
> > +1
> >
> >> postgres=# set work_mem = '1g';
> >> ERROR: invalid value for parameter "work_mem": "1g"
> >
> > Perhaps this would b
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> My vote is to reject the patch and work on a config checker.
>
> +1
>
>> postgres=# set work_mem = '1g';
>> ERROR: invalid value for parameter "work_mem": "1g"
>
> Perhaps this would be a great place for a HINT listing all
> va
Greg Sabino Mullane wrote:
> Tom Lane wrote:
> > postgres=# set work_mem = '1g';
> > ERROR: invalid value for parameter "work_mem": "1g"
>
> Perhaps this would be a great place for a HINT listing all
> valid inputs, if not there already?
alvherre=# set work_mem = '1g';
ERROR: invalid value for
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane wrote:
> My vote is to reject the patch and work on a config checker.
+1
> postgres=# set work_mem = '1g';
> ERROR: invalid value for parameter "work_mem": "1g"
Perhaps this would be a great place for a HINT listing all
valid inputs,
"Greg Stark" <[EMAIL PROTECTED]> writes:
> On Mon, Sep 8, 2008 at 2:11 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> But of course case insensitivity isn't going to fix that example for you.
>> So we're right back at the question of where we should draw the line in
>> trying to accept variant input.
Martin Pihlak <[EMAIL PROTECTED]> writes:
> Attached is a patch which adds a timestamp to pgstat.stat file header,
> backend_read_statsfile uses this to determine if the file is fresh.
> During the wait loop, the stats request message is retransmitted to
> compensate for possible loss of message(s)
On Mon, Sep 8, 2008 at 8:44 PM, Markus Wanner <[EMAIL PROTECTED]> wrote:
>>Merge into WAL writer?
>
> Uh.. that would mean you'd loose parallelism between WAL writing to disk and
> WAL shipping via network. That does not sound appealing to me.
That depends on the order of WAL writing and W
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Sep 08, 2008 at 02:18:55PM +0100, Greg Stark wrote:
> On Mon, Sep 8, 2008 at 2:11 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > But of course case insensitivity isn't going to fix that example for you.
> > So we're right back at the question of w
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Another idea is to create backward compatible AM and put them into separate
library. If these AM will work also with old page structure then there should
not be reason for reindexing or index page conversion after upgrade.
I don't
On Mon, Sep 8, 2008 at 2:11 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> But of course case insensitivity isn't going to fix that example for you.
> So we're right back at the question of where we should draw the line in
> trying to accept variant input.
Well it's not a perfect precedent but for exam
Tom Lane wrote:
> Timestamp within the file is certainly better than trying to rely on
> filesystem timestamps. I doubt 1 sec resolution is good enough, and
> I'd also be worried about issues like clock skew between the
> postmaster's time and the filesystem's time.
>
Attached is a patch which a
M2Y escribió:
> On Sep 7, 11:52 pm, [EMAIL PROTECTED] (Shane Ambler) wrote:
> > > What is a good way to start understanding backend(postgres) code? Is
> > > there any documentation available especially for developers?
> > > What is commit log and why it is needed?
> >
> > To achieve ACID (Atomic,
Gregory Stark <[EMAIL PROTECTED]> writes:
> I'm all for using the correct acronyms in all messages and documentation. What
> I find annoying is the:
> postgres=# set work_mem = '1g';
> ERROR: invalid value for parameter "work_mem": "1g"
But of course case insensitivity isn't going to fix that exa
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Relation forks didn't change anything inside relation files, so no
scanning of relations is required because of that. Neither will the
FSM rewrite. Not sure about DSM yet.
Does it mean, that if you "inject" old
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> I'd also be worried about issues like clock skew between the
>>> postmaster's time and the filesystem's time.
>
>> Can that even happen on a local filesystem? I guess you could put the
>> file on NFS though, but t
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Tom Lane napsal(a):
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
In fact, I don't think there's any low-level data format changes yet
between 8.3 and 8.4, so this would be a comparatively easy release
to implement upgrade-in-place. There's
Simon Riggs <[EMAIL PROTECTED]> writes:
> Peter's objection is reasonable, as far as most people have replied.
> Marko's proposal is also reasonable to most people, since they do not
> wish fat fingers to cause any amount of downtime. ISTM that if you've
> done this, you appreciate the feature, if
Gregory Stark <[EMAIL PROTECTED]> writes:
> Yeah, I've been thinking about how to use the planner to do this.
I thought the answer to that was going to be more or less "call
cost_sort() and cost_index() and compare the answers".
> To do that it seems to me what we would need to do is add a functi
Simon Riggs <[EMAIL PROTECTED]> writes:
> Peter's objection is reasonable, as far as most people have replied.
> Marko's proposal is also reasonable to most people, since they do not
> wish fat fingers to cause any amount of downtime. ISTM that if you've
> done this, you appreciate the feature, if
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> The bpchar_pattern_ops change you mentioned must be this one:
>> A not-immediately-obvious incompatibility is that the sort order within
>> bpchar_pattern_ops indexes changes --- it had been identical to plain
>> strcmp, but is now trailing-blank-ins
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Another idea is to create backward compatible AM and put them into separate
> library. If these AM will work also with old page structure then there should
> not be reason for reindexing or index page conversion after upgrade.
I don't think that'd be re
M2Y <[EMAIL PROTECTED]> writes:
> On Sep 7, 11:52 pm, [EMAIL PROTECTED] (Shane Ambler) wrote:
>> Most of the developer info is within comments in the code itself.
>> Another place to start ishttp://www.postgresql.org/developer/coding
>>
> I have seen this link. But, I am looking(or hoping) for any
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'd also be worried about issues like clock skew between the
>> postmaster's time and the filesystem's time.
> Can that even happen on a local filesystem? I guess you could put the
> file on NFS though, but that seems to be.. eh. sub
Hi,
ITAGAKI Takahiro wrote:
1. Is process-switching approach the best way to share one socket?
Both Postgres-R and the log-shipping prototype use the approach now.
Can I think there is no objection here?
I don't see any appealing alternative. The postmaster certainly
shouldn
Hi,
On Sun, 2008-09-07 at 13:39 -0400, Andrew Dunstan wrote:
> The point I was making is that for 8.4, unless you specifically
> configure with --disable-integer-datetimes, it is enabled by default on
> any platform that can support it. We committed that change on 30 March
> here: http://archi
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> I think there needs to be an option to force this to do either sorts or
>> indexscans.
>
> If we use the planner, "set enable_indexscan =off" or "set enable_sort=off"
> ought to work.
Yeah, I've been thinking about how to us
Markus Wanner <[EMAIL PROTECTED]> wrote:
> ITAGAKI Takahiro wrote:
> > Are there any better idea to share one socket connection between
> > backends (and bgwriter)?
>
> I fear I'm repeating myself, but I've had the same problem for
> Postgres-R and solved it with an internal message passing infr
On Mon, 2008-09-08 at 13:52 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > I think there needs to be an option to force this to do either sorts or
> > indexscans.
>
> If we use the planner, "set enable_indexscan =off" or "set
> enable_sort=off" ought to work.
Agreed - as long as tha
On Wed, 2008-09-03 at 11:58 +0300, Asko Oja wrote:
> On Wed, Sep 3, 2008 at 11:20 AM, Heikki Linnakangas
> <[EMAIL PROTECTED]> wrote:
> Marko Kreen wrote:
> On 9/2/08, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Marko Kreen wrote:
>
Simon Riggs wrote:
I think there needs to be an option to force this to do either sorts or
indexscans.
If we use the planner, "set enable_indexscan =off" or "set
enable_sort=off" ought to work.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers m
Hi,
ITAGAKI Takahiro wrote:
Are there any better idea to share one socket connection between
backends (and bgwriter)? The connections could be established after
fork() from postmaster, and number of them could be two or more.
This is one of the most complicated part of synchronous log shipping.
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > > b) Use new background process as WALSender
> > >
> > >This idea needs background-process hook which enables users
> > >to define new background processes
> I think starting/stopping a process for each WAL send is too much
> overhead.
Yes,
"Hitoshi Harada" <[EMAIL PROTECTED]> wrote:
> so I guess all of these variables should be defined together but
> actually you put the two in buffile.h while the others in
> buf_internals.h. Is there clear reason for that?
That's because buffile.c includes buffile.h, but not buf_internals.h .
NDi
Zdenek Kotala wrote:
Tom Lane napsal(a):
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
In fact, I don't think there's any low-level data format changes yet
between 8.3 and 8.4, so this would be a comparatively easy release to
implement upgrade-in-place. There's just the catalog changes, but
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Relation forks didn't change anything inside relation files, so no
scanning of relations is required because of that. Neither will the
FSM rewrite. Not sure about DSM yet.
Does it mean, that if you "inject" old data file after catalog upgrade
Here is a revised version of the pgbench duration patch.
I merged some comments from Brendan and gnari.
"Brendan Jurd" <[EMAIL PROTECTED]> wrote:
> >> Wouldn't this be better written as:
> >> if ((duration > 0 && timer_exceeded) || st->cnt >= nxacts)
> >
> > sorry, but these do not lok as the s
Heikki Linnakangas napsal(a):
Tom Lane wrote:
I didn't see anything that looked like an immediate change in user table
contents, unless they used the "name" type; but what of relation forks?
Relation forks didn't change anything inside relation files, so no
scanning of relations is required b
Tom Lane napsal(a):
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
In fact, I don't think there's any low-level data format changes yet
between 8.3 and 8.4, so this would be a comparatively easy release to
implement upgrade-in-place. There's just the catalog changes, but AFAICS
nothing that wo
On Sun, Sep 7, 2008 at 5:58 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> Im just following this:
> http://wiki.postgresql.org/wiki/Reviewing_a_Patch so lets get started.
>
Hi Alex. Thanks for taking the time to review my patch.
> Feature test: Everything seems to work as advertised. However be
Bruce Momjian napsal(a):
Heikki Linnakangas wrote:
Bruce Momjian wrote:
As far as the page not fitting after conversion, what about some user
command that will convert an entire table to the new format if page
expansion fails.
VACUUM?
Having to run a manual command defeats the purpose somewha
Bruce Momjian napsal(a):
As far as the page not fitting after conversion, what about some user
command that will convert an entire table to the new format if page
expansion fails.
Keep in a mind that there are more kind of pages. Heap is easy, but each index
AM has own specific :(. Better app
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
The patch seems to be missing the new htup.c file.
I'm sorry. I attached new version which is synchronized with current
head. I would like to say more comments as well.
1) The patch contains also changes which w
Thanks Shane for your response...
On Sep 7, 11:52 pm, [EMAIL PROTECTED] (Shane Ambler) wrote:
> > What is a good way to start understanding backend(postgres) code? Is
> > there any documentation available especially for developers?
>
> Most of the developer info is within comments in the code itse
Tom Lane wrote:
> Martin Pihlak <[EMAIL PROTECTED]> writes:
>> I had also previously experimented with stat() based polling but ran into
>> the same issues - no portable high resolution timestamp on files. I guess
>> stat() is unusable unless we can live with 1 second update interval for the
>> sta
Martin Pihlak wrote:
> Magnus Hagander wrote:
>> I wrote a patch for this some time back, that was actually applied.
>> Turns out it didn't work, and I ran out of time to fix it, so it was
>> backed out again. And then I forgot about it :-) If you look through the
>> cvs history of pgstat you shoul
David Rowley wrote:
Thanks for all the reviews and suggestions.
David, could you re-run the performance tests you ran earlier? I'm
curious to know what impact switching to the simpler loop for 1-byte
pattern had.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent
1 - 100 of 102 matches
Mail list logo
