I'm getting "CONTINUE cannot be used outside a loop" errors even
though it's inside a loop. The error appears to be happening when
CONTINUE passes control to the beginning of the loop but there's
no more iterating to be done. I'd expect the loop to end at this
point instead of getting an error.
Bruce Momjian wrote:
We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a feature freeze
on July 1.
It would be nice to upgrade to autoconf 2.59 before the freeze (although
it would probably be okay to do this post-free
Tom Lane wrote:
The long-term point in my mind is that removing syntactical
redundancy always reduces the ability to detect errors or report
errors acccurately
Lexical scoping is unambiguous in a language like PL/PgSQL. Since it is
simple to determine whether a given END matches an IF, LOOP, o
Andrew Dunstan wrote:
I'm unkeen. I see no technical advantage - it's just a matter of taste.
There is no "technical advantage" to case insensitive keywords, or
dollar quoting, or a variety of other programming language features that
don't change functionality but exist to make using the prog
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> If this diagnosis were correct, wouldn't every buildfarm member be failing
> at the ContribCheck stage (if they get that far)?
I am way too tired right now to run down the details, but there is a
series of possibilities for the port libpq will try to
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Neil Conway said:
>> Any objections?
> I'm unkeen. I see no technical advantage - it's just a matter of taste. We
> advertise that plpgsql is similar to plsql - we should not do anything to
> make that less so IMNSHO. Terseness is not always good, red
Tom Lane said:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>> It appears that the dblink regression test defaults to port 5432. I've
>> been trying to get platypus to compile clean on HEAD and 8_0 and it's
>> been failing on dblink.
>
> There are several buildfarm machines failing like this. I th
On Tue, 21 Jun 2005, Bruce Momjian wrote:
I am not aware they were all addressed, and if you had terminate in
there, which was clearly not addressed, I question whether the others
issues are addressed too. I think we need to re-discuss the idea of
these functions.
Just curious, but if 'all
On Tue, 2005-06-21 at 23:34 -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> In any case the correct way to solve the problem is to find out what's
> >> being left corrupt by SIGTERM, rather than install more messiness in
> >> order to avoid facing the real issue ...
>
> >
Neil Conway said:
> In PL/PgSQL, "END LOOP" is used to terminate loop blocks, and "END IF"
> is used to terminate IF blocks. This is needlessly verbose: we could
> simply accept "END" in both cases without syntactic ambiguity. I'd like
> to make this change, so that END can be used to terminate an
Tom Lane wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
It appears that the dblink regression test defaults to port 5432. I've
been trying to get platypus to compile clean on HEAD and 8_0 and it's
been failing on dblink.
There are several buildfarm machines failing like this. I think a
p
Bruce Momjian writes:
> Tom Lane wrote:
>> In any case the correct way to solve the problem is to find out what's
>> being left corrupt by SIGTERM, rather than install more messiness in
>> order to avoid facing the real issue ...
> I am confused. Are you talking about the client SIGTERM or the s
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> It appears that the dblink regression test defaults to port 5432. I've
> been trying to get platypus to compile clean on HEAD and 8_0 and it's
> been failing on dblink.
There are several buildfarm machines failing like this. I think a
possible solution
Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > But it still requires me to send some data (such as a dummy query) to
> > the backend before it exits. This is because server side libpq blocks
> > when reading and ignores signals at this time. I believe the fix for
> > this would
On Tue, 21 Jun 2005, Tom Lane wrote:
> Pavel Stehule <[EMAIL PROTECTED]> writes:
> > I wont to prohibit synonyms in exception (every exception has unique
> > sqlstate).
>
> I don't think that's a particularly good idea --- maybe if SQL had been
> designed according to your worldview, it'd be lik
Andreas Pflug wrote:
> Bruce Momjian wrote:
> > Dave Page wrote:
> >
> > Basically, Andreas' approach for 8.0 was to develop a patch (without
> > posting a proposal or interface), and then argue why pgadmin needs it,
> > but without addressing the real concerns about the patch.
>
> Extending the
Josh Berkus writes:
> Oh, and in implementing the COPY stuff we realized that there weren't any
> regression tests for encodings. If we can figure out how to do them,
> we'll add those. Are new regression tests permitted during beta?
Certainly. Feature freeze is about features, not correctn
Neil,
> In PL/PgSQL, "END LOOP" is used to terminate loop blocks, and "END IF"
> is used to terminate IF blocks. This is needlessly verbose: we could
> simply accept "END" in both cases without syntactic ambiguity. I'd like
> to make this change, so that END can be used to terminate any kind of
>
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> Sounds good to me... just wondering where dblink went? Is it going to
> remain a part of the dist?
dblink stays, and so does anything else I didn't mention.
(There are actually various proposals to do additional things, but
these (a) require actua
In PL/PgSQL, "END LOOP" is used to terminate loop blocks, and "END IF"
is used to terminate IF blocks. This is needlessly verbose: we could
simply accept "END" in both cases without syntactic ambiguity. I'd like
to make this change, so that END can be used to terminate any kind of
block. There'
Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
>
>>But it still requires me to send some data (such as a dummy query) to
>>the backend before it exits. This is because server side libpq blocks
>>when reading and ignores signals at this time. I believe the fix for
>>this would be t
I think it makes my code cleaner, I'll give you an update tomorrow
Dave
On 21-Jun-05, at 5:49 PM, Tom Lane wrote:
Dave Cramer <[EMAIL PROTECTED]> writes:
Yeah, I think that might work if I understand it correctly.
Assuming I would be able to prepare, and bind all the parameters, and
the OUT p
On Tue, 21 Jun 2005, Josh Berkus wrote:
People:
Oh, and in implementing the COPY stuff we realized that there weren't any
regression tests for encodings. If we can figure out how to do them,
we'll add those. Are new regression tests permitted during beta?
Yes, most definitely ... especiall
Bruce Momjian wrote:
Dave Page wrote:
Basically, Andreas' approach for 8.0 was to develop a patch (without
posting a proposal or interface), and then argue why pgadmin needs it,
but without addressing the real concerns about the patch.
Extending the logging was to get a means of reading the lo
Sounds good to me... just wondering where dblink went? Is it going to
remain a part of the dist?
Sorry if this was already answered, I haven't had the time to check the
archive.
-Jonah
Tom Lane wrote:
Looking over the thread Josh started a few days ago, it seems there is
consensus to move
People:
Oh, and in implementing the COPY stuff we realized that there weren't any
regression tests for encodings. If we can figure out how to do them,
we'll add those. Are new regression tests permitted during beta?
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
Alvaro,
> Tom gave instructions in a mail (to you I think) to patch the xlog.c
> file so page dumps stop happening. I'm too lazy to search for that mail
> (I deleted my local copy) but if you find it in your mailbox, resend it
> to me and I'll produce a patch for you to test. (I'd produce the pa
On Jun 21, 2005, at 1:03 PM, Bruce Momjian wrote:
We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a feature
freeze
on July 1.
I'm hoping to add documentation and regression tests for interval-
>day over the n
On Tue, Jun 21, 2005 at 02:45:32PM -0700, Josh Berkus wrote:
> > Another thing to blame is the dump-whole-pages-after-checkpoint
> > business. Maybe the load you are seeing is not completely during
> > checkpoint, but right after it as well. How do you tell from the
> > results that the checkpoi
On Wed, Jun 22, 2005 at 12:36:23AM +0200, Andreas 'ads' Scherbaum wrote:
>
> Hello,
>
> is it possible to get the PG version splitted up into major, minor and
> micro version in the future?
> For now, only PG_VERSION is defined (at least, what i can see) and it is
> not possible to use PG_VERSION
On Jun 21, 2005, at 1:03 PM, Bruce Momjian wrote:
We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a feature
freeze
on July 1.
I'm hoping to add documentation and regression tests for interval-
>day over the nex
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Has anyone looked at how hard it would be to identify impossible
> conditions as part of planning the query?
The question in my mind is not so much how hard it would be as how many
cycles we would waste trying to prove things that won't be true for
99.9
Looking over the thread Josh started a few days ago, it seems there is
consensus to move these contrib modules into separate projects on
pgfoundry.org:
adddepend
dbase
dbmirror
fulltextindex
mSQL-interface
mac
oracle
tips
and to kill these outright:
array
ipc_check
miscutil
mysql
noupdate
pg_dum
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> We have addressed all the open issues for 8.1 except for auto-vacuum,
> which Alvaro is working on, so I think we are ready for a feature freeze
> on July 1.
FWIW, I'm still working on column-level triggers, but the July 1st deadline
should not be
Hello,
is it possible to get the PG version splitted up into major, minor and
micro version in the future?
For now, only PG_VERSION is defined (at least, what i can see) and it is
not possible to use PG_VERSION at compile time to determine the actual
PG version.
Example:
In a module i want to u
On Tue, Jun 21, 2005 at 10:33:45PM +0100, Simon Riggs wrote:
> On Tue, 2005-06-21 at 16:29 -0400, Tom Lane wrote:
> > > create index idx1 on tenk (col1) where col1 > 1 and col1 < 10;
> >
> > > explain select * from tenk where col1 > 5 and col1 < -5;
> > > [ uses that index ]
> >
> > This is a per
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> This patch removes Kerberos version 4 support from the backend and
> libpq. Per previous mail, I sent a mail to both hackers and -general
> about a month ago asking for ppl who use it, for zero responses. I also
> looked back in the archives and it se
Pavel Stehule <[EMAIL PROTECTED]> writes:
> I wont to prohibit synonyms in exception (every exception has unique
> sqlstate).
I don't think that's a particularly good idea --- maybe if SQL had been
designed according to your worldview, it'd be like that, but it isn't
and you can't retroactively f
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> But it still requires me to send some data (such as a dummy query) to
> the backend before it exits. This is because server side libpq blocks
> when reading and ignores signals at this time. I believe the fix for
> this would be to pass a flag down to
Dave Cramer <[EMAIL PROTECTED]> writes:
> Yeah, I think that might work if I understand it correctly.
> Assuming I would be able to prepare, and bind all the parameters, and
> the OUT parameters
> would be ignored.
This is what I've got in mind:
regression=# create function myfunc(f1 int, f2 in
Alvaro, Tom,
> bgwriter_delay | 200
> bgwriter_maxpages | 100
> bgwriter_percent | 1
>
> Maybe it should be more aggressive.
Yeah, a bgwriter progression is running now. I don't expect it to make
much difference. Most of sync impact is syncing the
On Tue, Jun 21, 2005 at 12:00:56PM -0700, Josh Berkus wrote:
> Folks,
>
> Going over some performance test results at OSDL, our single greatest
> performance issue seems to be checkpointing.Not matter how I fiddle
> with it, checkpoints seem to cost us 1/2 of our throughput while they're
>
On Tue, 2005-06-21 at 16:29 -0400, Tom Lane wrote:
> > create index idx1 on tenk (col1) where col1 > 1 and col1 < 10;
>
> > explain select * from tenk where col1 > 5 and col1 < -5;
> > [ uses that index ]
>
> This is a perfectly legitimate situation.
Like I said, its correct. I didn't suggest
Yeah, I think that might work if I understand it correctly.
Assuming I would be able to prepare, and bind all the parameters, and
the OUT parameters
would be ignored.
FWIW, I proposed adding to the protocol, not modifying the existing
messages, so it would be backward compatible and not bre
Dave Cramer <[EMAIL PROTECTED]> writes:
> Yeah, I think that might work if I understand it correctly.
> Assuming I would be able to prepare, and bind all the parameters, and
> the OUT parameters
> would be ignored.
> FWIW, I proposed adding to the protocol, not modifying the existing
> message
I had an idea about how to possibly solve the pg_terminate_backend
issue.
How about we add a field to PGPROC (or is there a better place?) called
shouldExit. pg_terminate_backend will set this field to "true" in the
target backend, and then send the normal "cancel query" signal.
The receiving ba
Dave Cramer <[EMAIL PROTECTED]> writes:
> The current situation with IN/OUT parameters requires that
> considerable juggling is required on the client end to not pass the
> OUT parameters in the query. This could be alleviated by adding two
> messages for stored procedure calls
> 1) PrepareCa
Josh Berkus writes:
> Can we break down everything that happens during a checkpoint so that we
> can see where this huge cost is coming from? Checkpointing should be
> limited to fsyncing to disk and marking WAL files as recyclable, but there
> seems to be something more.
I already asked y
Simon Riggs <[EMAIL PROTECTED]> writes:
> Sweating over the logic of the theorem prover, I notice it doesn't
> actually bother to complete an accurate test.
Sure it does.
> create index idx1 on tenk (col1) where col1 > 1 and col1 < 10;
> explain select * from tenk where col1 > 5 and col1 < -5;
>
Gavin Sherry wrote:
> On Wed, 15 Jun 2005, Bruce Momjian wrote:
>
> >
> > I am going to start working on it. I am concerned it is a big job.
> >
> > I will post questions as I find them, and the one below is a good one.
> >
>
> I'm wondering if effort is being misdirected here. I remember when M
Sweating over the logic of the theorem prover, I notice it doesn't
actually bother to complete an accurate test. I can't see that it
produces an error, but I thought I would raise it, if only to share my
annoyance at the realisation of how it does things. :-(
drop table tenk;
create table tenk (c
Folks,
Going over some performance test results at OSDL, our single greatest
performance issue seems to be checkpointing.Not matter how I fiddle
with it, checkpoints seem to cost us 1/2 of our throughput while they're
taking place. Overally, checkpointing costs us about 25% of our
perform
The current situation with IN/OUT parameters requires that
considerable juggling is required on the client end to not pass the
OUT parameters in the query. This could be alleviated by adding two
messages for stored procedure calls
1) PrepareCall which sent the types, and direction of the par
Magnus Hagander wrote:
> Is there an "Open Issues" list yet, as you usually prepare for releases?
> If so, can you please put these items up on it?
Yes, it is at:
This item has been added to the 7.4 open items list:
http://candle.pha.pa.us/cgi-bin/pgopenitems
It did contain only pgautov
Andrew Dunstan wrote:
> There is also the tiny patch to trap lexical warnings I submitted not
> long ago still outstanding.
OK, I missed that one. I see it at:
http://archives.postgresql.org/pgsql-patches/2005-06/msg00280.php
However, I don't see the new regession files attached to tha
On Sun, 19 Jun 2005, Neil Conway wrote:
> Pavel Stehule wrote:
> > DECLARE excpt EXCEPTION [= 'SQLSTATE']
>
> What would this default to? (i.e. if no '= SQLSTATE' is specified)
I wont to prohibit synonyms in exception (every exception has unique
sqlstate). If I need better control for sqlst
Takahiro,
> scale| DBsize | open_sync | fsync=false | O_DIRECT only| fsync_direct |
> open_direct
> -++---+--+--+--+
>--- 10 | 150MB | 252.6 tps | 263.5(+ 4.3%)| 253.4(+ 0.3%)|
> 253.6(+ 0.4%)| 253.3(+ 0.3%) 100 | 1.5GB | 102.7
Dave Page wrote:
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
> > Sent: 21 June 2005 05:04
> > To: PostgreSQL-development
> > Subject: [HACKERS] Schedule for 8.1 feature freeze
> >
> > We have addressed all the open iss
I'll do my best to submit bitmap index AM patch next week for your review.
--
Victor Y. Yegorov
---(end of broadcast)---
TIP 8: explain analyze is your friend
Tom Lane wrote:
> Oliver Jowett <[EMAIL PROTECTED]> writes:
> > Bruce Momjian wrote:
> >> I have received very few replies to my suggestion that we implement E''
> >> for escaped strings, so eventually, after a few major releases, we can
> >> have '' treat backslashes literally like the SQL standar
Bruce Momjian wrote:
We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a feature freeze
on July 1.
FYI - plperl status.
I am trying to get the following 2 items done by feature freeze:
. convert returned perl ar
On Tuesday 21 June 2005 10:04, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > You know, since we don't maintain static connections (http is our friend)
> > connecting to template1 really isn't a problem for phppgadmin users. At
> > least I can't remember anyone ever having complain
Rohit Gaddi <[EMAIL PROTECTED]> writes:
> I have a table with two indices on the same column, one of which is a partial
> index. I would like the query planner to use the partial index whenever the
> query condition lies in the range of the partial index as it would yield
> better performance. I
AgentM <[EMAIL PROTECTED]> writes:
> What I am really hoping for is that PQexecParams() [in later versions
> of libpq] can figure it out for itself so client code doesn't need
> fixing. That is the plan, right?
Out-of-line parameters are not an issue at all --- only string literals
embedded in
FYI
On 06/20/2005 11:12:20 PM, Bruce Momjian wrote:
[ BCC to general. ]
I have received very few replies to my suggestion that we implement
E''
for escaped strings, so eventually, after a few major releases, we can
have '' treat backslashes literally like the SQL standard requires.
I assume th
Mag Gam <[EMAIL PROTECTED]> writes:
> I had to modify this line in the tsearch2 Makefile
> from
> SHLIB_LINK := -lm
> to
> SHLIB_LINK := -lm -lpgport
Hmm, that's annoying. I was about to commit this change but it actively
fails on my machine:
/usr/ccs/bin/ld: DP relative code in file ../../src
What I am really hoping for is that PQexecParams() [in later versions
of libpq] can figure it out for itself so client code doesn't need
fixing. That is the plan, right?
On Jun 20, 2005, at 11:57 PM, Oliver Jowett wrote:
Bruce Momjian wrote:
I have received very few replies to my suggesti
If the method needs a truly global LSN, then it is broken --- the only
way you could have such a value and have it stay good long enough to do
anything with it is to block all other backends from inserting any new
WAL records. Which is the very antithesis of concurrency.
Global LSN needs to reco
Bruce Momjian writes:
> We have addressed all the open issues for 8.1 except for auto-vacuum,
Aside from the other stuff people mentioned, I have these things on
my to-look-at list:
* Fix pg_dump to be able to dump large objects in text dumps
* Fix inherited constraints (per discussion around 5
Tom Lane wrote:
Robert Treat <[EMAIL PROTECTED]> writes:
You know, since we don't maintain static connections (http is our friend)
connecting to template1 really isn't a problem for phppgadmin users. At
least I can't remember anyone ever having complained about it.
Sure you have:
Robert Treat <[EMAIL PROTECTED]> writes:
> You know, since we don't maintain static connections (http is our friend)
> connecting to template1 really isn't a problem for phppgadmin users. At
> least I can't remember anyone ever having complained about it.
Sure you have: people have complained a
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > I'd really like to see role support added into 8.1. I've sent Alvaro
> > and Tom versions of the patch in the past and I was planning on
> > submitting it to -patches soon. There's a few remaining issue bu
"Dave Page" writes:
>> Another point is that Dave added code to pg_dumpall to not dump the
>> postgres database.
> My reading of that code was that I merely stopped it dumping the CREATE
> DATABASE statement (and the ACL) for the database, /not/ the actual
> contents - in the same way as is done
Stephen Frost <[EMAIL PROTECTED]> writes:
> I'd really like to see role support added into 8.1. I've sent Alvaro
> and Tom versions of the patch in the past and I was planning on
> submitting it to -patches soon. There's a few remaining issue but I
> don't think they'll take very long to
On Tuesday 21 June 2005 04:01, Dave Page wrote:
> > -Original Message-
> > From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
> > Sent: 21 June 2005 08:57
> > To: Dave Page
> > Cc: Robert Treat; Tom Lane; Andrew Dunstan; Andreas Pflug;
> > Magnus Hagander; pgsql-hackers@postgresql.org
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Now I basically finished recovery for GiST (of course, it's need a hard
> testing)
> and go to concurrency. As it described in Kornaker, Mohan and Hellerstein's
> paper
> (http://www.sai.msu.su/~megera/postgres/gist/papers/concurrency/sigmod97-gist.pd
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> I tested two combinations,
> - fsync_direct: O_DIRECT+fsync()
> - open_direct: O_DIRECT+O_SYNC
> to compare them with O_DIRECT on my linux machine.
> The pgbench results still shows a performance win:
> scale| DBsize | open_sync | fsync=false | O
Tom:
Got it working!
I had to modify this line in the tsearch2 Makefile
from
SHLIB_LINK := -lm
to
SHLIB_LINK := -lm -lpgport
it works like a charm!
thanks for your help!
On 5/18/05, Mag Gam <[EMAIL PROTECTED]> wrote:
> Thanks for the reply Tom!
>
> I managed to get the cvs version and I m
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> I have received very few replies to my suggestion that we implement E''
>> for escaped strings, so eventually, after a few major releases, we can
>> have '' treat backslashes literally like the SQL standard requires.
> Just checki
Tom Lane wrote:
One thing that neither Dave nor I wanted to touch is pg_autovacuum.
If that gets integrated into the backend by feature freeze then the
question is moot, but if it doesn't then we'll have to decide whether
autovac should preferentially connect to template1 or postgres. Neither
c
> I realise there probably won't be time to fix pg_terminate_backend, or
> convince people that it offers the admin the lesser of two evils (my
> limited understanding being that there is a chance of it not clearing
> some locks, vs, having to shut down the whole server to kill a single
> connectio
On Tue, Jun 21, 2005 at 22:11:25 +1000,
John Hansen <[EMAIL PROTECTED]> wrote:
>
> I misunderstood the original post as a request for queries NOT to use
> indexes where it doesn't match the table contents.
I think that is what they were asking, but I don't think they wanted
to see a sequential
Bruno Wolff III [mailto:[EMAIL PROTECTED] Wrote:
> You only want to use partial indexes when they don't cover
> the whole table. They make sense to enforce uniqueness of a
> column under some condition and when you can save significant
> space (becuase the condition is only satisfied for a smal
On Tue, Jun 21, 2005 at 21:54:34 +1000,
John Hansen <[EMAIL PROTECTED]> wrote:
> Bruno Wolff III [mailto:[EMAIL PROTECTED] Wrote
>
> > I think the real problem is that check constraints on tables
> > aren't used by the optimizer. Given that, what you have below
> > is expected.
> > There has b
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> We have addressed all the open issues for 8.1 except for auto-vacuum,
> which Alvaro is working on, so I think we are ready for a feature freeze
> on July 1.
Bruce,
I'd really like to see role support added into 8.1. I've sent Alvaro
and Tom
Bruno Wolff III [mailto:[EMAIL PROTECTED] Wrote
> I think the real problem is that check constraints on tables
> aren't used by the optimizer. Given that, what you have below
> is expected.
> There has been talk about that in the past, but I haven't
> heard anything recently about someone consi
On Tue, Jun 21, 2005 at 09:46:50 +1000,
John Hansen <[EMAIL PROTECTED]> wrote:
> Someone Wrote:
>
> > Should not check constraint act as the first filter? The index should
> > ideally be scanned only when the check constraint is passed by the
> search
> > criteria but surprisingly it did not h
Now I basically finished recovery for GiST (of course, it's need a hard testing)
and go to concurrency. As it described in Kornaker, Mohan and Hellerstein's
paper
(http://www.sai.msu.su/~megera/postgres/gist/papers/concurrency/sigmod97-gist.pdf)
it's need a way to get global LSN, in our case -
First of all your patch does not conform with the project style. Please
have a look at how other files are indented, in particular regarding
brace position and ereport() arguments (any function arguments really,
but in ereport your problems are more visible). Also, always use
ereport() for use
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
Sent: 21 June 2005 05:04
To: PostgreSQL-development
Subject: [HACKERS] Schedule for 8.1 feature freeze
We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is work
Thank you for the comments.
First of all your patch does not conform with the project style. Please
have a look at how other files are indented, in particular regarding
brace position and ereport() arguments (any function arguments really,
but in ereport your problems are more visible). Also,
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 21 June 2005 05:13
> To: Dave Page
> Cc: Andrew Dunstan; Andreas Pflug; Robert Treat; Magnus
> Hagander; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [PATCHES] default database creation
> with initdb
>
> -Original Message-
> From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
> Sent: 21 June 2005 08:57
> To: Dave Page
> Cc: Robert Treat; Tom Lane; Andrew Dunstan; Andreas Pflug;
> Magnus Hagander; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [PATCHES] default database cre
Yes - that's intentional so that pgAdmin/phpPgAdmin et al. can
reasonably expect it to be there.
Problem is, how the hell do I know it's there before I connect?
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send
> We have addressed all the open issues for 8.1 except for
> auto-vacuum, which Alvaro is working on, so I think we are
> ready for a feature freeze on July 1.
I don't beleive we have :-(
The server instrumentation patch is not yet addressed. Last I checked
there was the objections to pg_termi
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
> Sent: 21 June 2005 05:04
> To: PostgreSQL-development
> Subject: [HACKERS] Schedule for 8.1 feature freeze
>
> We have addressed all the open issues for 8.1 except for auto-vacuum,
>
> -Original Message-
> From: Robert Treat [mailto:[EMAIL PROTECTED]
> Sent: 21 June 2005 08:10
> To: Tom Lane
> Cc: Dave Page; Andrew Dunstan; Andreas Pflug; Magnus
> Hagander; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [PATCHES] default database creation with initdb
>
> On
On Tuesday 21 June 2005 00:12, Tom Lane wrote:
> "Dave Page" writes:
> > OK, new patch posted to -patches that updates all the utilities as well.
>
If I read the code correctly, the database name will be hardwired to
"postgres" regardless of the default super user name correct?
--
Robert Trea
98 matches
Mail list logo
