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 proj
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?
Lau
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 swi
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
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]
EnterpriseDBhttp://www.
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 ty
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 back
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 | ( expressi
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] WR
Bruce Momjian <[EMAIL PROTECTED]> writes:
> CREATE [ UNIQUE ] INDEX name ON table
> [ USING method ] [ [ENABLE] WRITE [ACCESS] ]
> ( { column | ( expression ) } [ opclass ] [, ...] )
> [ WITH ( storage_parameter = value [, ... ] ) ]
> [ TABLESPACE tab
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. small-is-ze
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/res
[ 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 sur
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 "les
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
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 point
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
>
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.
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: se
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 broadcast)
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 intellige
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);
ERR
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:
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 pr
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 m
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
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 sh
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 s
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 a
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.
cheer
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 GENERATE
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 boot
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
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 th
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
regression
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
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 tha
Ü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
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 t
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 beca
Thanks for mentioning about pgpool!
> pgpool
>
> pgpool 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 extend it to create a simple replication sy
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 pg
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.
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]; Bru
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
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 ow
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
> > 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
> >
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 inde
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
> th
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
Martijn van Oosterhout writes:
>
> 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 can avoid deciding which it is un
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=# i
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]
On Aug 2, 2006, at 12:47 , Joe Conway wrote:
regression=# create rule r2 as on update to src do insert into log
values(old.*, 'old'), (new.*, 'new');
ERROR: VALUES must not contain OLD or NEW references
Would it make sense to add a HINT as well, recommending the UNION
construct Tom mentio
66 matches
Mail list logo
