Josh Berkus josh@agliodbs.com writes:
Diogo's xlogviewer stuff should be ready shortly also (1-3 weeks). Since
that's a contrib module how do we stand on having that get into 8.2,
even though it isn't going to hit the main feature freeze?
This is why I was asking for status reports on
Folks,
As Dave Page is on holiday for the next few weeks, I'm looking for
people who can help summarize -patches and -committers for inclusion
in the PostgreSQL Weekly News. When you volunteer for this, you don't
have to catch everything, but I'd really appreciate it if you can get
me something
On Aug 1, 2006, at 16:15 , Harald Armin Massa wrote:
As accepting 2006-02-31 as a valid date would require brainwashing
at least the entire core team, we should find a recommended path
of date migration from different universes.
Have you checked out the mysql2pgsql[1] or my2postgres
Simon Riggs wrote:
Patch included to implement xlog switching, using an xlog record
processing instruction and forcibly moving xlog pointers.
1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL switch any more?
Laurenz
Albe Laurenz wrote:
Simon Riggs wrote:
Patch included to implement xlog switching, using an xlog record
processing instruction and forcibly moving xlog pointers.
1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL
Tim Allen wrote:
Patch included to implement xlog switching, using an xlog record
processing instruction and forcibly moving xlog pointers.
1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL switch any more?
Well,
Albe Laurenz wrote:
Tim Allen wrote:
Patch included to implement xlog switching, using an xlog record
processing instruction and forcibly moving xlog pointers.
1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL switch
Now that it is August 1, we are in feature freeze. During the next
month, all outstanding patches will be reviewed and hopefully applied.
After that, we will start preparing for beta, hopefully to start in
September or October.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDB
On 20/07/06, Tom Lane [EMAIL PROTECTED] wrote:
Reini Urban [EMAIL PROTECTED] writes:
BTW: HAVE_LONG_LONG_INT_64 is defined, so INT64_IS_BUSTED is defined also.
You sure? INT64_IS_BUSTED should *not* be set in that case --- it's
only supposed to be set if we couldn't find any 64-bit-int type
Consindering the syntax for this, we currently allow read access during
index creation, just not write access, so I think the new syntax should
be:
CREATE [ UNIQUE ] INDEX name ON table
[ USING method ] [ [ENABLE] WRITE [ACCESS] ]
( { column | ( expression ) } [
Albe Laurenz wrote:
Tim Allen wrote:
Patch included to implement xlog switching, using an xlog record
processing instruction and forcibly moving xlog pointers.
1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a
Adrian Maier wrote:
On 20/07/06, Tom Lane [EMAIL PROTECTED] wrote:
Reini Urban [EMAIL PROTECTED] writes:
BTW: HAVE_LONG_LONG_INT_64 is defined, so INT64_IS_BUSTED is
defined also.
You sure? INT64_IS_BUSTED should *not* be set in that case --- it's
only supposed to be set if we couldn't
Bruce Momjian wrote:
Consindering the syntax for this, we currently allow read access during
index creation, just not write access, so I think the new syntax should
be:
CREATE [ UNIQUE ] INDEX name ON table
[ USING method ] [ [ENABLE] WRITE [ACCESS] ]
( { column | (
Andrew Dunstan wrote:
Bruce Momjian wrote:
Consindering the syntax for this, we currently allow read access during
index creation, just not write access, so I think the new syntax should
be:
CREATE [ UNIQUE ] INDEX name ON table
[ USING method ] [ [ENABLE] WRITE [ACCESS]
Bruce Momjian [EMAIL PROTECTED] writes:
CREATE [ UNIQUE ] INDEX name ON table
[ USING method ] [ [ENABLE] WRITE [ACCESS] ]
( { column | ( expression ) } [ opclass ] [, ...] )
[ WITH ( storage_parameter = value [, ... ] ) ]
[ TABLESPACE
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
CREATE [ UNIQUE ] INDEX name ON table
[ USING method ] [ [ENABLE] WRITE [ACCESS] ]
( { column | ( expression ) } [ opclass ] [, ...] )
[ WITH ( storage_parameter = value [, ... ] ) ]
[
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Maybe we need to abandon trying to map float8 results exactly in the
resultmap file, and just let pg_regress pick the best fit as we do with
some other tests.
I thought about that too but it seems a very bad idea.
On 01/08/06, Andrew Dunstan [EMAIL PROTECTED] wrote:
Adrian Maier wrote:
On 20/07/06, Tom Lane [EMAIL PROTECTED] wrote:
Apparently the regression test is comparing the results/float8.out
with expected/float8-small-is-zero.out because of the following line
in
src/test/regress/resultmap :
[ re cassowary buildfarm failure ]
Adrian Maier [EMAIL PROTECTED] writes:
On 20/07/06, Tom Lane [EMAIL PROTECTED] wrote:
As for the regression test failure, it's odd because it looks to me that
the actual test output is an exact match to the default float8.out
file. I'm not sure why
Andrew Dunstan [EMAIL PROTECTED] writes:
Maybe we need to abandon trying to map float8 results exactly in the
resultmap file, and just let pg_regress pick the best fit as we do with
some other tests.
I thought about that too but it seems a very bad idea. small-is-zero is
distinctly less
On 01/08/06, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Maybe we need to abandon trying to map float8 results exactly in the
resultmap file, and just let pg_regress pick the best fit as we do with
some other tests.
I thought about that too but it seems a very
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I thought about that too but it seems a very bad idea. small-is-zero is
distinctly less correct than the regular output, and I don't think we
want pg_regress to be blindly accepting it as OK on any platform.
Yes, good points. One
Bruce Momjian wrote:
Andrew Dunstan wrote:
It's not particularly clear to me. On its face this seems to me to imply
something about how the index will be able to be used, not about how it
is to be built.
Yea, that was always a confusion. CREATE CONCURRENT INDEX has the same
problem.
Alvaro Herrera wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
It's not particularly clear to me. On its face this seems to me to imply
something about how the index will be able to be used, not about how it
is to be built.
Yea, that was always a confusion. CREATE
char(42) 'literal value here'
Playing around that I noticed:
postgres=# select '{asd}'::text[], '{asd}'::_text, _text '{asd}';
text | _text | _text
---+---+---
{asd} | {asd} | {asd}
(1 row)
postgres=# select text[] '{asd}';
ERROR: syntax error at or near ]
LINE 1:
Teodor Sigaev [EMAIL PROTECTED] writes:
postgres=# select text[] '{asd}';
ERROR: syntax error at or near ]
LINE 1: select text[] '{asd}';
Is it desired effect?
Not really, but that's another thing that seems unreasonably hard to
fix.
regards, tom lane
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
One other thought I had was that we could have
pg_regress always allow a fallback to the canonical result file.
Hm, that's a good thought. Want to see how painful it is to code?
Would this do the trick?
cheers
andrew
Andrew Dunstan [EMAIL PROTECTED] writes:
Would this do the trick?
I think Bruce changed the call convention for run_diff ... are you
looking at CVS tip? Otherwise it looks reasonable.
regards, tom lane
---(end of
Tom Lane [EMAIL PROTECTED] writes:
I think the problem may well be that we use hash buckets that are too
large (ie, whole pages). After we fetch the page, we have to grovel
through every tuple on it to find the one(s) that really match the
query, whereas btree has a much more intelligent
Not really, but that's another thing that seems unreasonably hard to
fix.
Sorry, but more problem:
1)
postgres=# select 'as'::pg_catalog.char, 'as'::char, 'as'::char(2);
char | bpchar | bpchar
--++
a| a | as
(1 row)
postgres=# select 'as'::pg_catalog.char(2);
On Tue, Aug 01, 2006 at 06:47:31PM +0400, Teodor Sigaev wrote:
Not really, but that's another thing that seems unreasonably hard to
fix.
Sorry, but more problem:
snip more problems
No kidding, it's quite a mess and really needs to be cleaned up. About
the only thing we could do would be to
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
I think the problem may well be that we use hash buckets that are too
large (ie, whole pages). After we fetch the page, we have to grovel
through every tuple on it to find the one(s) that really match the
query, whereas btree has a
Jim,
On 7/28/06 12:27 PM, Jim C. Nasby [EMAIL PROTECTED] wrote:
In that case, perhaps this is something Greenplum might be interested
in, since it might fit nicely between bitmap and btree indexes.
I'm certainly following the thread.
We have talked about hash and btree organized tables both
Hello,
Maybe this question is not logic, but for me is very
important.
I was tested some temporary tables and, of course are
very fast, because they are in memory.
But one table created by one connection, can´t be
modified by others connections?
I want to know if exist some way to
moises wrote:
Hello,
Maybe this question is not logic, but for me is very important.
I was tested some temporary tables and, of course are very fast,
because they are in memory.
But one table created by one connection, can´t be modified by others
connections?
I want to know if exist
moises wrote:
I want to know if exist some way to shared a temporary table between
2 connections.
No.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an
On Tue, 2006-08-01 at 07:55 -0700, Luke Lonergan wrote:
WRT hashing - we use FNV hash which is a very nice, very fast modern hash
algorithm. We would contribute that if we worked on this.
We currently use Bob Jenkins' hash function[1], which is apparently
faster than FNV on most architectures
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Would this do the trick?
I think Bruce changed the call convention for run_diff ... are you
looking at CVS tip? Otherwise it looks reasonable.
You're right. I had forgotten to do a cvs update. Fixed and committed.
cheers
Hi,
I have progressed a bit with my pet project, a.k.a $SUBJECT.
Now GENERATED ALWAYS AS IDENTITY and
GENERATED ALWAYS AS ( expr ) work as
intended. Documentation was also extended.
Some test cases are also included, that shows
that ALTER TABLE ALTER TYPE keeps both
the sequence and the
On Tue, Aug 01, 2006 at 10:54:10AM -0400, Andrew Dunstan wrote:
This is now sounding like a lot of low hanging fruit ... highly
performant hash indexed tables could possibly be a very big win.
So does someone want to 'take up the cause' for them?
--
Jim C. Nasby, Sr. Engineering Consultant
Zoltan Boszormenyi wrote:
BTW, is there anyone working on COPY FROM ( select ) feature?
I am, but it's in a too early stage to be in 8.2. Sorry :-(
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
On Sun, Jul 30, 2006 at 11:27:33AM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Sat, Jul 29, 2006 at 09:44:10PM -0400, Tom Lane wrote:
The correct solution is for client-side libraries to provide the
feature.
Not if the app is written in SQL, as the bootstrap,
On Tue, Aug 01, 2006 at 12:37:48PM -0500, Jim C. Nasby wrote:
On Sun, Jul 30, 2006 at 11:27:33AM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Sat, Jul 29, 2006 at 09:44:10PM -0400, Tom Lane wrote:
The correct solution is for client-side libraries to provide
the
Patch applied. Thanks.
---
Martin Pitt wrote:
-- Start of PGP signed section.
Hi PostgreSQL developers,
some time ago I started a discussion [1] here about modifying pg_dump
to not restore TABLE DATA objects if the
I've found a problem with the VALUES-as-RTE approach:
regression=# create table src(f1 int, f2 int);
CREATE TABLE
regression=# create table log(f1 int, f2 int, tag text);
CREATE TABLE
regression=# insert into src values(1,2);
INSERT 0 1
regression=# create rule r2 as on update to src do
Tom Lane wrote:
I've found a problem with the VALUES-as-RTE approach:
regression=# create table src(f1 int, f2 int);
CREATE TABLE
regression=# create table log(f1 int, f2 int, tag text);
CREATE TABLE
regression=# insert into src values(1,2);
INSERT 0 1
regression=# create rule r2 as on
Tom Lane wrote:
What I'm inclined to do for 8.2 is to disallow OLD/NEW references in
multi-element VALUES clauses; the feature is still tremendously useful
without that.
Given the timing, this sounds like a reasonable approach. I agree that
the feature has lots of interesting uses -- I'd hate
Alvaro Herrera [EMAIL PROTECTED] writes:
Does it work if you do
regression=# create rule r2 as on update to src do
regression-# insert into log values(old.f1, old.f2, 'old'), (new.f1, new.f2,
'new');
No, that's not the problem. * expansion works just fine here, it's
the executor that can't
Ühel kenal päeval, T, 2006-08-01 kell 10:54, kirjutas Andrew Dunstan:
Gregory Stark wrote:
I looked a while back and was suspicious about the actual hash functions
too.
It seemed like a lot of them were vastly suboptimal. That would mean we're
often dealing with mostly empty and
On Tue, 2006-08-01 at 18:10 +0200, Zoltan Boszormenyi wrote:
Hi,
I have progressed a bit with my pet project, a.k.a $SUBJECT.
Now GENERATED ALWAYS AS IDENTITY and
GENERATED ALWAYS AS ( expr ) work as
intended. Documentation was also extended.
I'm only commenting because I debated trying
Rod Taylor írta:
On Tue, 2006-08-01 at 18:10 +0200, Zoltan Boszormenyi wrote:
Hi,
I have progressed a bit with my pet project, a.k.a $SUBJECT.
Now GENERATED ALWAYS AS IDENTITY and
GENERATED ALWAYS AS ( expr ) work as
intended. Documentation was also extended.
I'm only commenting
Thanks for mentioning about pgpool!
sect2title pgpool /title
para applicationpgpool/application was initially created by
Tatsuo Isshii as a portable alternative to Java connection pool
modules. He subsequently observed that it wouldn't take very much
effort to
Chris Browne wrote:
Here's a patch to add in the material on replication recently
discussed on pgsql.docs. I'm not thrilled that there were only a few
comments made; I'd be happy to see slicing and dicing to see this
made more useful.
The agreed-to process was
1. post information on
Hannu Krosing [EMAIL PROTECTED] writes:
Ãhel kenal päeval, T, 2006-08-01 kell 10:54, kirjutas Andrew Dunstan:
Gregory Stark wrote:
I looked a while back and was suspicious about the actual hash functions
too.
It seemed like a lot of them were vastly suboptimal. That would mean
1. post information on pgsql-general
1.a. solicit comments
2. put information page on web site
3. link from documentation to web site
You seem to have short-circuited all that.
I don't think this sort of material belongs directly into the PostgreSQL
documentation.
It might be interesting to
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Greg Stark
Sent: Tuesday, August 01, 2006 4:42 PM
To: Hannu Krosing
Cc: Andrew Dunstan; Gregory Stark; Tom Lane; Alvaro Herrera; Jim C. Nasby;
Luke Lonergan; [EMAIL PROTECTED]; Bruce
Joshua D. Drake wrote:
I don't think this sort of material belongs directly into the PostgreSQL
documentation.
Why not?
It might be interesting to have some links in the external projects area
for replication, but a section of its own doesn't seem relevant.
I disagree about having some
Alvaro Herrera wrote:
Joshua D. Drake wrote:
I don't think this sort of material belongs directly into the PostgreSQL
documentation.
Why not?
Well Peter said that, not me :)
It might be interesting to have some links in the external projects area
for replication, but a section of its
Joshua D. Drake wrote:
Alvaro Herrera wrote:
Joshua D. Drake wrote:
I don't think this sort of material belongs directly into the PostgreSQL
documentation.
Why not?
Well Peter said that, not me :)
I know, but I though I'd post one message instead of two. (In fact I
didn't even think
For db restoration (pg_dump), how do you restore to the same values as
previously if it is always regenerated? By making ALWAYS a suggestion
for some users instead of always enforced and providing an override
mechanism for it. I assume it only works for relation owners but I've
not
Alvaro Herrera wrote:
I don't think this sort of material belongs directly into the
PostgreSQL documentation.
Why not?
PostgreSQL documentation (or any product documentation) should be
factual: describe what the software does and give advice on its use.
This should be mostly independent
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
What I'm inclined to do for 8.2 is to disallow OLD/NEW references in
multi-element VALUES clauses; the feature is still tremendously useful
without that.
Given the timing, this sounds like a reasonable approach. I agree that
the feature
I was thinking of something similar to our encryption section:
http://www.postgresql.org/docs/8.1/static/encryption-options.html
The idea being to define issues like multi/single master, async vs,
sync, and mention the projects which are in each category.
Should we wait for someone to actually ask for this before adding it to
the TODO list? Does it cause a crash now?
---
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
What I'm inclined to do for
Martijn van Oosterhout kleptog@svana.org writes:
snip more problems
No kidding, it's quite a mess and really needs to be cleaned up. About
the only thing we could do would be to merge the productions for types
and functions. Or at least, make the productions look similar enough
that bison
Bruce Momjian wrote:
Should we wait for someone to actually ask for this before adding it
to the TODO list?
Probably worth adding it to the TODO list so it doen't get lost.
Does it cause a crash now?
Nope:
regression=# create table log(f1 int, f2 int, tag text);
CREATE TABLE
regression=#
pg_dump in HEAD is dumping the entire contents of system catalogs.
New feature? :-(
--
Michael Fuhr
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED]
67 matches
Mail list logo
