Just a quick look. At first point. Your change introduces new page layout
version. Which is not acceptable from my point of view for 8.4 (it add another
complexity to inplace upgrade). And I guest that it maybe works fine on 64bits
x86 but it will fail on SPARC and other machine which requires
Hello Zdenek,
On Wed, Oct 8, 2008 at 10:59 PM, Zdenek Kotala [EMAIL PROTECTED] wrote:
Just a quick look. At first point. Your change introduces new page layout
version. Which is not acceptable from my point of view for 8.4 (it add
I would like to see this patch (or some variant) go in if
Ryan Bradetich napsal(a):
Hello Zdenek,
Hello Ryan,
On Wed, Oct 8, 2008 at 10:59 PM, Zdenek Kotala [EMAIL PROTECTED] wrote:
Just a quick look. At first point. Your change introduces new page layout
version. Which is not acceptable from my point of view for 8.4 (it add
I would like to see
On Wed, 2008-10-08 at 20:56 +0200, A. Kretschmer wrote:
am Wed, dem 08.10.2008, um 14:29:23 -0400 mailte Alvaro Herrera folgendes:
Hi,
Trigger functions are supposed to be able to be called only as triggers,
but apparently the check is not working in CVS HEAD:
alvherre=# create or
Thanks for your reviewing, Alex.
I applied your comments to my patch.
- auto_explain.patch : patch against HEAD
- auto_explain.tgz : contrib module
- autoexplain.sgml : documentation
Alex Hunsaker [EMAIL PROTECTED] wrote:
*custom_guc_flags-0828.patch
My only other concern is the changes
Matthew Wakeling wrote:
I could be wrong - but couldn't other bad things happen too? If you're
copying the files before the checkpoint has completed, couldn't the new
database end up with some of the recent changes going missing? Or is
that prevented by FlushDatabaseBuffers?
Josh Berkus [EMAIL PROTECTED] writes:
Would it be a worth it for us to implement a non-standard simple syntax
sugar on top of WITH RECURSIVE? Or, at least, something like
CONNECT_BY()?
The Oracle syntax only *looks* simple. When you start to study it
you realize that it's a horrid, messy
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] wrote:
So I gave up waiting for someone else to do the reloptions patch for
autovacuum and started work on it myself.
Is it needed to keep backward compatibility?
I'd like to suggest to keep pg_catalog.pg_autovacuum
Matthew Wakeling wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Another thought is to ignore ENOENT in copydir.
On Wed, 8 Oct 2008, Tom Lane wrote:
Yeah, I thought about that too, but it seems extremely dangerous ...
I agree. If a file randomly goes missing, that's not an error to
On Thu, 9 Oct 2008, Tom Lane wrote:
So I'm mystified
how Matthew could have seen the expected error and yet had the
destination tree (or at least large chunks of it) left behind.
Remember I was running 8.3.0, and you mentioned a few changes after that
version which would have made sure the
I discovered a bug (server crash) with the conversion of bytea types to
xml with base64 (and hex) encoding.
The patch against the postgres backend at the end of this email seems to
resolve the problem. I've never touched the postgres source before, and
the patch is simply a copy paste of
Heikki Linnakangas [EMAIL PROTECTED] writes:
Another thought is to ignore ENOENT in copydir.
On Wed, 8 Oct 2008, Tom Lane wrote:
Yeah, I thought about that too, but it seems extremely dangerous ...
I agree. If a file randomly goes missing, that's not an error to ignore,
even if you think
Is anyone working the CLUSTER: Add VERBOSE option... TODO item listed
on the PostgreSQL Wiki? If not, would it be wise for me to use
VERBOSE handling in an existing command (e.g. VACUUM)
as a guide while adding VERBOSE to CLUSTER?
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
No, you could have TEXTDOMAIN be defined as NULL by default, and let
modules redefine it as foo.
Doh, right.
So this'd seem to be the version ready to be applied (plus the needed
nls.mk files).
Perhaps repeated code like the
Hi,
On Sat, Sep 27, 2008 at 12:18:45PM +0900, KaiGai Kohei wrote:
As I repeated several times, SE-PostgreSQL applies the seuciry policy
of SELinux to achieve consistency in access controls.
I get this. The problem as I see it is that the SELinux security
policy is designed around a very
Matthew Wakeling [EMAIL PROTECTED] writes:
On Thu, 9 Oct 2008, Tom Lane wrote:
So I'm mystified
how Matthew could have seen the expected error and yet had the
destination tree (or at least large chunks of it) left behind.
Remember I was running 8.3.0, and you mentioned a few changes after
Hello Zdenek,
On Thu, Oct 9, 2008 at 12:38 AM, Zdenek Kotala [EMAIL PROTECTED] wrote:
Ryan Bradetich napsal(a):
On Wed, Oct 8, 2008 at 10:59 PM, Zdenek Kotala [EMAIL PROTECTED]
wrote:
I would like to see this patch (or some variant) go in if possible.
Since the inplace
upgrades a concern
Heikki Linnakangas [EMAIL PROTECTED] writes:
I committed a patch to do a full-blown checkpoint before the copy.
Annoying to do two checkpoints, but CREATE DATABASE is a pretty
heavy-weight operation anyway. I don't see any other solution at the
moment, at least not one that we could
On Wed, Oct 08, 2008 at 11:36:19AM +0900, KaiGai Kohei wrote:
Yes, unfortunatelly.
No one replied to my proposed design:
http://marc.info/?l=pgsql-hackersm=12470930544w=2
FWIW, I didn't know what to say about that proposal because I still
don't know what problems any of this is trying to
[EMAIL PROTECTED] writes:
I discovered a bug (server crash) with the conversion of bytea types to
xml with base64 (and hex) encoding.
Crash confirmed here...
The patch against the postgres backend at the end of this email seems to
resolve the problem. I've never touched the postgres
Ryan Bradetich [EMAIL PROTECTED] wrote:
Here is a proof-of-concept patch for reducing the alignment
requirement for heap tuples on 64-bit systems.
pg_depend 312 kB 296 kB
pg_description160 kB 152 kB
5 percent of gain seems reasonable for me.
Magnus Hagander [EMAIL PROTECTED] writes:
IIRC, Visual C++ compiles UTF8 source code just fine, so it should work.
The problem is that what's in our CVS is Latin-1. I'm not quite sure
why the OP's compiler is expecting it to be UTF-8, but it's pretty
obvious what's going to happen if it does
Peter Eisentraut wrote:
Alvaro Herrera wrote:
So this'd seem to be the version ready to be applied (plus the needed
nls.mk files).
Perhaps repeated code like the following should be refactored to a
common function offered by the backend?
True; committed that way, with a new function in
Kevin Grittner wrote:
Kevin Grittner [EMAIL PROTECTED] wrote:
Even more surprising is the behavior for interval(1) here:
[ some context with nonsurprising examples removed ...]
ccdev=# select '1 year 2 mons 3 days 04:05:06.64321'::interval(1);
interval
On Thu, Oct 09, 2008 at 11:50:17AM -0700, Ron Mayer wrote:
Kevin Grittner wrote:
Kevin Grittner [EMAIL PROTECTED] wrote:
Even more surprising is the behavior for interval(1) here:
[ some context with nonsurprising examples removed ...]
ccdev=# select '1 year 2 mons 3 days
Kenneth Marshall [EMAIL PROTECTED] writes:
There is a difference between the result 0.6 and 0.60 in rounding.
The first is accurate +-0.05 and the second is +-0.005. Certainly,
it does not seem unreasonable that machines can calulate intervals
to the nearest 100th of a second. What is not
Alvaro Herrera wrote:
True; committed that way, with a new function in miscinit.c.
So apparently I broke buildfarm member grebe:
/opt/prod/gcc-4.1.1/bin/gcc -maix64 -O2 -Wall -Wmissing-prototypes
-Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
-fno-strict-aliasing -fwrapv -g
On Thu, Oct 09, 2008 at 02:47:24PM -0500, Kevin Grittner wrote:
Kenneth Marshall [EMAIL PROTECTED] wrote:
Even more surprising is the behavior for interval(1) here:
[ some context with nonsurprising examples removed ...]
ccdev=# select '1 year 2 mons 3 days
Alvaro Herrera wrote:
Alvaro Herrera wrote:
True; committed that way, with a new function in miscinit.c.
So apparently I broke buildfarm member grebe:
Hmm, see bug #2608,
http://archives.postgresql.org/pgsql-bugs/2006-09/msg00029.php
I don't understand why gettext works and dgettext
current cvs head won't compile here, linking problem. I did try make
distclean, etc:
Undefined symbols:
_dgettext, referenced from:
_errmsg_internal in elog.o
_elog_finish in elog.o
_errcontext in elog.o
_errhint in elog.o
_errdetail_log in elog.o
Grzegorz Jaskiewicz wrote:
current cvs head won't compile here, linking problem. I did try make
distclean, etc:
Undefined symbols:
_dgettext, referenced from:
_errmsg_internal in elog.o
_elog_finish in elog.o
_errcontext in elog.o
_errhint in elog.o
On 2008-10-09, at 21:25, Alvaro Herrera wrote:
Grzegorz Jaskiewicz wrote:
current cvs head won't compile here, linking problem. I did try make
distclean, etc:
Undefined symbols:
_dgettext, referenced from:
_errmsg_internal in elog.o
_elog_finish in elog.o
_errcontext in
Hello ITAGAKI-san,
I apologize for not replying earlier, I needed to head out to work.
On Thu, Oct 9, 2008 at 5:01 AM, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Ryan Bradetich [EMAIL PROTECTED] wrote:
Here is a proof-of-concept patch for reducing the alignment
requirement for heap tuples on
Tom Lane wrote:
In the integer-timestamp world we know that the number is exact in
microseconds. We clearly ought to be prepared to display up to six
fractional digits, but suppressing trailing zeroes in that seems
appropriate.
Great.
We could try to do the same in the float case, but I'm a
Ron Mayer [EMAIL PROTECTED] writes:
Tom Lane wrote:
We could try to do the same in the float case, but I'm a bit worried
about finding ourselves showing 1234567.79 where it should be
1234567.8.
If I understand the code right fsec should mostly be values
between -1 and 1 anyway, because
Grzegorz Jaskiewicz wrote:
On 2008-10-09, at 21:25, Alvaro Herrera wrote:
Yeah, my bad. What's the platform?
mac os x
Hmm, does your link line include -lintl? If not, does it successfully
link if you add it?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
thickbook:backend gj$ gcc-4.2 -no-cpp-precomp -no-cpp-precomp -O2 -
Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-
statement -Wendif-labels -fno-strict-aliasing -fwrapv -L../../src/port
-Wl,-dead_strip_dylibs access/common/heaptuple.o access/common/
indextuple.o
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I wonder if we can get away with simply renaming the new toast table and
index after the data has been copied.
Yeah, that seems like the best answer.
Seems like this patch fixes it.
How far back should be backpatched? Given the
Tom Lane wrote:
Log Message:
---
Un-break non-NLS builds.
Doh! Sorry I didn't realize that :-)
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list
Hi,
bug report http://archives.postgresql.org/pgsql-bugs/2008-10/msg00037.php
seems like a reasonably request to me... and one that is simple to
fulfill, just create a PG_VERSION in the pg_tblspc dir at initdb.
if no one objects, here is a one linear patch for that
--
regards,
Jaime Casanova
Hah, got it. The reason the leak only manifests on 32-bit is that it
only manifests if int8 is a pass-by-reference datatype. The new API
for amgetbitmap causes a query-lifespan leak of one palloc(sizeof(int8))
per bitmap index scan. The distinguishing feature of your query seems
to be just that
Kenneth Marshall [EMAIL PROTECTED] wrote:
Even more surprising is the behavior for interval(1) here:
[ some context with nonsurprising examples removed ...]
ccdev=# select '1 year 2 mons 3 days 04:05:06.64321'::interval(1);
interval
--
1
Alvaro Herrera [EMAIL PROTECTED] writes:
Yeah, that seems like the best answer.
Seems like this patch fixes it.
Um, not for tables that don't have toast tables ...
How far back should be backpatched?
Not at all; it's not a bug fix.
regards, tom lane
--
Sent via
Jaime Casanova [EMAIL PROTECTED] writes:
bug report http://archives.postgresql.org/pgsql-bugs/2008-10/msg00037.php
seems like a reasonably request to me... and one that is simple to
fulfill, just create a PG_VERSION in the pg_tblspc dir at initdb.
I don't think it's a reasonable request. If
Hi,
I am attaching a new patch that deals with the issue of the locks on
temporary tables that have been accessed in transactions that have been
prepared but not committed.
I have added another list that keeps track of temp tables accessed by
transactions that are prepared but not committed.
On Thu, Oct 9, 2008 at 6:22 PM, Tom Lane [EMAIL PROTECTED] wrote:
Jaime Casanova [EMAIL PROTECTED] writes:
bug report http://archives.postgresql.org/pgsql-bugs/2008-10/msg00037.php
seems like a reasonably request to me... and one that is simple to
fulfill, just create a PG_VERSION in the
The attached patch allows uuid_in() to parse a wider variety of
variant input formats for the UUID data type, per the TODO named in
the subject line.
Original discussion here:
http://archives.postgresql.org/pgsql-hackers/2008-02/msg01214.php
Hi all,
I am new to postgresql. I am currently doing research to optimize the query
performance of RDBMS, specifically postgresql. Hence, I am currently reading
out the code to understand the implementation of various query evaluation
algorithm in postgresql.
Currently, I am investigating the
Andrew Sullivan wrote:
On Wed, Oct 08, 2008 at 11:36:19AM +0900, KaiGai Kohei wrote:
Yes, unfortunatelly.
No one replied to my proposed design:
http://marc.info/?l=pgsql-hackersm=12470930544w=2
FWIW, I didn't know what to say about that proposal because I still
don't know what problems
Andrew Sullivan wrote:
In my vision, Apache assigns its contents handler an individual
security context based on HTTP authentication, source IP address
and so on just before web application invoked.
Because web applications works with individual least privilege set,
its accesses on filesystem
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Tom Lane wrote:
We could try to do the same in the float case, but I'm a bit worried
about finding ourselves showing 1234567.79 ...
If I understand the code right [I didn't...]
The problem is ... seconds field that includes hours,
Robert Haas wrote:
While we could perhaps accept only those variant formats which we
specifically know someone to be using, it seems likely that people
will keep moving those pesky dashes around, and we'll likely end up
continuing to add more formats and arguing about which ones are widely
On 2008-10-09, at 22:57, Alvaro Herrera wrote:
Grzegorz Jaskiewicz wrote:
On 2008-10-09, at 21:25, Alvaro Herrera wrote:
Yeah, my bad. What's the platform?
mac os x
Hmm, does your link line include -lintl? If not, does it successfully
link if you add it?
ld: library not found for
53 matches
Mail list logo
