Happy New Year,
On Mon, 2010-01-04 at 11:50 +0900, Takahiro Itagaki wrote:
> Robert Haas 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:
> >
> > http://archives.po
2010/1/4 David E. Wheeler :
> 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 ('{"foo":{"bar":["
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
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 "Al
hello
2010/1/2 Tom Lane :
> Pavel Stehule 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 where multibyte
> characters can't
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 subscript
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 vi
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 (pgsql-
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 :
> hello
>
> 2010/1/2 Tom Lane :
>> Pavel Stehule writes:
>>> here is patch
>>
>> I looked at t
On Mon, Jan 4, 2010 at 2:44 AM, Tom Lane 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 the actual
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 - Sen
Tom Lane wrote:
Andrew Dunstan 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 is controlled by
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. I
Pavel Stehule 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 the server's,
it migh
Andrew Dunstan 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 complaints about
ot
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 be
Alvaro Herrera 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 rename the files underly
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 it
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 mailin
On Mon, Jan 4, 2010 at 3:04 AM, Simon Riggs 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 forwards when a new feat
I realize this is a very platform-specific thing, but should we
consider setting the value of /proc//oom_adj when running on
linux? See:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/proc.txt;h=220cc6376ef80e0c9bcfec162d45552e729cdf5a;hb=45d28b
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//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
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
> pg_class.reltuples)
>
Well that migh
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera wrote:
> Magnus Hagander wrote:
>> I realize this is a very platform-specific thing, but should we
>> consider setting the value of /proc//oom_adj when running on
>> linux? See:
>
> http://archives.postgresql.org/message-id/20080201223336.GC24780%40alvh
On Mon, 4 Jan 2010 16:57:28 +0100, Magnus Hagander
wrote:
> On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera
> wrote:
>> Magnus Hagander wrote:
>>> I realize this is a very platform-specific thing, but should we
>>> consider setting the value of /proc//oom_adj when running on
>>> linux? See:
>>
>>
ht
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera wrote:
Magnus Hagander wrote:
I realize this is a very platform-specific thing, but should we
consider setting the value of /proc//oom_adj when running on
linux? See:
http://archives.postgresql.org/message-id
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 wrote:
>
>
> Magnus Hagander wrote:
>>
>> On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera
>> wrote:
>>
>>>
>>> Magnus Hagander wrote:
>>>
I realize this is a very platform-specific thing, but should we
consider setting the value of /proc//o
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera wrote:
Magnus Hagander wrote:
I realize this is a very platform-specific thing, but should we
consider setting the value of /proc//oom_adj when running on
linux? See:
http://archives.postgresql.org/message-id/2
Mark Cave-Ayland 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 beforehand...)
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 17:07, Andrew Dunstan wrote:
Magnus Hagander wrote:
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera
wrote:
Magnus Hagander wrote:
I realize this is a very platform-specific thing, but should we
consider setting the value
On Mon, Jan 4, 2010 at 17:40, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>>
>> On Mon, Jan 4, 2010 at 17:07, Andrew Dunstan wrote:
>>
>>>
>>> Magnus Hagander wrote:
>>>
On Mon, Jan 4, 2010 at 16:45, Alvaro Herrera
wrote:
>
> Magnus Hagander wrote:
>>
Greg Smith 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 would be questione
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 p
On Mon, 2010-01-04 at 10:31 -0500, Robert Haas wrote:
> On Mon, Jan 4, 2010 at 3:04 AM, Simon Riggs 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
On Mon, Jan 4, 2010 at 17:55, Alvaro Herrera 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.
>
> It doesn't soun
Alvaro Herrera 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.
regards, tom
Magnus Hagander wrote:
> On Mon, Jan 4, 2010 at 17:55, Alvaro Herrera
> 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 often run as
Administr
2009/12/31 Hitoshi Harada :
> 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 typos in documen
On Fri, Jan 1, 2010 at 20:45, Magnus Hagander wrote:
> On Fri, Dec 4, 2009 at 11:42, Tsutomu Yamada 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 __nop?
>
> __noop: http://msdn
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
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 comman
Magnus Hagander writes:
> I realize this is a very platform-specific thing, but should we
> consider setting the value of /proc//oom_adj when running on
> linux? See:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/proc.txt;h=220cc6376ef80e0c9b
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
On Sun, Jan 3, 2010 at 11:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> 2010/1/3 KaiGai Kohei :
>>> if (number_of_attribute_origin(myrelid, oldattname) > 1)
>>> ereport(ERROR, ...);
>>>
>>> Am I missing something?
>
>> That sounds about right to me,
>
> It looks remarkably inefficient 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
Tom Lane 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
> implemented c
Robert Haas 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 at Naylor's bki re
On Mon, Jan 4, 2010 at 1:39 PM, Tom Lane wrote:
> Robert Haas 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
>> patc
Josh Berkus 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 set up, you
Robert Haas 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 rebasing mine afterwar
> 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 preserv
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 requir
On Mon, Jan 4, 2010 at 10:42 AM, Alvaro Herrera
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 another issue. Updat
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 n
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 .
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
On Mon, Jan 4, 2010 at 1:48 PM, Tom Lane wrote:
> Robert Haas 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
Bruce Momjian 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 not only a ma
Alvaro Herrera 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 "int64"?
On Mon, Jan 4, 2010 at 2:11 PM, 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 b
Tom Lane írta:
> Alvaro Herrera 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 d
On Mon, Jan 4, 2010 at 5:17 AM, Leonardo F 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 with a diffe
2010/1/4 Tom Lane :
> Pavel Stehule 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 differe
Tom Lane wrote:
> Bruce Momjian 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.
Robert Haas wrote:
> On Mon, Jan 4, 2010 at 2:11 PM, 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 t
On Mon, Jan 4, 2010 at 11:57 AM, Simon Riggs wrote:
> On Mon, 2010-01-04 at 10:31 -0500, Robert Haas wrote:
>> On Mon, Jan 4, 2010 at 3:04 AM, Simon Riggs 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
> 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 subscr
Josh Berkus 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.
regards, tom lan
>> 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 wrote:
> Robert Haas wrote:
>> On Mon, Jan 4, 2010 at 2:11 PM, 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 alrea
Robert Haas wrote:
> On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian wrote:
> >> > Alvaro Herrera wrote:
> >> >> > 2) ?Right now pg_migrator renames old tablespaces to .old, which fails
> >> >> > if the tablespaces are
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 tablespa
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 emergenc
Tom Lane wrote:
> Magnus Hagander 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 writes:
Le 28/12/2009 17:06, Tom Lane a écrit :
> I think we were stalled on the question of whether to use one array
>
On Mon, Jan 4, 2010 at 3:51 PM, Simon Riggs 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 with HS and
On Mon, Jan 4, 2010 at 3:33 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian wrote:
>> > Robert Haas wrote:
>> >> On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian wrote:
>> >> > Alvaro Herrera wrote:
>> >> >> > 2) ?Right now pg_migrator renames old tabl
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 s
On Mon, Jan 4, 2010 at 4:53 PM, Bruce Momjian 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 ne
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 probl
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 wrote:
> On Wed, Dec 30, 2009 at
On Mon, Jan 4, 2010 at 5:33 PM, Paul Ramsey 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 :)
That's good to know.
"David E. Wheeler" 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
regular expressions
On mån, 2010-01-04 at 17:10 -0600, Kevin Grittner wrote:
> "David E. Wheeler" 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
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
/home/postgres/pgsql/src/backend/bootstrap/boo
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
Peter Eisentraut 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 this plan.
> 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 sla
I wrote:
> Peter Eisentraut 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 #include a f
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
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 showstoppe
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
> u
On Mon, Jan 4, 2010 at 8:12 PM, Alvaro Herrera
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 what
>> license that
Robert Haas writes:
> On Mon, Jan 4, 2010 at 3:51 PM, Simon Riggs 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 follow up in >7 files, >12 pla
1 - 100 of 128 matches
Mail list logo
