Happy New Year,
On Mon, 2010-01-04 at 11:50 +0900, Takahiro Itagaki wrote:
Robert Haas robertmh...@gmail.com wrote:
So, what is the roadmap for getting this done? It seems like to get
rid of VFI completely, we would need to implement something like what
Tom described here:
2010/1/4 David E. Wheeler da...@kineticode.com:
On Jan 3, 2010, at 4:18 PM, Hitoshi Harada wrote:
That sounds good and seems possible, as far as operator returns JSON
always. Perhaps every JSON fetching returns JSON even if the result
would be a number. You can cast it.
% SELECT
Hi all,
I would like to work on Allow substring/replace() to get/set bit values,
since it looks like a simple task.
The item is not marked as easy on the TODO though. Before proceding to a
discussion on how this functions should be implemented (I got from the messages
on the mailing list
The method I suggested would allow the
necessary information to be extracted during the initial search for
child tables, which we have to do anyway.
find_all_inheritors() returns a clean list which does not contain
duplicated OID of the inherited relation, so it seems to me we need
to
Re-reading the docs it looks like the only thing missing is get/set_bit for bit
string.
Substring is already implemented for bit string, and I don't really know if
replace is useful at all.
(sorry if the other mail came with a different sender name)
Leonardo
I would like to work on
hello
2010/1/2 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
here is patch
I looked at this patch a bit, and I think the real problem with it is
that it's not multibyte safe. You've copied backend code that is
allowed to assume it's in a safe encoding (ie, one
On sön, 2010-01-03 at 18:40 -0500, Andrew Dunstan wrote:
Incidentally, I guess we need to look at plpython and pltcl for
similar issues.
I confirm that the same issue exists in plpython.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Hello
I am looking for some quoting implementation in PostgreSQL. I cannot
to understand, why we can to use multibyte unsafe functions
quote_identifier or fmtId, and we have to use multibyte safe functions
quote_literal (and similar). Can somebody explain it?
Thank you
Pavel Stehule
--
Sent
Heikki Linnakangas wrote:
Here's is modified patch that adds a new backupStartPoint field to
pg_control for that + some other minor editorialization.
I've committed this now.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list
Hello
I talked with Hitoshi Harada, and fmtId function is safe (minimally
for Japanese case). This function working without any errors, so we
must not duplicate a code.
Pavel
2010/1/4 Pavel Stehule pavel.steh...@gmail.com:
hello
2010/1/2 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule
On Mon, Jan 4, 2010 at 2:44 AM, Tom Lane t...@postgresql.org wrote:
Log Message:
---
When estimating the selectivity of an inequality column constant or
column constant, and the comparison value is in the first or last
histogram bin or outside the histogram entirely, try to fetch
Tom Lane wrote:
Why do DOCS still go into doc/contrib? Shouldn't that become
doc/$MODULEDIR for consistency?
Hmmm it looks as if the code was correct but I missed the comment at the
top of the file. Sorry for the confusion - revised version attached.
ATB,
Mark.
--
Mark Cave-Ayland -
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
andrew=# select 'a' || invalid_utf_seq() || 'b';
ERROR: invalid byte sequence for encoding UTF8: 0xd0
HINT: This error can also happen if the byte sequence does not
match the encoding expected by the server, which
Greg Stark wrote:
I also wonder if we want to run these lookups on every single planner
invocation. If the table is being rarely updated analyze will never
fire and the stats value will never be updated. I don't think we want
the planner doing write operations to the stats either though. It
Pavel Stehule pavel.steh...@gmail.com writes:
I have one question. If I understand well, the function fmtId isn't
multibyte safe? So why is possible to use it in pg_dump?
pg_dump is only guaranteed to work correctly in the server encoding.
If you force it to use a client_encoding different from
Andrew Dunstan and...@dunslane.net writes:
How about we just change the hint so it also refers to the possibility
that the data comes from a PL? That would save lots of trouble.
Maybe just lose the hint altogether. It's not adding that much,
and I seem to recall that there have already been
Bruce Momjian wrote:
pg_migrator has become more popular recently, so it seems time to look
at some enhancements that would improve pg_migrator. None of these are
required, but rather changes that would be nice to have:
1) Right now pg_migrator preserves relfilenodes for TOAST files
Alvaro Herrera alvhe...@commandprompt.com writes:
Getting rid of the need for placeholders is a good idea. +1 on getting
TOAST tables created with the correct relfilenode from the start. I
don't know that preserving any other relfilenode is useful; however if
it means you no longer have to
I've merged the replication branch with PostgreSQL CVS HEAD now,
including the patch for end-of-backup WAL records I committed earlier
today. See 'replication' branch in my git repository.
There's also a couple of other small changes: I believe the SSL stuff
isn't really necessary, so I removed
Andrew Dunstan wrote:
I don't think the parens on trailing conditions issue is anything
other than just a matter of taste.
Agreed
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing
On Mon, Jan 4, 2010 at 3:04 AM, Simon Riggs si...@2ndquadrant.com wrote:
This is a more cautious approach. Completely removing VFI in this
release is a big risk that we need not take; we have little to gain from
doing so and putting it back again will be harder. I am always keen to
push
I realize this is a very platform-specific thing, but should we
consider setting the value of /proc/pid/oom_adj when running on
linux? See:
Robert Haas escribió:
Hmm, I see this needs to be rebased over Tom's latest changes, but the
conflict I got was in syscache.h, rather than syscache.c. Not sure if
that's what you were going for or if there's another issue. Updated
patch attached.
FWIW I think the reloptions code in this
Magnus Hagander wrote:
I realize this is a very platform-specific thing, but should we
consider setting the value of /proc/pid/oom_adj when running on
linux? See:
http://archives.postgresql.org/message-id/20080201223336.GC24780%40alvh.no-ip.org
--
Alvaro Herrera
On Mon, Jan 4, 2010 at 2:50 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Maybe autovac could run such a cheap ANALYZE frequently on tables with
large number of inserts (but not large enough to trigger a regular
ANALYZE) ... say a fixed number of tuples (not depending on
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera alvhe...@commandprompt.com wrote:
Magnus Hagander wrote:
I realize this is a very platform-specific thing, but should we
consider setting the value of /proc/pid/oom_adj when running on
linux? See:
On Mon, 4 Jan 2010 16:57:28 +0100, Magnus Hagander mag...@hagander.net
wrote:
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera
alvhe...@commandprompt.com
wrote:
Magnus Hagander wrote:
I realize this is a very platform-specific thing, but should we
consider setting the value of /proc/pid/oom_adj
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera alvhe...@commandprompt.com wrote:
Magnus Hagander wrote:
I realize this is a very platform-specific thing, but should we
consider setting the value of /proc/pid/oom_adj when running on
linux? See:
On Wed, 2009-12-30 at 17:16 +0100, Tom Lane wrote:
I think the cleanest solution to this would be to make ANALYZE
cheaper, perhaps by finding some way for it to work incrementally.
What if when inserting/deleting a tuple, some random sample of them
would be passed into an auto-analyze buffer ?
On Mon, Jan 4, 2010 at 17:07, Andrew Dunstan and...@dunslane.net wrote:
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera alvhe...@commandprompt.com
wrote:
Magnus Hagander wrote:
I realize this is a very platform-specific thing, but should we
consider setting the
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera alvhe...@commandprompt.com wrote:
Magnus Hagander wrote:
I realize this is a very platform-specific thing, but should we
consider setting the value of /proc/pid/oom_adj when running on
linux? See:
Mark Cave-Ayland mark.cave-ayl...@siriusit.co.uk writes:
Hmmm it looks as if the code was correct but I missed the comment at the
top of the file. Sorry for the confusion - revised version attached.
Applied with minor fixups (mostly improving the documentation, which
was not in very good shape
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 17:07, Andrew Dunstan and...@dunslane.net wrote:
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera alvhe...@commandprompt.com
wrote:
Magnus Hagander wrote:
I realize this is a very platform-specific
On Mon, Jan 4, 2010 at 17:40, Andrew Dunstan and...@dunslane.net wrote:
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 17:07, Andrew Dunstan and...@dunslane.net wrote:
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera
alvhe...@commandprompt.com
wrote:
Magnus
Greg Smith g...@2ndquadrant.com writes:
In http://archives.postgresql.org/pgsql-hackers/2008-02/msg00049.php Tom
points out that while you could make this adjustment in the init scripts
for PostgreSQL, actually doing so is quite questionable as a packaging
decision.
I just wondered if it
Magnus Hagander wrote:
Right. Which is why I like the idea of disabling the OOM killer for
the *postmaster*, but not the regular backends. Gives it a chance to
recover. It's not nice, but it's better than nothing.
It doesn't sound like the init script can reenable the killer for the
child
On Mon, 2010-01-04 at 10:31 -0500, Robert Haas wrote:
On Mon, Jan 4, 2010 at 3:04 AM, Simon Riggs si...@2ndquadrant.com wrote:
This is a more cautious approach. Completely removing VFI in this
release is a big risk that we need not take; we have little to gain from
doing so and putting it
On Mon, Jan 4, 2010 at 17:55, Alvaro Herrera alvhe...@commandprompt.com wrote:
Magnus Hagander wrote:
Right. Which is why I like the idea of disabling the OOM killer for
the *postmaster*, but not the regular backends. Gives it a chance to
recover. It's not nice, but it's better than nothing.
Alvaro Herrera alvhe...@commandprompt.com writes:
Is there a way to disable memory overcommit for particular processes?
I would think not --- the very essence of overcommit is that you're
promising more total memory than the system has got, and that's
inherently a global proposition.
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 17:55, Alvaro Herrera alvhe...@commandprompt.com
wrote:
BTW, is it possible for pg_ctl to disable OOM-killer? I guess not,
since it's not run by root ...
No, it has to run as root.
We could at least make it work on Windows, since it is
2009/12/31 Hitoshi Harada umi.tan...@gmail.com:
Attached is the fix pointed out in the previous CommitFest plus RANGE
offset support.
Improved version attached. In this revision I fixed type mismatch case
like ORDER BY int4_data RANGE BETWEEN int8_data PRECEDING
Update of comments and fix
On Fri, Jan 1, 2010 at 20:45, Magnus Hagander mag...@hagander.net wrote:
On Fri, Dec 4, 2009 at 11:42, Tsutomu Yamada tsut...@sraoss.co.jp wrote:
2) use appropriate macro and datatypes for Windows API.
enables more than 32bits shared memory.
Are you sure this one should use __noop, and not
Alvaro Herrera wrote:
3) There is no easy way to analyze all databases. vacuumdb --analyze
does analyze _and_ vacuum, which for an 8.4 to 8.5 migration does an
unnecessary vacuum. Right now I recommend ANALYZE in every database,
but it would be nice if there were a single command which
Robert Haas wrote:
3) ?There is no easy way to analyze all databases. ?vacuumdb --analyze
does analyze _and_ vacuum, which for an 8.4 to 8.5 migration does an
unnecessary vacuum. ?Right now I recommend ANALYZE in every database,
but it would be nice if there were a single command which did
Magnus Hagander mag...@hagander.net writes:
I realize this is a very platform-specific thing, but should we
consider setting the value of /proc/pid/oom_adj when running on
linux? See:
Robert Haas wrote:
4) ?I have implemented the ability to run pg_migrator --check on a live
old server. ?However, pg_migrator uses information from controldata to
check things, and it also needs xid information that is only available
via pg_resetxlog -n(no update) to perform the migration.
On Sun, Jan 3, 2010 at 11:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
2010/1/3 KaiGai Kohei kai...@ak.jp.nec.com:
if (number_of_attribute_origin(myrelid, oldattname) 1)
ereport(ERROR, ...);
Am I missing something?
That sounds about right to
Bruce Momjian escribió:
I considered that but realize that pg_migrator has to read
pg_controldata in both the old and new servers, meaning it would need
access to both C structures, and considering they both have the same
structure names, that would require some odd C tricks. Add to that you
Tom Lane t...@sss.pgh.pa.us wrote:
This suggests that PG's shared memory ought not be counted in the
postmaster's OOM score, which would mean that the problem
shouldn't be quite as bad as we've believed. I wonder if that is
a recent change? Or maybe it's supposed to be that way and is not
Robert Haas robertmh...@gmail.com writes:
Hmm, I see this needs to be rebased over Tom's latest changes, but the
conflict I got was in syscache.h, rather than syscache.c. Not sure if
that's what you were going for or if there's another issue. Updated
patch attached.
I'm planning to go look
On Mon, Jan 4, 2010 at 1:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Hmm, I see this needs to be rebased over Tom's latest changes, but the
conflict I got was in syscache.h, rather than syscache.c. Not sure if
that's what you were going for or if
Josh Berkus j...@agliodbs.com writes:
I've applied a patch to HEAD that does the above. Can you test it to
see how well it fixes your problem?
Sure. It'll take us a while to set up a test environment; the database
is 1TB in size so converting it to 8.5 isn't quick.
Great. When you have it
Robert Haas robertmh...@gmail.com writes:
My only objection to that is that if we're going to add attoptions
also, I'd like to get this committed first before I start working on
that, and we're running short on time. If you can commit his patch in
the next day or two, then I am fine with
I've applied a patch to HEAD that does the above. Can you test it to
see how well it fixes your problem?
Sure. It'll take us a while to set up a test environment; the database
is 1TB in size so converting it to 8.5 isn't quick.
Will report back.
--Josh
--
Sent via pgsql-hackers mailing
Alvaro Herrera wrote:
Bruce Momjian wrote:
pg_migrator has become more popular recently, so it seems time to look
at some enhancements that would improve pg_migrator. None of these are
required, but rather changes that would be nice to have:
1) Right now pg_migrator preserves
Alvaro Herrera wrote:
Bruce Momjian escribi?:
I considered that but realize that pg_migrator has to read
pg_controldata in both the old and new servers, meaning it would need
access to both C structures, and considering they both have the same
structure names, that would require some
On Mon, Jan 4, 2010 at 10:42 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
Hmm, I see this needs to be rebased over Tom's latest changes, but the
conflict I got was in syscache.h, rather than syscache.c. Not sure if
that's what you were going for or if there's
Boszormenyi Zoltan wrote:
I happened to notice this by chance:
+ #if (LONG_BIT == 64)
+ #define SQLINT8 ECPGt_long
+ #define SQLSERIAL8 ECPGt_long
+ #else
+ #define SQLINT8 ECPGt_long_long
+ #define SQLSERIAL8 ECPGt_long_long
+ #endif
I'm not
Alvaro Herrera wrote:
2) Right now pg_migrator renames old tablespaces to .old, which fails
if the tablespaces are on mount points. I have already received a
report of such a failure.
I thought it was impossible to use bare mountpoints as tablespaces due
to ownership problems ... Is
Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
I happened to notice this by chance:
+ #if (LONG_BIT == 64)
+ #defineSQLINT8 ECPGt_long
+ #defineSQLSERIAL8 ECPGt_long
+ #else
+ #defineSQLINT8 ECPGt_long_long
+ #defineSQLSERIAL8 ECPGt_long_long
On Mon, Jan 4, 2010 at 1:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
My only objection to that is that if we're going to add attoptions
also, I'd like to get this committed first before I start working on
that, and we're running short on time. If you
Bruce Momjian br...@momjian.us writes:
I was just really asking if disallowing pg_resetxlog -n on a live server
is planned behavior or an oversight. I can see the logic that it should
be disallowed but I am just looking for confirmation from someone and I
can then drop the issue.
Well, it's
Alvaro Herrera alvhe...@commandprompt.com writes:
I'm not sure how portable is the LONG_BIT business.
I think checking SIZEOF_LONG would be preferred, since that's what
we use elsewhere. Although actually I wonder why this code exists
at all --- wouldn't it be easier to make these depend on
On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian br...@momjian.us wrote:
Alvaro Herrera wrote:
2) Right now pg_migrator renames old tablespaces to .old, which fails
if the tablespaces are on mount points. I have already received a
report of such a failure.
I thought it was impossible to
Tom Lane írta:
Alvaro Herrera alvhe...@commandprompt.com writes:
I'm not sure how portable is the LONG_BIT business.
I think checking SIZEOF_LONG would be preferred, since that's what
we use elsewhere. Although actually I wonder why this code exists
at all --- wouldn't it be
On Mon, Jan 4, 2010 at 5:17 AM, Leonardo F m_li...@yahoo.it wrote:
Re-reading the docs it looks like the only thing missing is get/set_bit for
bit string.
Substring is already implemented for bit string, and I don't really know if
replace is useful at all.
(sorry if the other mail came
2010/1/4 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I have one question. If I understand well, the function fmtId isn't
multibyte safe? So why is possible to use it in pg_dump?
pg_dump is only guaranteed to work correctly in the server encoding.
If you force
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I was just really asking if disallowing pg_resetxlog -n on a live server
is planned behavior or an oversight. I can see the logic that it should
be disallowed but I am just looking for confirmation from someone and I
can then drop
Robert Haas wrote:
On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian br...@momjian.us wrote:
Alvaro Herrera wrote:
2) ?Right now pg_migrator renames old tablespaces to .old, which fails
if the tablespaces are on mount points. ?I have already received a
report of such a failure.
I
On Mon, Jan 4, 2010 at 11:57 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-01-04 at 10:31 -0500, Robert Haas wrote:
On Mon, Jan 4, 2010 at 3:04 AM, Simon Riggs si...@2ndquadrant.com wrote:
This is a more cautious approach. Completely removing VFI in this
release is a big risk
Great. When you have it set up, you might want to play with enabling
the mergejoinscansel change as well, and see if that is a net plus or
minus for you.
How would I *disable* it?
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Josh Berkus j...@agliodbs.com writes:
Great. When you have it set up, you might want to play with enabling
the mergejoinscansel change as well, and see if that is a net plus or
minus for you.
How would I *disable* it?
It's #ifdef NOT_USED in CVS at the moment.
What I should have said, in addition: VFI will be kept as a non-default
option, in case it is required. We will document that use of VFI will
not work correctly with HS and that its use is deprecated and should be
in emergencies only in any case. I will enjoy removing VFI when that
On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian br...@momjian.us wrote:
Alvaro Herrera wrote:
2) ?Right now pg_migrator renames old tablespaces to .old, which fails
if the tablespaces are on mount
Robert Haas wrote:
On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian br...@momjian.us wrote:
Alvaro Herrera wrote:
2) ?Right now pg_migrator renames old tablespaces to .old, which fails
if the
Bruce Momjian wrote:
Alvaro Herrera wrote:
2) Right now pg_migrator renames old tablespaces to .old, which fails
if the tablespaces are on mount points. I have already received a
report of such a failure.
I thought it was impossible to use bare mountpoints as tablespaces due
to
On Mon, 2010-01-04 at 12:05 -0800, Josh Berkus wrote:
What I should have said, in addition: VFI will be kept as a non-default
option, in case it is required. We will document that use of VFI will
not work correctly with HS and that its use is deprecated and should be
in emergencies only in
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
...oom_adj...
One interesting thing I read there is:
Swapped out tasks are killed first. Half of each child's memory size is
added to the parent's score if they do not share the same memory.
Le 29/12/2009 14:12, Guillaume Lelarge a écrit :
Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
Le 28/12/2009 22:59, Tom Lane a écrit :
Guillaume Lelarge guilla...@lelarge.info writes:
Le 28/12/2009 17:06, Tom Lane a écrit :
I think we were stalled on the question of whether to use one
On Mon, Jan 4, 2010 at 3:51 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-01-04 at 12:05 -0800, Josh Berkus wrote:
What I should have said, in addition: VFI will be kept as a non-default
option, in case it is required. We will document that use of VFI will
not work correctly
On Mon, Jan 4, 2010 at 3:33 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian br...@momjian.us wrote:
Alvaro Herrera wrote:
2) ?Right now
Robert Haas wrote:
What doesn't work if we just don't rename the tablespace at all? ?And
can't we put some smarts into the backend to handle that thing?
Well, when you restore the old dump's schema into the new server, the
tablespace directory path will be the same, so we had better
On Mon, Jan 4, 2010 at 4:53 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
What doesn't work if we just don't rename the tablespace at all? ?And
can't we put some smarts into the backend to handle that thing?
Well, when you restore the old dump's schema into the new
Robert Haas wrote:
But can't we just call a special function first before running the
CREATE TABLESPACE, like:
pg_tablespace_dont_really_create_this_tablespace_because_we_are_in_pg_migrator()?
Sorta like what you did to preserve ENUM OIDs, etc.?
Well, the problem is that we are
I'm sure whatever conclusion -hackers comes to in the end will be the
best for pgsql, and I'll be supportive. But until then, let me note
from the PostGIS point-of-view: sure would be great to get this in for
8.5 :)
P.
On Thu, Dec 31, 2009 at 4:26 AM, Greg Stark gsst...@mit.edu wrote:
On Wed,
On Mon, Jan 4, 2010 at 5:33 PM, Paul Ramsey pram...@cleverelephant.ca wrote:
I'm sure whatever conclusion -hackers comes to in the end will be the
best for pgsql, and I'll be supportive. But until then, let me note
from the PostGIS point-of-view: sure would be great to get this in for
8.5 :)
David E. Wheeler da...@kineticode.com wrote:
I think the consensus was, failing support for concurrent sessions
in psql, to use a Perl script to control multiple psql sessions
and perhaps use Test::More to do the testing.
Are there any examples of that? While I can hack my way through
On mån, 2010-01-04 at 17:10 -0600, Kevin Grittner wrote:
David E. Wheeler da...@kineticode.com wrote:
I think the consensus was, failing support for concurrent sessions
in psql, to use a Perl script to control multiple psql sessions
and perhaps use Test::More to do the testing.
Are
Andrew Dunstan wrote:
Yes. I believe the test is highlighting an existing problem: that plperl
function in non-PG_UTF8 databases can't use regular expressions that
require unicode character meta-data.
Either the (GetDatabaseEncoding() == PG_UTF8) test in plperl_safe_init()
should be removed,
On Jan 4, 2010, at 3:29 PM, Peter Eisentraut wrote:
If you're not deep into Perl, perhaps ignore the Test::More comment for
the moment and just use DBI to connect to several database sessions,
execute your queries and check if the results are what you want. Once
you have gotten somewhere
It seems like VPATH building is broken at the moment, at least if you
are working from a maintainer-clean source tree.
make -C bootstrap all
make[3]: Entering directory `/home/postgres/build/src/backend/bootstrap'
/usr/local/bin/bison -o bootparse.c
On mån, 2010-01-04 at 18:49 -0500, Tom Lane wrote:
It seems like VPATH building is broken at the moment, at least if you
are working from a maintainer-clean source tree.
make -C bootstrap all
make[3]: Entering directory `/home/postgres/build/src/backend/bootstrap'
/usr/local/bin/bison -o
Peter Eisentraut pete...@gmx.net writes:
On mån, 2010-01-04 at 18:49 -0500, Tom Lane wrote:
I thought the current plan was that derived files should be generated in
the build tree (as indeed it seems to be doing) ... but there are
apparently parts of the Makefiles that are not in sync with
I think I'd vote for throwing an ERROR. By the time you see the
WARNING it may be too late. Since this is only for emergencies, the
user can shut off recovery_connections first if they really need it.
I'm with Robert on this one. If running VFI will cause unrecoverable
failure on the
I wrote:
Peter Eisentraut pete...@gmx.net writes:
This should in principle work. My guess is an old make version being
confused.
Well, I am testing with relatively old make and gcc too, but what it
looks like to me is that we need to add a -I. switch in places where we
might need to
On Mon, 2010-01-04 at 16:41 -0500, Robert Haas wrote:
I propose we have a WARNING if VFI being run when recovery_connections =
on, since I probably know what I'm doing if I go out of my way to use
new syntax after presumably having read the manual.
I think I'd vote for throwing an ERROR.
Tom,
It seems I introduced a couple errors in src/tools/msvc/clean.bat in
the bki patch. I'm attaching a cumulative fix. I can resend the
complete updated patch, if you like...
Sorry! :-)
John
I'm planning to go look at Naylor's bki refactoring patch now. Assuming
there isn't any showstopper
Robert Haas escribió:
I did a quick read-through of this, and one question that immediately
occurred to me is that rbtree.c says that it is adopted from
http://algolist.manual.ru/ds/rbtree.php. But I'm not sure what
license that code is under, so I'm not sure whether it's OK for us to
use
On Mon, Jan 4, 2010 at 8:12 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
I did a quick read-through of this, and one question that immediately
occurred to me is that rbtree.c says that it is adopted from
http://algolist.manual.ru/ds/rbtree.php. But I'm not sure
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 4, 2010 at 3:51 PM, Simon Riggs si...@2ndquadrant.com wrote:
Changes required to remove it are at least these places
* most of vacuum.c
* visibility checks
* heap tuple flags and xvac
* nontransactional validation
* minor points and
1 - 100 of 128 matches
Mail list logo
