On Sun, May 31, 2009 at 06:32:53PM -0400, Tom Lane wrote:
regression=# select '999'::interval second;
The correct interpretation of the input value is certainly 999 seconds.
Agreed; silent truncation like this is confusing and will lead to
unnecessary bugs in users' code.
the attached patch
Thank you Tom for looking at this.
I would be pleased to help on testing the fix when available.
My plan is to store Informix INTERVALs (coming from the 4gl applications we
support) into PostgreSQL INTERVALs, and I have a bunch of tests for that...
I believe Informix INTERVALs (and related
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
pg_migrator needs hard link() capabiity on Win32 to support its --link
option. Can someone create that and hopefully add it to libpgport?
AFAIK hard links simply don't exist on Windows.
Magnus showed me
Fujii Masao masao.fu...@gmail.com writes:
pg_standby can use ln command to restore an archived file,
which might destroy the archived file as follows.
Does it matter? pg_standby's source area wouldn't normally be an
archive in the real sense of the word, it's just a temporary staging
area
Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
pg_standby can use ln command to restore an archived file,
which might destroy the archived file as follows.
Does it matter? pg_standby's source area wouldn't normally be an
archive in the real sense of the word, it's just a temporary
On Sun, May 31, 2009 at 11:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
(At the risk of beating a dead horse, note if we were upgrading the
catalog tables directly via SQL, this type of scenario could be
handled cleanly without hacking pg_dump; I repeat
Sam Mason s...@samason.me.uk writes:
On Sun, May 31, 2009 at 06:32:53PM -0400, Tom Lane wrote:
There is some case to be made that we should throw error here,
which we could do by putting error tests where the attached patch
has comments suggesting an error test.
With things as they are I
On Mon, Jun 1, 2009 at 4:03 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, May 31, 2009 at 11:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Updating the catalog tables directly via SQL? Good luck making that
work. If you ever get it to work at all, it'll require a pile of hacks
that will
Greg Stark st...@enterprisedb.com writes:
On Mon, Jun 1, 2009 at 4:03 PM, Robert Haas robertmh...@gmail.com wrote:
We really need to figure out an approach that lets us keep the old
datatypes around under a different name while making the original name
be the new version of the datatype. That
* Heikki Linnakangas heikki.linnakan...@enterprisedb.com [090601 10:56]:
Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
pg_standby can use ln command to restore an archived file,
which might destroy the archived file as follows.
Does it matter? pg_standby's source area wouldn't
On Mon, Jun 1, 2009 at 11:10 AM, Greg Stark st...@enterprisedb.com wrote:
On Mon, Jun 1, 2009 at 4:03 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, May 31, 2009 at 11:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Updating the catalog tables directly via SQL? Good luck making that
work. If
On Mon, Jun 1, 2009 at 11:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@enterprisedb.com writes:
On Mon, Jun 1, 2009 at 4:03 PM, Robert Haas robertmh...@gmail.com wrote:
We really need to figure out an approach that lets us keep the old
datatypes around under a different name
Robert Haas wrote:
It's certainly the case that there is a lot more work to do before
pg_migrator could support everything that we reasonably want to be
able to do in a version update. ?As I see it, the reason it's getting
revived now is that 8.3-8.4 happens to be an update where most of
Greg Stark wrote:
On Mon, Jun 1, 2009 at 4:03 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, May 31, 2009 at 11:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Updating the catalog tables directly via SQL? ?Good luck making that
work. ?If you ever get it to work at all, it'll require a pile
Dimitri Fontaine wrote:
Le 31 mai 09 à 18:21, Tom Lane a écrit :
You could maybe make this work by executing your own transaction
to do it, but I really have to wonder if it's a good idea. One
point to think about is that elog(ERROR) still means elog(FATAL)
at this point, so any brokenness
As of today we are three months behind the original plan for 8.4.0 release.
In a one-year release cycle that's already pretty bad slip; but there now
seems no chance of a release happening in less than a month, and if we
continue to let things drift it could easily stretch to five or six
months'
On May 29, 1:04 pm, t...@sss.pgh.pa.us (Tom Lane) wrote:
Kevin Field kevinjamesfi...@gmail.com writes:
default:
elog(ERROR, unrecognized raise option: %d,
opt-opt_type);
Should this be changed to:
default:
ereport(ERROR,
On Mon, 2009-06-01 at 12:23 -0400, Alvaro Herrera wrote:
Dimitri Fontaine wrote:
Le 31 mai 09 à 18:21, Tom Lane a écrit :
You could maybe make this work by executing your own transaction
to do it, but I really have to wonder if it's a good idea. One
point to think about is that
Greg,
Well the goal is to make them simpler. I don't know any language that
has implemented what you describe. Either you have access to the
internal methods of a class or you don't and you only have access to
the public api. That seems to work for much more sophisticated
languages than ours
Hi,
Kevin Grittner wrote:
Greg Stark st...@enterprisedb.com wrote:
I would want any serialization failure to be
justifiable by simple inspection of the two transactions.
BTW, there are often three (or more) transaction involved in creating
a serialization failure, where any two of them
Tom Lane t...@sss.pgh.pa.us writes:
[...]
See http://blog.endpoint.com/2009/05/postgresql-with-systemtap.html for
details. Perhaps it's worth noting in the documentation that SystemTap users
will need to use the double-underscore version?
I think a better solution is to persuade the
Hi,
a newish conversion with cvs2git is available to check here:
git://www.bluegap.ch/
(it's not incremental and will only stay for a few days)
For everybody interested, please check the committer names and emails.
I'm missing the names and email addresses for these committers:
'barry'
Robert Haas robertmh...@gmail.com wrote:
But at least it doesn't seem like anyone is seriously arguing that
true serializability wouldn't be a nice feature, if hypothetically
we had an agreed-upon implementation and a high-level developer with
a lot of time on their hands.
If that's true,
On Mon, Jun 1, 2009 at 6:27 PM, Markus Wanner mar...@bluegap.ch wrote:
I'm not that eager on the justifiable by simple inspection requirement
above. I don't think a DBA is commonly doing these inspections at all.
I think a tool to measure abort rates per transaction (type) would serve
the DBA
Markus Wanner mar...@bluegap.ch writes:
I'm missing the names and email addresses for these committers:
'barry' : ('barry??', ''),
Barry Lind, formerly one of the JDBC bunch, been inactive for awhile
'dennis' : ('Dennis??', ''),
I suppose this must be Dennis Björklund, but I didn't
Tom,
Let me start this out by voting the things I think we can drop until 8.5:
* gettext plurals patch needs some polishing
-- revert patch, save for 8.5
# adjust information_schema precision and scale fields?
-- save for 8.5
# instrument the Windows shared memory reattachment problem?
-- as
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Robert Haas robertmh...@gmail.com wrote:
But at least it doesn't seem like anyone is seriously arguing that
true serializability wouldn't be a nice feature, if hypothetically
we had an agreed-upon implementation and a high-level developer
Greg Stark st...@enterprisedb.com wrote:
But it's certainly insufficient in an OLAP or DSS environment where
transactions can take hours. If you can never know for sure that
you've written your transaction safely and it might randomly fail
and need to be retried any given day due to
On Mon, 2009-06-01 at 11:09 -0700, Josh Berkus wrote:
Tom,
# adjust information_schema precision and scale fields?
-- save for 8.5
I read this thread. It seems for the changes we can make we should just
make them. The actual amount of change is actually very nominal.
Joshua D. Drake
--
Josh Berkus j...@agliodbs.com writes:
# cost_nestloop and cost_hashjoin are broken for SEMI and ANTI joins
* tgl says: I think this is mostly dealt with but it could use
performance testing.
Mark? Jignesh? Can you test this?
Actually I'm hoping that Kevin Grittner will have
Kevin,
I'm not sure it's without value to the project; I just don't know that
it would be worth using for us. It seems to be accepted in some other
DBMS products. Since some (like MS SQL Server) allow users to choose
snapshot isolation or blocking-based serializable transactions in
their MVCC
Tom Lane wrote:
Markus Wanner mar...@bluegap.ch writes:
'dennis' : ('Dennis??', ''),
I suppose this must be Dennis Bj�rklund, but I didn't realize he
used to be a committer.
IIRC he was given commit privs for translation files.
--
Alvaro Herrera
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
I suppose this must be Dennis Björklund, but I didn't realize he
used to be a committer.
IIRC he was given commit privs for translation files.
Ah, right, that does ring a bell now.
BTW, Markus: you do realize thomas is not me
On Mon, Jun 1, 2009 at 7:24 PM, Josh Berkus j...@agliodbs.com wrote:
Since some (like MS SQL Server) allow users to choose
snapshot isolation or blocking-based serializable transactions in
their MVCC implementation
This approach allowed MSSQL to clean up on TPCE; to date their performance
Josh Berkus wrote:
Well I don't mind push but I still think pop is an error. What you
really want to do is restore it to the value you started with. You
don't want to remove the last element since that may not be the
element you added. Some function you called may have added an extra
element
On Mon, Jun 1, 2009 at 7:57 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Josh Berkus wrote:
Well I don't mind push but I still think pop is an error. What you
really want to do is restore it to the value you started with. You
don't want to remove the last element since that may not be
Tom Lane escribió:
An
alternative was to not have BEGIN/END but instead a GUC variable that
you can SET to the name of the extension currently being added to.
(The main advantage of that is that the state isn't hidden, but easily
checkable via existing commands.)
With the CREATE EXTENSION
Aidan Van Dyk wrote:
* Heikki Linnakangas heikki.linnakan...@enterprisedb.com [090601 10:56]:
Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
pg_standby can use ln command to restore an archived file,
which might destroy the archived file as follows.
Does it matter? pg_standby's
On May 29, 12:43 pm, Kevin Field kevinjamesfi...@gmail.com wrote:
On May 29, 11:48 am, Kevin Field kevinjamesfi...@gmail.com wrote:
On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote:
On Fri, May 29, 2009 at 7:59 AM, Kevin Field kevinjamesfi...@gmail.com
wrote:
On May
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I wonder if we should just remove the symlink option from pg_standby.
I was considering suggesting that too...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Mon, Jun 01, 2009 at 08:05:33PM +0100, Greg Stark wrote:
As I said earlier I doubt pop or delete is ever going to actually
be what you want. I suspect you're far more likely to want to restore
it to what it was before you started altering it.
As support I'll point out this is what our C
Josh Berkus j...@agliodbs.com writes:
Let me start this out by voting the things I think we can drop until 8.5:
* gettext plurals patch needs some polishing
-- revert patch, save for 8.5
Peter might think differently about that ;-). My problem with it is
that we don't seem to have a polished
On Mon, Jun 1, 2009 at 2:09 PM, Josh Berkus j...@agliodbs.com wrote:
Tom,
Let me start this out by voting the things I think we can drop until 8.5:
* gettext plurals patch needs some polishing
-- revert patch, save for 8.5
# adjust information_schema precision and scale fields?
-- save
On Mon, Jun 1, 2009 at 3:27 PM, Sam Mason s...@samason.me.uk wrote:
On Mon, Jun 01, 2009 at 08:05:33PM +0100, Greg Stark wrote:
As I said earlier I doubt pop or delete is ever going to actually
be what you want. I suspect you're far more likely to want to restore
it to what it was before you
Robert Haas robertmh...@gmail.com writes:
I recommend we create
http://wiki.postgresql.org/wiki/PostgreSQL_8.5_Open_Items and start
bumping things that can't be completed for 8.4.
Why not just the regular TODO list?
Stuff that has plausible patches attached can go directly to the
On Mon, Jun 1, 2009 at 3:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I recommend we create
http://wiki.postgresql.org/wiki/PostgreSQL_8.5_Open_Items and start
bumping things that can't be completed for 8.4.
Why not just the regular TODO list?
Stuff
In the spirit of helping wrap-up 8.4 todo items...
Robert Haas wrote:
On Mon, May 25, 2009 at 6:15 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Now I'm still not exactly happy with GEQO, but it's surely a lot better
than it was in the fall of 2000. So on the whole it does seem that the
current
Greg Stark st...@enterprisedb.com wrote:
If you can never know for sure that you've written your transaction
safely
Whoa! I just noticed this phrase on a re-read. I think there might
be some misunderstanding here.
You can be sure you've written your transaction safely just as soon as
During integration gcc4.2 into Solaris. My colleague hit a following
problem with PostgreSQL compilation:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6845982
cd
/builds/sfw-fixes/usr/src/cmd/postgres/postgresql-8.2/postgresql-8.2.13/src/pl/plperl
+
On Mon, Jun 1, 2009 at 3:57 PM, Zdenek Kotala zdenek.kot...@sun.com wrote:
During integration gcc4.2 into Solaris. My colleague hit a following
problem with PostgreSQL compilation:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6845982
cd
On Mon, Jun 1, 2009 at 8:55 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Whoa! I just noticed this phrase on a re-read. I think there might
be some misunderstanding here.
You can be sure you've written your transaction safely just as soon as
your COMMIT returns without error.
I
Zdenek Kotala zdenek.kot...@sun.com writes:
My idea is to rename list_head to pg_list_head (and other functions
analogously) to avoid name conflict.
There is zero chance of that happening. We have thousands of references
to those functions in the core code, and who knows how many more in
Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
# instrument the Windows shared memory reattachment problem?
-- as much as I'd like to do this, the solution could be as bad as the
problem; we'd need more testing time for new instrumentation. Will have
to deal with via testing patched
On Mon, Jun 1, 2009 at 4:08 PM, Greg Stark st...@enterprisedb.com wrote:
On Mon, Jun 1, 2009 at 8:55 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Whoa! I just noticed this phrase on a re-read. I think there might
be some misunderstanding here.
You can be sure you've written your
Greg Stark st...@enterprisedb.com wrote:
On Mon, Jun 1, 2009 at 8:55 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
You can be sure you've written your transaction safely just as soon
as your COMMIT returns without error.
I think we have different definitions of safely. You only
Robert Haas píše v po 01. 06. 2009 v 16:03 -0400:
On Mon, Jun 1, 2009 at 3:57 PM, Zdenek Kotala zdenek.kot...@sun.com wrote:
During integration gcc4.2 into Solaris. My colleague hit a following
problem with PostgreSQL compilation:
All,
I just realized that even if you do this:
table foo (
id serial,
bar varchar(200)
)
ALTER TABLE foo ALTER COLUMN bar TYPE VARCHAR(1000)
... it triggers a heap index rebuild, even though it's completely
unnecessary. Is this a special case of VARCHAR, or are
Magnus Hagander mag...@hagander.net writes:
Tom Lane wrote:
# instrument the Windows shared memory reattachment problem?
Yeah. That was put on the list a month ago, when there was still plenty
of time to do something about it; but since we missed getting it into
beta2 I think it will have
Josh Berkus j...@agliodbs.com writes:
I just realized that even if you do this:
ALTER TABLE foo ALTER COLUMN bar TYPE VARCHAR(1000)
... it triggers a heap index rebuild, even though it's completely
unnecessary.
Yeah, this has been discussed before; I think it's even in the TODO
list. The
Tom Lane píše v po 01. 06. 2009 v 16:09 -0400:
Zdenek Kotala zdenek.kot...@sun.com writes:
What is sys/list.h, and why is it being imported by the Perl headers?
It seems that problem is with Perl. It includes sys/mode.h. The new
change for gcc 4.2 is that mode.h includes vnode.h and it
Josh Berkus j...@agliodbs.com wrote:
This approach allowed MSSQL to clean up on TPCE; to date their
performance on that benchmark is so much better than anyone else
nobody else wants to publish.
Since they use a compatibility level setting to control whether a
request for a serializable
On Mon, 2009-06-01 at 13:26 -0700, Josh Berkus wrote:
All,
I just realized that even if you do this:
table foo (
id serial,
bar varchar(200)
)
ALTER TABLE foo ALTER COLUMN bar TYPE VARCHAR(1000)
... it triggers a heap index rebuild, even though it's completely
On Mon, Jun 1, 2009 at 9:24 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
I'm concerned with whether you can be sure that the 999th time you
run it the database won't randomly decide to declare a serialization
failure for reasons you couldn't predict were possible.
Now you're
On Mon, Jun 1, 2009 at 9:49 PM, Jeff Davis pg...@j-davis.com wrote:
NUMERIC(x, y) comes to mind, although that might be a more dangerous
case. If you turn a NUMERIC(5,0) into a NUMERIC(5,1), then '1.2' may be
stored as either '1' or '1.2' depending on whether you did the insert
before or
On Mon, 2009-06-01 at 22:12 +0100, Greg Stark wrote:
No, I'm not. I'm questioning whether a serializable transaction
isolation level that makes no guarantee that it won't fire spuriously
is useful.
I am also concerned (depending on implementation, of course) that
certain situations can make it
On Mon, Jun 1, 2009 at 10:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We could certainly put in a quick hack that just covered a few of the
cases for built-in types, but it's not very pleasing ...
Jonah proposed a patch for that a long time ago.
See
Yeah, this has been discussed before; I think it's even in the TODO
list.
I couldn't find it. At least, not under data types, and also not with
the keyword typemod. Anyone see it?
The stumbling block has been to identify a reasonably clean way
of determining which datatype changes don't
On Mon, 2009-06-01 at 14:39 -0700, Josh Berkus wrote:
Note that this doesn't deal with the special case of VARCHAR--TEXT, but
just with changing typemods. Are there other cases of data *type*
conversions where no check or rebuild is required? Otherwise we might
just special case
Greg Stark st...@enterprisedb.com wrote:
On Mon, Jun 1, 2009 at 9:24 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
I'm concerned with whether you can be sure that the 999th time you
run it the database won't randomly decide to declare a
serialization failure for reasons you couldn't
Jeff,
I observe that the casts (VARCHAR - TEXT and TEXT - VARCHAR) are
marked WITHOUT FUNCTION. If that's the case, can't we use that to say
that no heap rebuild is required? Perhaps we'll need to combine this
with the typmod checks to see if we need to check the heap.
yeah, you're right ..
Jeff Davis pg...@j-davis.com wrote:
On Mon, 2009-06-01 at 22:12 +0100, Greg Stark wrote:
No, I'm not. I'm questioning whether a serializable transaction
isolation level that makes no guarantee that it won't fire
spuriously is useful.
I am also concerned (depending on implementation, of
Josh Berkus j...@agliodbs.com wrote:
So, at least theoretically, anyone who had a traffic mix similar to
TPCE would benefit. Particularly, some long-running serializable
transactions thrown into a mix of Read Committed and Repeatable
Read transactions, for a stored procedure driven
Josh Berkus j...@agliodbs.com writes:
yeah, you're right .. that would give us a short list of conversions
which don't require a rewrite.However, as Tom points out, that
doesn't mean that they might not need a reindex (as well as OID, there's
also XML).
Um. I had actually forgotten
Josh Berkus j...@agliodbs.com writes:
Yeah, this has been discussed before; I think it's even in the TODO
list.
I couldn't find it. At least, not under data types, and also not with
the keyword typemod. Anyone see it?
It's the last item under ALTER:
* Don't require table rewrite on ALTER
Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
cost_nestloop and cost_hashjoin are broken for SEMI and ANTI joins
Actually I'm hoping that Kevin Grittner will have something to
report on that one soon
So far, I haven't found any performance regressions in the
On Mon, Jun 1, 2009 at 11:07 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Greg Stark st...@enterprisedb.com wrote:
No, I'm not. I'm questioning whether a serializable transaction
isolation level that makes no guarantee that it won't fire
spuriously is useful.
Well, the technique
I wrote:
Sam Mason s...@samason.me.uk writes:
On Sun, May 31, 2009 at 06:32:53PM -0400, Tom Lane wrote:
There is some case to be made that we should throw error here,
which we could do by putting error tests where the attached patch
has comments suggesting an error test.
With things as they
Greg Stark st...@enterprisedb.com wrote:
Just as carefully written SQL code can be written to avoid deadlocks
I would expect to be able to look at SQL code and know it's safe
from serialization failures, or at least know where they might
occur.
This is the crux of our disagreement, I
Hi,
On Mon, Jun 1, 2009 at 11:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
pg_standby can use ln command to restore an archived file,
which might destroy the archived file as follows.
Does it matter? pg_standby's source area wouldn't normally be an
On Mon, Jun 1, 2009 at 8:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Sam Mason s...@samason.me.uk writes:
On Sun, May 31, 2009 at 06:32:53PM -0400, Tom Lane wrote:
There is some case to be made that we should throw error here,
which we could do by putting error tests where the attached
Robert Haas robertmh...@gmail.com writes:
More to the point, it's also what 8.3.7 does:
Well, no, because the cases at issue are where an interval qualifier
is specified. 8.3 did this:
regression=# select '99 seconds'::interval second;
interval
--
00:00:39
(1 row)
and even more
Fujii Masao masao.fu...@gmail.com writes:
If so, it might be deleted after triggering the warm-standby. But, we cannot
remove it because the latest xlog file which is required for normal recovery
might exist in it. This is another undesirable scenario. Is this problem?
What recovery? In the
Joe Conway m...@joeconway.com writes:
Probably better if I break this up in logical chunks too. This patch
only addresses the refactoring you requested here:
http://archives.postgresql.org/message-id/28719.1230996...@sss.pgh.pa.us
This looks sane to me in a quick once-over, though I've not
Hi,
On Tue, Jun 2, 2009 at 10:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
If so, it might be deleted after triggering the warm-standby. But, we cannot
remove it because the latest xlog file which is required for normal recovery
might exist in it. This
Joe Conway m...@joeconway.com writes:
Here's a much simpler SQL/MED support patch for dblink.
This enforces security in the same manner for FOREIGN SERVER connections
as that worked out over time for other dblink connections. Essentially,
the FOREIGN SERVER and associated user MAPPING
Fujii Masao masao.fu...@gmail.com writes:
Yes, the old xlog itself is not used again. But, the *old file* might
be recycled and used later. The case that I'm looking at is that the
symlink to a temporary area is recycled. Am I missing something?
Actually, I think the right fix for that would
Sushant Sinha sushant...@gmail.com wrote:
I think that dot should be considered by as a word delimiter because
when dot is not followed by a space, most of the time it is an error
in typing. Beside they are not many valid english words that have
dot in between.
It's not treating it as an
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
cost_nestloop and cost_hashjoin are broken for SEMI and ANTI joins
Actually I'm hoping that Kevin Grittner will have something to
report on that one soon
So far,
Joshua D. Drake j...@commandprompt.com writes:
On Mon, 2009-06-01 at 11:09 -0700, Josh Berkus wrote:
# adjust information_schema precision and scale fields?
-- save for 8.5
I read this thread. It seems for the changes we can make we should just
make them. The actual amount of change is
Hi,
On Tue, Jun 2, 2009 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
Yes, the old xlog itself is not used again. But, the *old file* might
be recycled and used later. The case that I'm looking at is that the
symlink to a temporary area is recycled.
Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
Tom Lane wrote:
I think what this suggests is that there probably needs to be some
encoding conversion logic near the places we examine localeconv()
output.
Attached is a patch to the current CVS.
It uses a similar way like LC_TIME
Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
Probably better if I break this up in logical chunks too. This patch
only addresses the refactoring you requested here:
http://archives.postgresql.org/message-id/28719.1230996...@sss.pgh.pa.us
This looks sane to me in a quick once-over,
Euler Taveira de Oliveira wrote:
Robert Haas escreveu:
...EXPLAIN ANALYZE reports the number of rows as an integer... Any
chance we could reconsider this decision? I often find myself wanting
to know the value that is here called ntuples, but rounding
ntuples/nloops off to the nearest
On Mon, Jun 1, 2009 at 3:34 PM, Selena Deckelmann sel...@endpoint.com wrote:
In the spirit of helping wrap-up 8.4 todo items...
Robert Haas wrote:
For 8.4, I'd be happy to just improve the documentation. I think this
sentence could just be deleted from the section on
from_collapse_limit:
My
On Mon, Jun 1, 2009 at 12:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
As of today we are three months behind the original plan for 8.4.0 release.
In a one-year release cycle that's already pretty bad slip; but there now
seems no chance of a release happening in less than a month, and if we
If the connection isn't over SSL, there's no need to do the disable.
This effectively halves the number of syscalls performed by libpq when
SSL is not in use.
Signed-off-by: Jeremy Kerr j...@ozlabs.org
---
src/interfaces/libpq/fe-secure.c |7 +++
1 file changed, 3 insertions(+), 4
Currently, I'm seeing the psecure_{red,write} functions being invoked
when connecting to postgres via a unix domain socket. psecure_write
seems to alter the signal mask of the process to disable sigpipe
reporting. psecure_read only does this when the connection is using SSL.
When using a
On Mon, 1 Jun 2009, Robert Haas wrote:
Regarding this item:
* Consider reverting preventing regular users from base type creation
You raise this point:
tgl says: whether or not we think PL/Java is bulletproof, there are
other problems, for instance this one
98 matches
Mail list logo
