I am looking into the SQL standard to try to determine precisely how the
CTE feature should behave.
Taking a simple case like:
with recursive
foo(i) as
(values(1)
union all
select i+1 from foo where i < 5)
select * from foo;
And looking at the SQL standard 200n 7.13: Ge
On Sun, Sep 7, 2008 at 9:52 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Whilst going through the pending patch to add TRUNCATE as a separate
> permission, I noticed that it neglected to add TRUNCATE to the various
> columns in information_schema that display privileges. I wonder whether
> we should
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
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
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
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
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
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
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
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
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
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
"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
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
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
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:
>
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
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
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
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
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
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
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
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
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
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
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
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
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.
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 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
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:
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
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
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,
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
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,
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
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 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
-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
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
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)
"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.
-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 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
"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
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
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 <[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
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
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
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
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
> (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
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
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,
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
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
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
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
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
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
> "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
> "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
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
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
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, 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
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
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
[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:
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
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
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)
> >
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
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
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
> "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
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.
>
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
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
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
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
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
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?
> "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
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
> "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
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,
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
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
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
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
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
>> * 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
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
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 <[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
1 - 100 of 102 matches
Mail list logo
