On Tue, February 13, 2007 07:39, Tom Lane wrote:
Lukas Kahwe Smith [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Lukas Kahwe Smith wrote:
http://developer.postgresql.org/index.php/IRC2RWNames
Ah, excellent. Should we put this in the IRC topic line?
if there is still some space in
I know. My guess is the parser does not read the stop word file at
least with default configuration.
Parser should not read stopword file: its deal for dictionaries.
So if a character is not ASCII, it returns 0 even if p_isalpha returns
1. Is this what you expect?
No, p_islatin should
On Mon, Feb 12, 2007 at 11:19:14PM -0500, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
By my count there are only 170 uses of VARATT_SIZEP in the entire
backend (including contrib) so this is not an especially daunting
change. It would break existing user-written functions that
I know. My guess is the parser does not read the stop word file at
least with default configuration.
Parser should not read stopword file: its deal for dictionaries.
I'll come up with more detailed info, explaining why stopword file is
not read.
So if a character is not ASCII, it
Precise definition for latin in C locale please. Are you saying that
single byte encoding with range 0-7f? is latin? If so, it seems they
are exacty same as ASCII.
p_islatin returns true for ASCII alpha characters.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
I've been looking at backporting the stats fix committed to head and 8.2
into 8.1, but realised that it's just not going to work. 8.1 still uses
the dual stats processor stuff, which means that the simplification just
is not possible.
The most obvious result is that autovacuum is very likely to
Hannu Krosing wrote:
But actually that 1 free byte in the header is not currently just waste
of space. If you have any nulls in your tuple, there's going to be a
null bitmap in addition to the header. 1 byte is conveniently enough to
store the null bitmap for a table with max 8 columns,
Are
Robert Treat wrote:
On Saturday 10 February 2007 13:59, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
I'd say we probably want to keep the tgargs info for at least a version
or two after changing the implementation. Getting rid of using the args
info sounds like a good idea.
We
On Mon, Feb 12, 2007 at 08:08:31PM -0500, Robert Treat wrote:
In my memory I remember a site that displayed the code coverage of the
regression tests, but I can't find it now. Does anybody know?
Are you thinking of spikesource? According to thier numbers, we currently
cover about 40% of
Tom Lane [EMAIL PROTECTED] writes:
If we replaced that line with something like
SET_VARLENA_LEN(result, len + VARHDRSZ);
then we'd have a *whole* lot more control.
I think that part was already clear. The problem was in VARDATA.
I don't really see a way around it though. Places
Magnus Hagander wrote:
On Mon, Feb 12, 2007 at 11:19:14PM -0500, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
By my count there are only 170 uses of VARATT_SIZEP in the entire
backend (including contrib) so this is not an especially daunting
change. It would break existing
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
For example it'd be easy to implement the previously-discussed design
involving storing uncompressed length words in network byte order:
SET_VARLENA_LEN does htonl() and VARSIZE does ntohl() and nothing else in
the per-datatype functions
Heikki Linnakangas [EMAIL PROTECTED] writes:
Hannu Krosing wrote:
Are we actually doing that ? I.E are null bitmaps really allocated in 1
byte steps nowadays ?
Yes.
Not really; we still have to MAXALIGN at the end of the bitmap. The
point is that you can get 8 bits in there before paying
Heikki Linnakangas [EMAIL PROTECTED] writes:
Actually I think neither htonl nor bitshifting the entire 4-byte word is
going
to really work here. Both will require 4-byte alignment. Instead I think we
have to access the length byte by byte as a (char*) and do arithmetic. Since
it's the
Bruce Momjian [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
Could the new style macros be back-ported to previous releases in case
we do this?
Yes, Tom and I talked about this. It could appear in the next minor
release of all branches.
I don't really see the point of that. Third-party
Gregory Stark wrote:
a) To have two sets of macros, one of which, VARATT_DATA and
VARATT_SIZEP are for constructing new tuples and behaves exactly as
it does now. So you always construct a four-byte header datum. Then
in heap_form*tuple we check if you can use a shorter header and
convert.
Florian G. Pflug [EMAIL PROTECTED] writes:
As far as I understood the proposal, tgargs wouldn't go away, it would
just not be populated for RI triggers.
Yes, of course. I wasn't suggesting that we take away the ability to
pass arguments to triggers in general.
regards,
On Tue, Feb 13, 2007 at 09:44:03AM -0500, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
Could the new style macros be back-ported to previous releases in case
we do this?
Yes, Tom and I talked about this. It could appear in the next minor
release of
Gregory Stark [EMAIL PROTECTED] writes:
I don't really see a way around it though. Places that fill in VARDATA before
the size (formatting.c seems to be the worst case) will just have to be
changed and it'll be a fairly fragile point.
No, we're not going there: it'd break too much code now and
Heikki Linnakangas wrote:
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
For example it'd be easy to implement the previously-discussed design
involving storing uncompressed length words in network byte order:
SET_VARLENA_LEN does htonl() and VARSIZE does ntohl() and nothing else
The latest set of XML changes (I think latest, at least fairly recent)
broke the win32vc build with asserts enabled. The line:
Assert(fully_escaped || !escape_period);
From what I can tell, this is because the Assert() puts code (the do {}
loop) *before* the declaration of StringInfoData
Bruce Momjian wrote:
Heikki Linnakangas wrote:
We would still require all datums with a 4-byte header to be 4-byte
aligned, right? When reading, you would first check if it's a compressed
or uncompressed header. If compressed, read the 1 byte header, if
uncompressed, read the 4-byte header
On 2/13/07, Tom Lane [EMAIL PROTECTED] wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Hannu Krosing wrote:
Are we actually doing that ? I.E are null bitmaps really allocated in 1
byte steps nowadays ?
Yes.
Not really; we still have to MAXALIGN at the end of the bitmap. The
point is
On Tue, Feb 13, 2007 at 04:29:16PM +0100, Magnus Hagander wrote:
The latest set of XML changes (I think latest, at least fairly recent)
broke the win32vc build with asserts enabled. The line:
Assert(fully_escaped || !escape_period);
From what I can tell, this is because the Assert()
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Heikki Linnakangas wrote:
We would still require all datums with a 4-byte header to be 4-byte
aligned, right? When reading, you would first check if it's a compressed
or uncompressed header. If compressed, read the 1 byte header, if
Bruce Momjian [EMAIL PROTECTED] writes:
But if you are walking through attributes, how do you know to look at
the next byte or the next aligned byte? We have to force zeros in
there?
Yup: pad bytes must be zeroes (they are already) and a 1-byte-header
can't be a zero (easily done if its
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
I don't really see a way around it though. Places that fill in VARDATA
before
the size (formatting.c seems to be the worst case) will just have to be
changed and it'll be a fairly fragile point.
No, we're not
Magnus Hagander [EMAIL PROTECTED] writes:
From what I can tell, this is because the Assert() puts code (the do {}
loop) *before* the declaration of StringInfoData buf, which is not
permitted.
This will fail on every ANSI-C compiler, not just vc. Please fix.
regards,
On Tue, Feb 13, 2007 at 10:50:30AM -0500, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
From what I can tell, this is because the Assert() puts code (the do {}
loop) *before* the declaration of StringInfoData buf, which is not
permitted.
This will fail on every ANSI-C
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
(1) code written to existing practice will always generate 4-byte
headers. (Hence, VARDATA() acts the same as now.) That's the format
that generally gets passed around in memory.
So then we don't need to replace
Magnus Hagander wrote:
The latest set of XML changes (I think latest, at least fairly recent)
broke the win32vc build with asserts enabled. The line:
Assert(fully_escaped || !escape_period);
From what I can tell, this is because the Assert() puts code (the do {}
loop) *before* the
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
I don't really see a way around it though. Places that fill in VARDATA
before
the size (formatting.c seems to be the worst case) will just have to be
changed and it'll be a fairly
Tom Lane [EMAIL PROTECTED] writes:
So (nigh) every tuple will get deformed and reformed once before it goes to
disk? Currently the toast code doesn't even look at a tuple if it's small
enough, but in this case we would want it to fire even on very narrow rows.
I'd be inclined to put the
Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
So (nigh) every tuple will get deformed and reformed once before it goes
to
disk? Currently the toast code doesn't even look at a tuple if it's small
enough, but in this case we would want it to fire even on very narrow
rows.
On Mon, 2007-12-02 at 00:10 -0500, Tom Lane wrote:
Marc Munro [EMAIL PROTECTED] writes:
Consider a table C containing 2 child records C1 and C2, of parent P.
If transaction T1 updates C1 and C2, the locking order of the the
records will be C1, P, C2. Another transaction, T2, that attempts
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
From what I can tell, this is because the Assert() puts code (the
do {} loop) *before* the declaration of StringInfoData buf, which
is not permitted.
This will fail on every ANSI-C compiler, not just vc. Please fix.
We seem to
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I'd be inclined to put the intelligence into heap_form_tuple and thereby
avoid getting the TOAST code involved unless there are wide fields to
deal with.
And have heap_deform_tuple / heap_getattr palloc and memcpy the
On Tue, Feb 13, 2007 at 05:23:56PM +0100, Peter Eisentraut wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
From what I can tell, this is because the Assert() puts code (the
do {} loop) *before* the declaration of StringInfoData buf, which
is not permitted.
This
Based on this patch review, I am removing the patch from the patch
queue and requiring a resubmission.
---
Tom Lane wrote:
Dhanaraj M [EMAIL PROTECTED] writes:
Sorry for resubmitting this patch.
Just now I found a
Peter Eisentraut wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
From what I can tell, this is because the Assert() puts code (the
do {} loop) *before* the declaration of StringInfoData buf, which
is not permitted.
This will fail on every ANSI-C compiler, not just
Magnus Hagander [EMAIL PROTECTED] writes:
On Tue, Feb 13, 2007 at 05:23:56PM +0100, Peter Eisentraut wrote:
It turns out that gcc warns about it anyway. Does anyone have some sort
of clever recipe to catch warnings more easily than by carefully
reading the make output or manually grepping
Marc Munro [EMAIL PROTECTED] writes:
From an application developer's standpoint there are few options, none
of them ideal:
How about
4) Make all the FK constraints deferred, so that they are only checked
at end of transaction. Then the locking order of transactions that only
modify C is
On Tue, 2007-13-02 at 11:38 -0500, Tom Lane wrote:
Marc Munro [EMAIL PROTECTED] writes:
From an application developer's standpoint there are few options, none
of them ideal:
How about
4) Make all the FK constraints deferred, so that they are only checked
at end of transaction. Then
Bruce Momjian [EMAIL PROTECTED] writes:
But I'm surprised, I had the impression that you were reluctant to consider
memcpying all the data all the time.
Uh, if the macros can read 1 and 4-byte headers, why do we need to
allocate memory for them?
Because the macros can't read 1 and 4-byte
Added to TODO:
* Update our code to handle 64-bit timezone files to match the zic
source code, which now uses them
---
Tom Lane wrote:
Back when we converted src/timezone to use int64 for pg_time_t, we
wondered what
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
But I'm surprised, I had the impression that you were reluctant to consider
memcpying all the data all the time.
Uh, if the macros can read 1 and 4-byte headers, why do we need to
allocate memory for them?
Because the
Tom Lane [EMAIL PROTECTED] writes:
The point I'm trying to get across here is to do things one small step
at a time; if you insist on a big bang patch then it'll never get
done. You might want to go back and review the CVS history for some
other big changes like TOAST and the version-1
Hey all:
This is a randomly inserted distraction to tell you that I really like to
read about these ideas. No input from myself at this point. I'm happy with
the direction you are taking.
Thanks,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
The 8.1 build for cuckoo is currently hung, with the *postmaster* taking
all the CPU it can get. The build started almost 5 hours ago.
The postmaster is stuck in the following loop, according to
ktrace/kdump:
2023 postgres RET write 59/0x3b
2023 postgres CALL close(0x)
2023
Gregory Stark [EMAIL PROTECTED] writes:
You keep suggesting things that I've previously considered and rejected --
perhaps prematurely. Off the top of my head I recall the following four
options from our discussions. It looks like we're circling around option 4.
No, I think I'm arguing for
Tom Lane wrote:
We detect cases where the typmod guarantees either a fixed size or a maximum
size 256 bytes.
After last week I would veto this option anyway: it fails unless we
always know typmod exactly, and I'm here to tell you we don't.
If we can pull this off, it handles short values
[EMAIL PROTECTED] (Bruce Momjian) writes:
Log Message:
---
Add ORDER BY to vacummdb so databases are scaned in the same order as
pg_dumpall.
If we're gonna do that (which I have no objection to), shouldn't
clusterdb and reindexdb do the same?
regards, tom lane
Tom Lane wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Log Message:
---
Add ORDER BY to vacummdb so databases are scaned in the same order as
pg_dumpall.
If we're gonna do that (which I have no objection to), shouldn't
clusterdb and reindexdb do the same?
Done, thanks.
--
On Feb 12, 5:16 pm, [EMAIL PROTECTED] (Joshua D. Drake) wrote:
Peter Eisentraut wrote:
Jeroen T. Vermeulen wrote:
Is this a known problem? Is there any test procedure that builds the
base distribution before release?
Most of the core team is convinced that the postgresql-foo tarballs
This is from October 2006. Is there a TODO here?
---
Tom Lane wrote:
I did a couple more tests using x86 architectures. On a rather old
Pentium-4 machine running Fedora 5 (gcc 4.1.1, glibc-2.4-11):
$ gcc -O3 -std=c99
Jim C. Nasby [EMAIL PROTECTED] writes:
The postmaster is stuck in the following loop, according to
ktrace/kdump:
2023 postgres CALL select(0x8,0xbfffe194,0,0,0xbfffe16c)
2023 postgres RET select 1
2023 postgres CALL sigprocmask(0x3,0x2f0d38,0)
2023 postgres RET sigprocmask 0
Andrew Hammond wrote:
On Feb 12, 5:16 pm, [EMAIL PROTECTED] (Joshua D. Drake) wrote:
Peter Eisentraut wrote:
Jeroen T. Vermeulen wrote:
Is this a known problem? Is there any test procedure that builds the
base distribution before release?
Most of the core team is
Bruce Momjian [EMAIL PROTECTED] writes:
This is from October 2006. Is there a TODO here?
I think we had decided that the code that's in there is fine.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
You keep suggesting things that I've previously considered and rejected --
perhaps prematurely. Off the top of my head I recall the following four
options from our discussions. It looks like we're circling around
Gregory Stark wrote:
Alternatively, what does the trailing a in varlena signify? Would this be
varlenb?
attribute
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ
Andrew Hammond wrote:
The FreeBSD database/postgres* ports depend on them. Which is
probably why Marc insists on keeping them.
I hesitate to believe that seeing that they don't actually work, whereas
we have heard no complaints that the FreeBSD ports don't work.
--
Peter Eisentraut
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Any such site is already broken, because with the proposed design, code
is only exposed to short-header datums if it is also exposed to toasted
datums.
Well the toaster doesn't run until we were about to put the
Hello
please add to ToDo: Holdable cursor support in SPI
Regards
Pavel Stehule
_
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/
---(end of
The FreeBSD database/postgres* ports depend on them. Which is probably
why Marc insists on keeping them.
Well, I think that's a horrid dependency to have. Other packaging
systems (e.g. the RPM builds) seem quite able to split up a single
unified build into multiple packages - what can't
On Feb 13, 2007, at 12:15 PM, Tom Lane wrote:
Interesting. So accept() fails because it can't allocate an FD, which
means that the select condition isn't cleared, so we keep retrying
forever. I don't see what else we could do though. Having the
postmaster abort on what might well be a
Jim Nasby [EMAIL PROTECTED] writes:
On Feb 13, 2007, at 12:15 PM, Tom Lane wrote:
We could possibly sleep() a bit before retrying,
just to not suck 100% CPU, but that doesn't really *fix* anything ...
Well, not only that, but the machine is currently writing to the
postmaster log at the
Peter Eisentraut [EMAIL PROTECTED] writes:
Andrew Hammond wrote:
The FreeBSD database/postgres* ports depend on them. Which is
probably why Marc insists on keeping them.
I hesitate to believe that seeing that they don't actually work, whereas
we have heard no complaints that the FreeBSD
Peter Eisentraut wrote:
Andrew Hammond wrote:
The FreeBSD database/postgres* ports depend on them. Which is
probably why Marc insists on keeping them.
I hesitate to believe that seeing that they don't actually work, whereas
we have heard no complaints that the FreeBSD ports don't work.
Tom Lane skrev:
Is there any cross-check on the correctness of this list?
As have been said, there is a registration service that makes it harder
to steal nicks.
There is no guarantee that anyone who claim to be this or that really is
who he say he is. On the other hand, a lot of us have
On 2/13/07, Peter Eisentraut [EMAIL PROTECTED] wrote:
Andrew Hammond wrote:
The FreeBSD database/postgres* ports depend on them. Which is
probably why Marc insists on keeping them.
I hesitate to believe that seeing that they don't actually work, whereas
we have heard no complaints that the
Added to TODO:
* Improve failure message when DROP DATABASE is used on a database that
has prepared transactions
---
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
I think we should set things up so that prepared
Tom Lane wrote:
Jim Nasby [EMAIL PROTECTED] writes:
On Feb 13, 2007, at 12:15 PM, Tom Lane wrote:
We could possibly sleep() a bit before retrying,
just to not suck 100% CPU, but that doesn't really *fix* anything ...
Well, not only that, but the machine is currently writing to the
Alvaro Herrera wrote:
Tom Lane wrote:
Jim Nasby [EMAIL PROTECTED] writes:
On Feb 13, 2007, at 12:15 PM, Tom Lane wrote:
We could possibly sleep() a bit before retrying,
just to not suck 100% CPU, but that doesn't really *fix* anything ...
Well, not only that, but the
Andrew Dunstan [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
Tom Lane wrote:
delay. I just stuck a fixed 100msec delay into the accept-failed code
path.
Seems worth mentioning that bgwriter sleeps 1 sec in case of failure.
(And so does the autovac code I'm currently looking at).
There
Is there a TODO here?
---
Jim Nasby wrote:
On Oct 2, 2006, at 6:28 PM, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
However, the test right above that means that we'll fail if the user
tries something like
I tried to write a trigger using C++. This requires to include the
following header-files:
extern C {
#include postgres.h
#include executor/spi.h
#include commands/trigger.h
#include fmgr.h
}
Unfortunately some of the included headers define some structs and
functions where a few identifiers are
Regarding the advisory on possibly insecure security definer functions
that I just sent out (by overriding the search path you can make the
function do whatever you want with the privileges of the function
owner), the favored solution after some initial discussion in the core
team was to save
Jacob Rief wrote:
Is there any convention how to rename such identifiers? If I would
rename those identifiers (I simply would add an underscore to each of
them), would such a patch be accepted and adopted onto one of the
next releases?
Couldn't you do the required renamings as preprocessor
The Darwin dlopen() patch has already been applied. Where are we on the
Bonjour patch? Do we want code that works on Darwin 10.2 and 10.3?
---
Chris Campbell wrote:
On Oct 8, 2006, at 14:29, Tom Lane wrote:
Looks
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Regarding the advisory on possibly insecure security definer functions
that I just sent out (by overriding the search path you can make the
function do whatever you want with the privileges of the function
owner), the favored solution after some
What is the status of this feature addition?
---
Stephen Frost wrote:
-- Start of PGP signed section.
* Tom Lane ([EMAIL PROTECTED]) wrote:
(However, now that we support nulls in arrays, meseems a more consistent
Stephen Frost [EMAIL PROTECTED] writes:
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Regarding the advisory on possibly insecure security definer functions
that I just sent out (by overriding the search path you can make the
function do whatever you want with the privileges of the function
Jacob Rief [EMAIL PROTECTED] writes:
I tried to write a trigger using C++.
That is most likely not going to work anyway, because the backend
operating environment is C not C++. If you dumb it down enough
--- no exceptions, no RTTI, no use of C++ library --- then it might
work, but at that point
Stephen Frost [EMAIL PROTECTED] writes:
It'll break most of the functions that we have in our production
systems... They're not security definer functions but it's routine for
us to switch between different schemas to run a function on.
What about pushing all the in-function references down
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
It'll break most of the functions that we have in our production
systems... They're not security definer functions but it's routine for
us to switch between different schemas to run a function on.
What about
Stephan Szabo [EMAIL PROTECTED] writes:
On Mon, 12 Feb 2007, Tom Lane wrote:
It turns out this isn't sufficient: ri_Check_Pk_Match() wants to
generate PK = PK checks, and the PK = FK operator isn't the right one
for that.
Ugh, right, for modifications of the pk side with no action to make
Peter Eisentraut wrote:
Regarding the advisory on possibly insecure security definer functions
that I just sent out (by overriding the search path you can make the
function do whatever you want with the privileges of the function
owner), the favored solution after some initial discussion in
Simon Riggs wrote:
On Thu, 2006-10-26 at 18:45 -0400, Tom Lane wrote:
Chris Campbell [EMAIL PROTECTED] writes:
Is there additional logging information I can turn on to get more
details? I guess I need to see exactly what locks both processes
hold, and what queries they were running
Tom Lane wrote:
Albe Laurenz [EMAIL PROTECTED] writes:
[ Memo to hackers: why is it that log_min_error_statement = error
isn't the default? ]
To avoid spamming the logs with every failed SQL statement?
Certainly there are people who will turn it off, but that's why it's
configurable.
Bruce Momjian [EMAIL PROTECTED] writes:
Are we ready to set 'log_min_error_statement = error' by default for
8.3?
We already did that in 8.2.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Are we ready to set 'log_min_error_statement = error' by default for
8.3?
We already did that in 8.2.
Oh, interesting. Oops again.
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB
Added to TODO:
* Improve logging of prepared statements recovered during startup
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00092.php
---
Joachim Wieland wrote:
There have been
Added to TODO:
* Clean up casting in /contrib/isn
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00245.php
---
Tom Lane wrote:
It occurred to me to run the regression tests type_sanity and opr_sanity
over
Would someone update this patch with the optimization below. The patch
is at?
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
What's
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
! if (SOCK_ERRNO != ECONNRESET)
! SSL_shutdown(conn-ssl);
Ummm ... what is this supposed to fix exactly, and what are the odds
I
Just noticed a small cosmetic point in the logs when logging statement
performance data: if a statement accesses 0 blocks, the hit rate is
given as 0%.
I can see that that makes sense mathematically--insofar as 0/0 makes
mathematical sense at all--but wouldn't it be more helpful to represent
this
A few months ago at
http://archives.postgresql.org/pgsql-general/2006-11/msg01770.php the
notion of adding an anyelement2 pseudotype was discussed. The context
was a compatibility SQL function to support Oracle's DECODE function.
Assuming this new pseudotype has not been added yet, I'm ready to
Matt Miller [EMAIL PROTECTED] writes:
A few months ago at
http://archives.postgresql.org/pgsql-general/2006-11/msg01770.php the
notion of adding an anyelement2 pseudotype was discussed. The context
was a compatibility SQL function to support Oracle's DECODE function.
Assuming this new
98 matches
Mail list logo
