Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Want me to change those or are you on it already?
I'm going to bed --- if you wanna do it, have at it ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Wednesday 05 August 2009 06:00:19 David Fetter wrote:
If I'm understanding you correctly, you're saying that pg_migrator (or
whatever actually does this) needs to be an official PostgreSQL
project in order for us to be able to require that people use it. For
what it's worth, I agree.
Is
So the next step to documentation bliss is to get rid of the man.tar.gz and
postgres.tar.gz tarballs that are shipped inside the tarball. These are
historical artifacts from the era when building the documentation for release
required manual interference, and that era ended yesterday at the
On Fri, Jul 31, 2009 at 11:42:33AM +0200, Boszormenyi Zoltan wrote:
made me look around more. Find the attached patch I came up with.
Now my previous test code works and produces similar C code
as without -C INFORMIX. Can it be this simple?
Unfortunately it is not.
Can you see anything wrong
Michael Meskes írta:
On Fri, Jul 31, 2009 at 11:42:33AM +0200, Boszormenyi Zoltan wrote:
made me look around more. Find the attached patch I came up with.
Now my previous test code works and produces similar C code
as without -C INFORMIX. Can it be this simple?
Unfortunately it is
On Wed, Aug 05, 2009 at 11:08:26AM +0200, Boszormenyi Zoltan wrote:
I have looked at it. The code seems to be invalid.
Yes, it is, I was too lazy to make it valid. If you just allocate the memory
for the variable in get_var() it becomes valid.
I tried to compile your code (with my previous fix
On Tue, Aug 4, 2009 at 19:13, Kevin Fieldkevinjamesfi...@gmail.com wrote:
On Sat, Aug 1, 2009 at 20:30, Kevin Fieldkevinjamesfi...@gmail.com
wrote:
The event viewer says:
The description for Event ID ( 0 ) in Source ( PostgreSQL )
cannot
be
found. The local computer may not
Michael Meskes írta:
On Wed, Aug 05, 2009 at 11:08:26AM +0200, Boszormenyi Zoltan wrote:
I have looked at it. The code seems to be invalid.
Yes, it is, I was too lazy to make it valid. If you just allocate the memory
for the variable in get_var() it becomes valid.
With
Right now, I do this like this:
if ($err =~ /name_of_first_foreign_key/) {
$r-error_exit('First error message.')
}
elsif ($err =~ /name_of_second_foreign_key/) {
...
As an aside comment, a bit more regex foo with \b is indicated here :-)
if ($err =~ /\bname_of_first_foreign_key\b/) {
Tom Lane wrote:
So my feeling is that adding GRANT ON VIEW is a bad idea. The main
argument for doing it seemed to be that the author wanted to be able
to grant different default privileges for tables and views, but I'm
unconvinced that there's a strong use-case for that. You could very
Yes
On Tue, Aug 04, 2009 at 01:12:10PM -0400, Alvaro Herrera wrote:
First we need several new error message fields: table name, function
name, constraint name, and so on. One possible way to go about this
would be to give each new field its own start letter (see
On Wednesday 05 August 2009 02:43:19 Alvaro Herrera wrote:
I'm wondering if dropping SPI_* manpages is really what we want. Maybe
we could add them to man section 3? I know I've wanted to have them a
couple of times.
Not sure about dblink.
This was just the status quo. We could add more
On Sun, Aug 2, 2009 at 7:57 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The reason for this regression is that Tom asked me to change
ExplainStmt to just carry a list of nodes and to do all the parsing in
ExplainQuery. Unfortunately, the TupleDesc is
Robert Haas wrote:
On Sun, Aug 2, 2009 at 7:57 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The reason for this regression is that Tom asked me to change
ExplainStmt to just carry a list of nodes and to do all the parsing in
ExplainQuery.
What are people doing with parsing error messages for column names for
datatype mismatches? I can't imagine any of my code being able to do
anything sensible in such a case. If it's things like people giving
dates to the database in an incorrect format then that's what they get
for not
Since Alvaro is talking about error messages in another thread, I
figured I should post this idea now as well.
Something that keeps annoying me a lot when trying to look through
what comes out of PostgreSQL logs is that errors generated by the user
(syntax errors in queries, warnings due to
On Sat, Jul 25, 2009 at 04:38:25PM -0500, Jaime Casanova wrote:
1) This is in /src/interfaces/ecpg/ecpglib/sqlda.c, and doesn't seems
something we want in our files... looking at actual code seems like
ecpg.c have something similar but at least specify that it has the
same license as
On Wed, Aug 5, 2009 at 7:20 AM, Andrew Dunstanand...@dunslane.net wrote:
Robert Haas wrote:
On Sun, Aug 2, 2009 at 7:57 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The reason for this regression is that Tom asked me to change
ExplainStmt to just carry a
On Wed, Aug 05, 2009 at 11:52:57AM +0200, Boszormenyi Zoltan wrote:
This means that what I did in my first patch for this
problem in add_struct_to_head() (unrolling members
of the struct) has to be done in adjust_informix(),
turning it into a recursive function.
I think this would be a good
On Wed, Aug 05, 2009 at 01:29:13PM +0200, Pavel Stehule wrote:
What are people doing with parsing error messages for column names for
datatype mismatches? I can't imagine any of my code being able to do
anything sensible in such a case. If it's things like people giving
dates to the
Michael,
I confess I haven't been following the ECPG threads real closely, but
I'm confused as to the status of the following two patches. Have you
reviewed these? If so, what was the outcome? If not, do you plan to?
When?
ECPG dynamic cursor, SQLDA support
ECPG support for string
On Tue, Jul 28, 2009 at 15:45, Tom Lanet...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Jul 27, 2009 at 16:14, Tom Lanet...@sss.pgh.pa.us wrote:
I'm not really insisting on a redesign. I'm talking about the places
where the code author appears not to have
I confess I haven't been following the ECPG threads real closely, but
I'm confused as to the status of the following two patches. Have you
reviewed these? If so, what was the outcome? If not, do you plan to?
I did a first review and then left for my vacation. Now Zoltan provided an
updated
Michael Meskes írta:
On Wed, Aug 05, 2009 at 11:52:57AM +0200, Boszormenyi Zoltan wrote:
This means that what I did in my first patch for this
problem in add_struct_to_head() (unrolling members
of the struct) has to be done in adjust_informix(),
turning it into a recursive function.
I
Michael Meskes írta:
I confess I haven't been following the ECPG threads real closely, but
I'm confused as to the status of the following two patches. Have you
reviewed these? If so, what was the outcome? If not, do you plan to?
I did a first review and then left for my vacation. Now
On Wed, Aug 5, 2009 at 09:24, Peter Eisentrautpete...@gmx.net wrote:
So the next step to documentation bliss is to get rid of the man.tar.gz and
postgres.tar.gz tarballs that are shipped inside the tarball. These are
historical artifacts from the era when building the documentation for release
Peter Eisentraut wrote:
On Wednesday 05 August 2009 02:43:19 Alvaro Herrera wrote:
I'm wondering if dropping SPI_* manpages is really what we want. Maybe
we could add them to man section 3? I know I've wanted to have them a
couple of times.
Not sure about dblink.
This was just the
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Want me to change those or are you on it already?
I'm going to bed --- if you wanna do it, have at it ...
Ok.
I note that many of the messages currently print the relpath() of the
relation, and don't include the
Hi,
I'm trying to develop a contrib module in order to parse sqlf queries, I'm
using lemon as a LALR parser generator (because I think it's easier than
bison) and re2c (because I think it's easier than flex) but when I try to
split the string into words postgres add some weird characters (this
On Wed, Aug 05, 2009 at 03:04:00PM +0200, Boszormenyi Zoltan wrote:
My question is: why not unroll the struct in the preprocessor?
The problem is not that the struct is unrolled in the preprocessor. I just
don't like the idea of having two places where structs are unrolled when one
could be
Magnus Hagander mag...@hagander.net writes:
I'd like to add another field to messages called source (not wedded
to the name). Initially, this could just be user and internal, but
I can see a use-case in the future for it to differ between for
example archiver and bgwriter (it's certainly not
On Wed, Aug 5, 2009 at 9:02 AM, Michael Meskesmes...@postgresql.org wrote:
I confess I haven't been following the ECPG threads real closely, but
I'm confused as to the status of the following two patches. Have you
reviewed these? If so, what was the outcome? If not, do you plan to?
I did a
Magnus Hagander wrote:
Something that keeps annoying me a lot when trying to look through
what comes out of PostgreSQL logs is that errors generated by the user
(syntax errors in queries, warnings due to incorrect string escaping,
statements terminated due to timeout etc etc) are intermixed
Robert Haas robertmh...@gmail.com writes:
(2) Is it worth making this work?
No, I don't think so. The odds of such a test ever showing anything
interesting seem minimal.
plpgsql's inability to cope with the case would be nice to fix, but
I'm not holding my breath for it...
Michael Meskes írta:
On Wed, Aug 05, 2009 at 11:08:26AM +0200, Boszormenyi Zoltan wrote:
I have looked at it. The code seems to be invalid.
Yes, it is, I was too lazy to make it valid. If you just allocate the memory
for the variable in get_var() it becomes valid.
If you meant
Michael Meskes írta:
On Wed, Aug 05, 2009 at 03:04:00PM +0200, Boszormenyi Zoltan wrote:
My question is: why not unroll the struct in the preprocessor?
The problem is not that the struct is unrolled in the preprocessor. I just
don't like the idea of having two places where structs
Sam Mason s...@samason.me.uk wrote:
On Wed, Aug 05, 2009 at 01:29:13PM +0200, Pavel Stehule wrote:
When you have a full set of constraint, then you don't need to
validate input. Just you will execute statement.
Constraints are different from input validation as they rely on
state that
Werner Echezuria werc...@gmail.com writes:
I'm trying to develop a contrib module in order to parse sqlf queries, I'm
using lemon as a LALR parser generator (because I think it's easier than
bison) and re2c (because I think it's easier than flex) but when I try to
split the string into words
On Aug 4, 2009, at 11:10 PM, Tom Lane wrote:
Want me to change those or are you on it already?
I'm going to bed --- if you wanna do it, have at it ...
Oh please. Everyone knows that you don't sleep, Tom. You just sit back
in your chair and power nap for five minutes once in a while,
Boszormenyi Zoltan írta:
Michael Meskes írta:
On Wed, Aug 05, 2009 at 11:08:26AM +0200, Boszormenyi Zoltan wrote:
I have looked at it. The code seems to be invalid.
Yes, it is, I was too lazy to make it valid. If you just allocate the memory
for the variable in
2009/8/5 Magnus Hagander mag...@hagander.net:
Since Alvaro is talking about error messages in another thread, I
figured I should post this idea now as well.
Something that keeps annoying me a lot when trying to look through
what comes out of PostgreSQL logs is that errors generated by the
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I note that many of the messages currently print the relpath() of the
relation, and don't include the affected segment suffix. For example:
could not read block 14 of relation base/11566/24614: read only 1
of 8192 bytes
If
Magnus Hagander mag...@hagander.net writes:
But. I'll look into cleaning those up for HEAD anyway, but due to lack
of reports I think we should skip backpatch. Reasonable?
Fair enough.
Here's what I came up with. Seems ok?
Works for me.
regards, tom lane
--
Sent
Petr Jelinek pjmo...@pjmodos.net writes:
Tom Lane wrote:
What I suggest as a way to resolve this last point is that a default ACL
should apply only to objects owned by the user who creates/modifies the
default ACL. In this view, the question of which schema the objects are
in is just an
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I note that many of the messages currently print the relpath() of the
relation, and don't include the affected segment suffix. For example:
could not read block 14 of relation base/11566/24614: read only 1
Hi,
Well, I use TextDatumGetCString in the main file, but it remains with the
weird characters.
this is the main file:
#include postgres.h
#include fmgr.h
#include gram.h
#include sqlf.h
#include utils/builtins.h
extern Datum sqlf(PG_FUNCTION_ARGS);
PG_MODULE_MAGIC;
Werner Echezuria werc...@gmail.com writes:
Well, I use TextDatumGetCString in the main file, but it remains with the
weird characters.
Hmm, no ideas then. Your interface code looks fine (making parse_str
const seems a bit strange, but it's not related to the problem at hand).
Given that the
Tom Lane escribió:
Well, it'd mainly be a question of whether there's enough interest out
there, which I can't judge. From a project standpoint we just require
that it be BSD-licensed and not impose any undue new burden on
maintainers (thus not wanting new build tools), but beyond that it's
Thanks for help
Edson Ramiro
On Tue, Aug 4, 2009 at 17:49, Tom Lane t...@sss.pgh.pa.us wrote:
Edson Ramiro erlfi...@gmail.com writes:
Does someone has some material which explain how the executor works?
Did you read
http://developer.postgresql.org/pgdocs/postgres/overview.html
and
On Wed, Aug 05, 2009 at 09:30:02AM -0500, Kevin Grittner wrote:
Anyway, the upshot is -- I think that it would be beneficial to allow,
to the extent we can confirm it's not a violation of any applicable
standard, a user-defined SQLSTATE to be associated with a constraint.
I also think that it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tom Lane wrote:
Could you do something like
be_pid = pg_backend_pid() AS is_self_notify
instead, to verify that it's a self-notify? (This is not quite right
because you'd need to execute pg_backend_pid() at the remote end, but
I'm not
Sam Mason s...@samason.me.uk wrote:
Not sure if overloading SQLSTATE is the right way of doing this is
it? It already has things like 23514 for a check violation and any
other client code relying in this would break if it started getting
different things back.
If that's the standard
On Mon, Jul 20, 2009 at 2:12 AM, Nikhil
Sontakkenikhil.sonta...@enterprisedb.com wrote:
The review is complete from my side. There is this question about
consistency between this patch and the Defaultacls patch. But am ok
with this patch on its own. So ready for committer from my side.
My
On Sun, Aug 2, 2009 at 3:05 PM, Jeff Davispg...@j-davis.com wrote:
The patch looks good.
Comments:
1. The docs should be clarified a little. For instance, it should have a
link back to the definition of a prefix search (12.3.2). I included my
doc suggestions as an attachment.
2.
Robert Haas robertmh...@gmail.com writes:
My understanding is that this patch will need to be reworked as well
based on Tom's comments on DefaultACLs. Does that sound right?
Should we expect a new version this week, or defer this until the
September CommitFest?
I was planning to go review
Folks,
We now have just 10 days left in this CommitFest and I think it is
time to start thinking about closing up shop. My tentative plan,
absent strong objections, is to wait until Friday night and then move
most or all of the patches that are still Waiting on Author to
Returned with Feedback.
Tom Lane wrote:
I'm not sure whether there is consensus on not using GRANT ON VIEW
(ie, having these patches treat tables and views alike). I was waiting
to see if Stephen would put forward a convincing counterargument ...
Conceptually it is right, I think. A view is a virtual table,
On Wed, Aug 5, 2009 at 12:40 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
My understanding is that this patch will need to be reworked as well
based on Tom's comments on DefaultACLs. Does that sound right?
Should we expect a new version this week, or defer
Robert Haas robertmh...@gmail.com writes:
... bulk-grant could be based on object type,
object name (with wildcard or regexp pattern), schema membership, or
maybe other things, and I think that would be quite useful if we can
figure out how to make it clean and elegant.
Yeah. In the end you
On Wed, Aug 05, 2009 at 11:32:06AM -0500, Kevin Grittner wrote:
Sam Mason s...@samason.me.uk wrote:
Not sure if overloading SQLSTATE is the right way of doing this is
it? It already has things like 23514 for a check violation and any
other client code relying in this would break if it
Petr Jelinek pjmo...@pjmodos.net writes:
One more typo fix in docs
I took a quick look at this version of the patch. Other than the
already-mentioned question of whether we really want to create a
distinction between tables and views in GRANT, there's not that
much there to criticize. I do
Sam Mason s...@samason.me.uk wrote:
It just looks like a fixed set of numbers for a fixed set of
conditions, can't find any canonical definition about what it's
really for though.
Sorry, I'm familiar with the SQLSTATE's role in the spec, I just
wasn't sure how specific they got in their
Robert Haas robertmh...@gmail.com writes:
Between now and then, I'm going to be working on identifying which
patches are not marked as Waiting on Author but should be, or which
are marked as Waiting on Author but shouldn't be.
Er, shouldn't you first work on finishing your own patches? The
Hi,
I've noticed that on 8.4.0, commits can take a long time when a temp table is
repeatedly
filled and truncated within a loop. A very contrived example is
begin;
create or replace function commit_test_with_truncations()
returns void
language 'plpgsql'
as $_func_$
declare
I wrote:
kar...@sao.ru (Sergey V. Karpov) writes:
Andres Freund and...@anarazel.de writes:
Looks nice. The only small gripe I have is that the patch adds trailing
whitespaces at a lot of places...
My fault. Please check the patch version attached - I've tried to fix
all those.
I did some
On Wed, Aug 05, 2009 at 12:41:30PM -0500, Kevin Grittner wrote:
From the spec:
The character string value returned in an SQLSTATE parameter
comprises a 2-character class value followed by a 3-character subclass
value, each with an implementation-defined character set that has a
one-octet
Sam Mason s...@samason.me.uk writes:
On Wed, Aug 05, 2009 at 12:41:30PM -0500, Kevin Grittner wrote:
Anyway, it was a bad suggestion that we provide a way to specify a
SQLSTATE to use for a constraint failure. I do think that some field
which could be used for that purpose would be good.
Sam Mason s...@samason.me.uk writes:
On Wed, Aug 05, 2009 at 12:41:30PM -0500, Kevin Grittner wrote:
From the table, the 23xxx series is for integrity constraint
violations, but they appear not to have gotten too specific about
breaking that down; thereby leaving it as an implementation
Tom Lane wrote:
I do have a feeling that the implementation
is a bit too narrowly focused on the stuff IN SCHEMA foo case;
if we were ever to add other filtering options it seems like we'd
have to rip all this code out and start over. But I don't have any
immediate ideas on what it should look
Sam Mason s...@samason.me.uk wrote:
Still doesn't really describe the
engineering rational behind it though.
Well, the distinctions in many cases would be mostly of interest to a
DBA managing a large shop who was trying to characterize the reasons
for query failure. Some codes, however,
2009/8/5 Tom Lane t...@sss.pgh.pa.us:
Sam Mason s...@samason.me.uk writes:
On Wed, Aug 05, 2009 at 12:41:30PM -0500, Kevin Grittner wrote:
Anyway, it was a bad suggestion that we provide a way to specify a
SQLSTATE to use for a constraint failure. I do think that some field
which could be
Tom,
I took a quick look at this version of the patch. Other than the
already-mentioned question of whether we really want to create a
distinction between tables and views in GRANT, there's not that
much there to criticize.
It's pretty common to have a database where there are some users
Hi,
In warm standby system when we have a filled log segment forwarded to
archiving, there is an inconsistency on standby next value sequences
obtained by a call to nextval() function. e.g.:
* Primary server
- Create sequence seq_a;
- Select nextval ( 'seq_a'); # value 1;
- Log shipping;
*
On Wed, Aug 5, 2009 at 1:43 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Between now and then, I'm going to be working on identifying which
patches are not marked as Waiting on Author but should be, or which
are marked as Waiting on Author but shouldn't be.
On Wed, Aug 5, 2009 at 2:57 PM, Josh Berkusj...@agliodbs.com wrote:
Right now we have a situation where most web developers aren't using
ROLEs *at all* because they are too complex for them to bother with. I
literally couldn't count the number of production applications I've run
across which
Tom Lane wrote:
Peter pointed out upthread that the SQL standard already calls out some
things that should be available in this way --- has anyone studied that
yet?
Yeah, I gave it a look. It looks useful as a guide, though obviously
not directly implementable because it relies on GET
Leonardo Cezar lhce...@gmail.com writes:
In warm standby system when we have a filled log segment forwarded to
archiving, there is an inconsistency on standby next value sequences
obtained by a call to nextval() function. e.g.:
* Primary server
- Create sequence seq_a;
- Select nextval (
On Wed, 2009-08-05 at 12:34 -0400, Robert Haas wrote:
Oleg,
Are you planning to update this patch this week? If not I will set it
to Returned with Feedback.
My only comments were related to docs and comments, and I supplied a
patch as a suggested fix for the docs. Also, the patch is very
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
Peter pointed out upthread that the SQL standard already calls out some
things that should be available in this way --- has anyone studied that
yet?
Yeah, I gave it a look. It looks useful as a guide, though obviously
not
2009/8/5 Tom Lane t...@sss.pgh.pa.us:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
Peter pointed out upthread that the SQL standard already calls out some
things that should be available in this way --- has anyone studied that
yet?
Yeah, I gave it a look. It looks
Robert Haas robertmh...@gmail.com writes:
I have one database that is set up with a reporting user (read only on
everything). It requires constant maintenance. Every time an object
is added or deleted (or dropped and recreated, like a view, which I do
ALL THE TIME to work around the
On Wed, Aug 5, 2009 at 3:40 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I have one database that is set up with a reporting user (read only on
everything). It requires constant maintenance. Every time an object
is added or deleted (or dropped and
Todd A. Cook tc...@blackducksoftware.com writes:
I've noticed that on 8.4.0, commits can take a long time when a temp table is
repeatedly
filled and truncated within a loop. A very contrived example is
Hmm. I tweaked the function to allow varying the number of truncates:
regression=#
2009/8/5 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
I have one database that is set up with a reporting user (read only on
everything). It requires constant maintenance. Every time an object
is added or deleted (or dropped and recreated, like a view, which I do
Tom Lane t...@sss.pgh.pa.us wrote:
Todd A. Cook tc...@blackducksoftware.com writes:
I've noticed that on 8.4.0, commits can take a long time when a
temp table is repeatedly filled and truncated within a loop.
The commit time doesn't seem tremendously out of line, but it looks
like there's
What I would like to avoid is a situation where we're basically ready
to go with beta and Bruce says, Hold on, everybody, it's going to
take another two weeks while I plow through 600 commit messages. I
have a theory that that work can be spread out and much of it done in
advance and not
Josh's position that this should be standard SQL is nonsense, or
at least he ought to be making that argument to the standards committee
not us.
Huh? When did I say that?
If we want something built-in, maybe providing some prefab plpgsql
functions is the way to go. But we'd have to
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Todd A. Cook tc...@blackducksoftware.com writes:
I've noticed that on 8.4.0, commits can take a long time when a
temp table is repeatedly filled and truncated within a loop.
The commit time doesn't seem
Josh Berkus j...@agliodbs.com writes:
Josh's position that this should be standard SQL is nonsense, or
at least he ought to be making that argument to the standards committee
not us.
Huh? When did I say that?
Sorry, I think I got one of your messages confused with one of Robert's.
Anyway,
Josh Berkus wrote:
What I would like to avoid is a situation where we're basically ready
to go with beta and Bruce says, Hold on, everybody, it's going to
take another two weeks while I plow through 600 commit messages. I
have a theory that that work can be spread out and much of it
On Wed, 2009-08-05 at 17:11 -0400, Bruce Momjian wrote:
Josh Berkus wrote:
As far as the alpha releases, I am still worried about the use of the
word alpha. I am worried someone is going to look at 8.4alpha1 and
think that represents most of the features that will be in 8.5final, and
will
Bruce Momjian br...@momjian.us writes:
As far as the alpha releases, I am still worried about the use of the
word alpha. I am worried someone is going to look at 8.4alpha1 and
think that represents most of the features that will be in 8.5final, and
will think the Postgres project is losing
As far as the alpha releases, I am still worried about the use of the
word alpha. I am worried someone is going to look at 8.4alpha1 and
think that represents most of the features that will be in 8.5final, and
will think the Postgres project is losing momentum. I would much rather
they be
--On Mittwoch, August 05, 2009 05:28:55 +0200 Pavel Stehule
pavel.steh...@gmail.com wrote:
At least, we need to document that both notations behaves different in
this case.
+1
Here again a patch version with updated documentation. I will stop
reviewing this patch now and mark this ready
Bruce Momjian wrote:
I would much rather
they be called Commit Feast 1 (CF1), or something like that.
ITYM Fest, although sometimes we make a meal of it ;-)
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Tom Lane t...@sss.pgh.pa.us wrote:
we need something that is alphanumerically less than beta.
antebeta1?
Then, each commit-fest, we up the ante
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
we need something that is alphanumerically less than beta.
antebeta1?
Then, each commit-fest, we up the ante
rotfl...
Actually just ante1 would work better for that joke.
On Wed, 2009-08-05 at 16:34 -0500, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
we need something that is alphanumerically less than beta.
antebeta1?
Then, each commit-fest, we up the ante
1stCF09
2ndCF09
3rdCF09
-Kevin
--
PostgreSQL - XMPP:
Tom Lane wrote:
So what I'm seeing is entirely explained by the buildup of dead versions
of the temp table's pg_class row --- the index_getnext time is spent
scanning over dead HOT-chain members. It might be possible to avoid
that by special-casing temp tables in TRUNCATE to recycle the
On Aug 5, 2009, at 3:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Leonardo Cezar lhce...@gmail.com writes:
In warm standby system when we have a filled log segment forwarded to
archiving, there is an inconsistency on standby next value sequences
obtained by a call to nextval() function. e.g.:
1 - 100 of 122 matches
Mail list logo
