Bruce Momjian írta:
> Bruce Momjian wrote:
>
>> I am seeing a compile failure in current CVS because my operating
>> system, BSD/OS, does not have inttypes.h:
>>
>> ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
>> -fno-strict-aliasing -O1 -Wall -Wmissing-prototypes
>>
Fujii Masao wrote:
>> I've done that in my git branch.
>
> Could you push that git branch to a public place?
Ahh, sorry, forgot that again. It's there now, at
git://git.postgresql.org/git/users/heikki/postgres.git, branch
'replication'.
--
Heikki Linnakangas
EnterpriseDB http://www.enterp
On Jan 6, 2010, at 1:52 AM, decibel wrote:
> On Dec 30, 2009, at 9:50 PM, Bruce Momjian 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 e
Boszormenyi Zoltan írta:
> Bruce Momjian írta:
>
>> Bruce Momjian wrote:
>>
>>
>>> I am seeing a compile failure in current CVS because my operating
>>> system, BSD/OS, does not have inttypes.h:
>>>
>>> ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
>>> -fno-strict-ali
Fujii Masao wrote:
> On Tue, Jan 5, 2010 at 11:29 PM, Alvaro Herrera
> wrote:
>> This was probably discussed to death earlier, but: why was it decided to
>> not simply use a different port for listening for walsender
>> connections?
>
> I believe that using a different port would make the setup
>
On Tue, Jan 05, 2010 at 06:54:36PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Thu, Dec 31, 2009 at 09:47:24AM -0800, David E. Wheeler wrote:
> >> Definite benefit, there. How does it handle the difference between
> >> IMMUTABLE | STABLE | VOLATILE, as well as STRICT functions?
>
> > It doe
Dave Page wrote:
> On Tuesday, January 5, 2010, Peter Eisentraut wrote:
>> On tis, 2010-01-05 at 16:48 +, Dave Page wrote:
>>> On Tue, Jan 5, 2010 at 3:15 PM, Tom Lane wrote:
I would have thought Microsoft would have a better solution than this
for managing 64-bit libraries. Or am
> See:
>
> http://msdn.microsoft.com/en-us/library/aa376307%28VS.85%29.aspx
>
> http://msdn.microsoft.com/en-us/library/aa375155%28VS.85%29.aspx
Oh, and:
http://blogs.msdn.com/jonwis/archive/2005/12/28/507863.aspx
--
Craig Ringer
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On Wed, 2010-01-06 at 14:41 +0900, Takahiro Itagaki wrote:
> Simon Riggs wrote:
>
> > > 1. Commit your patch, as-is (you/me)
> >
> > I assume this is OK with you now?
>
> I just applied the patch with a few additional comments.
> Also, I adjusted some messages for vacuumdb to be look-alike
> fo
On Tue, Jan 05, 2010 at 09:49:27PM -0500, Bruce Momjian wrote:
> I am seeing a compile failure in current CVS because my operating
> system, BSD/OS, does not have inttypes.h:
Sorry, missed this. I did remove it in another file, but didn't notice it's
here too. Should be fixed now that I committed
On Wed, Jan 06, 2010 at 09:42:06AM +0100, Boszormenyi Zoltan wrote:
> Attached. Passes "make check" here on 32-bit and
> 64-bit builds under Fedora 9/x86-64.
Applied.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Me
On ons, 2010-01-06 at 14:41 +0900, Takahiro Itagaki wrote:
> Simon Riggs wrote:
>
> > > 1. Commit your patch, as-is (you/me)
> >
> > I assume this is OK with you now?
>
> I just applied the patch with a few additional comments.
Please clean up the compiler warnings:
cluster.c: In function 'cl
On Tue, Jan 05, 2010 at 07:06:35PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > The only question I have at the moment, before I try implementing this,
> > is the the need for freeing the plan. When would that be needed?
>
> There's probably no strong need to do it at all,
That's good.
> unle
Hi,
I can access to system catalog using syscache functions. How can i change
the values of cache (e.g. change an attribute in pg_authid)? Are syscache
functions readonly?
Thanks - B. L.
Stefan Kaltenbrunner wrote:
Hi all!
There will be planned downtime on tribble.postgresql.org Jan 6(tomorrow)
from 10:00-12:30 GMT(estimated) affecting the following services:
cvs.postgresql.org
wwwmaster.postgresql.org
www.pgadmin.org
doxygen.postgresql.org
Downtime is necessary to implement s
black light wrote:
> Hi,
> I can access to system catalog using syscache functions. How can i change
> the values of cache (e.g. change an attribute in pg_authid)? Are syscache
> functions readonly?
I'd suggest that you look at the existing places that modify catalogs
for inspiration. E.g AlterRol
Fujii Masao escribió:
> On Sat, Dec 26, 2009 at 10:55 AM, Fujii Masao wrote:
> > On Fri, Dec 25, 2009 at 9:56 PM, Andrew Dunstan wrote:
> >> I don't see the use case for it - .pgpass is for single users, not a whole
> >> cluster. And it does support wildcards, which takes care of the 'all' case.
On Wed, Jan 6, 2010 at 15:02, Alvaro Herrera wrote:
> Fujii Masao escribió:
>> On Sat, Dec 26, 2009 at 10:55 AM, Fujii Masao wrote:
>> > On Fri, Dec 25, 2009 at 9:56 PM, Andrew Dunstan
>> > wrote:
>> >> I don't see the use case for it - .pgpass is for single users, not a whole
>> >> cluster. An
Stefan Kaltenbrunner wrote:
Stefan Kaltenbrunner wrote:
Hi all!
There will be planned downtime on tribble.postgresql.org Jan 6(tomorrow)
from 10:00-12:30 GMT(estimated) affecting the following services:
cvs.postgresql.org
wwwmaster.postgresql.org
www.pgadmin.org
doxygen.postgresql.org
Downtim
The fastgetattr() attempts to make provision for the case where isnull
is a NULL pointer, but it doesn't seem to work. I tried it and got:
relcache.c:494: error: invalid use of void expression
relcache.c:494: error: invalid use of void expression
relcache.c:494: warning: left-hand operand of comm
Tim Bunce writes:
> For my own benefit, being a PostgreSQL novice, could you expand a little?
> For example, given two stored procedures, A and V, where V is marked
> VOLATILE and both are plperl. How would having A call V directly, within
> the plperl interpreter, cause problems?
That case is fi
Tim Bunce writes:
> Let me ask the question another way... is there any reason to drop plans
> other than limiting memory usage?
No, that's about it. The only reason to care is if you'd otherwise have
a code path that would repetitively leak plans.
regards, tom lane
--
Dne 4.01.10 19:28, Alvaro Herrera napsal(a):
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
On Wed, Jan 6, 2010 at 9:42 AM, Stefan Kaltenbrunner
wrote:
> all services should be up now and again sorry for the delays...
No, thank you for maintaining this for the rest of us!
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
decibel writes:
> On Dec 29, 2009, at 6:29 PM, Tom Lane wrote:
>> * when a tabstat message comes in, increment changes_since_analyze by
>> the sum of t_tuples_inserted + t_tuples_updated + t_tuples_deleted;
>>
>> * when an analyze report message comes in, reset changes_since_analyze
>> to zero.
On Wed, Jan 6, 2010 at 9:46 AM, Tom Lane wrote:
> Tim Bunce writes:
>> For my own benefit, being a PostgreSQL novice, could you expand a little?
>> For example, given two stored procedures, A and V, where V is marked
>> VOLATILE and both are plperl. How would having A call V directly, within
>> t
Robert Haas writes:
> I think what we should do is either (1) implement a poor man's caching
> that doesn't try to cope with any of these issues, and document that
> you get what you pay for or (2) reject this idea in its entirety.
> Trying to reimplement all of our normal function call semantics
Robert Haas escribió:
> On Wed, Jan 6, 2010 at 9:42 AM, Stefan Kaltenbrunner
> wrote:
> > all services should be up now and again sorry for the delays...
>
> No, thank you for maintaining this for the rest of us!
Seconded, many thanks, pizza and free beer!
--
Alvaro Herrera
Tom Lane wrote:
Tim Bunce writes:
For my own benefit, being a PostgreSQL novice, could you expand a little?
For example, given two stored procedures, A and V, where V is marked
VOLATILE and both are plperl. How would having A call V directly, within
the plperl interpreter, cause problems?
Andrew Dunstan writes:
> I don't understand that phrase "call SPI with the right arguments for
> the type of function you're currently in". What calls that we make from
> plperl code would have different arguments depending on the volatility
> of the function?
eg, in plperl_spi_exec,
On Tue, Jan 5, 2010 at 10:17 AM, Robert Haas wrote:
> 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
Tom Lane wrote:
Andrew Dunstan writes:
I don't understand that phrase "call SPI with the right arguments for
the type of function you're currently in". What calls that we make from
plperl code would have different arguments depending on the volatility
of the function?
eg, in plper
Andrew Dunstan writes:
> Tom Lane wrote:
>> spi_rv = SPI_execute(query, current_call_data->prodesc->fn_readonly,
>> ^^^
> OK, but won't that automatically supply the value from the function
> called from postgres, which will be the
Zdenek Kotala wrote:
> Dne 4.01.10 19:28, Alvaro Herrera napsal(a):
> > 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 bot
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
spi_rv = SPI_execute(query, current_call_data->prodesc->fn_readonly,
^^^
OK, but won't that automatically supply the value from the function
called from
Andrew Dunstan writes:
> Next question: what do we do if a direct-called function calls
> return_next()? That at least must surely take effect in the caller's
> context - the callee won't have anywhere to stash the the results at all.
Whatever do you mean by "take effect in the caller's context
Fujii Masao writes:
> The attached patch supports new keyword 'replication' on .pgpass file.
> This keyword is used to specify the password for the standby server to
> connect to the primary server.
This strikes me as a completely bad idea. We need get no farther than
the point that it assumes n
Takahiro Itagaki writes:
> Domains were created successfully, but I cannot use type modifiers for them.
> =# CREATE TABLE tbl (v varchar2(10));
> ERROR: type modifier is not allowed for type "varchar2"
> What reason do we have not to inherit typmodin/typmodout from the base type?
Becaus
Craig Ringer writes:
> Fujii Masao wrote:
>> On Tue, Jan 5, 2010 at 11:29 PM, Alvaro Herrera
>> wrote:
>>> This was probably discussed to death earlier, but: why was it decided to
>>> not simply use a different port for listening for walsender
>>> connections?
>>
>> I believe that using a differ
On Tue, Jan 05, 2010 at 08:50:25PM -0700, u235sentinel wrote:
> Robert Haas wrote:
> >
> >Getting full?
> >
> >...Robert
> >
> Ok. Bad analogy. We have the tables setup to write data according
> to the month it was loaded. We have a December table, a January
> table and so on. Basically followi
On Wed, Jan 6, 2010 at 12:06 PM, David Fetter wrote:
> On Tue, Jan 05, 2010 at 08:50:25PM -0700, u235sentinel wrote:
>> Robert Haas wrote:
>> >
>> >Getting full?
>> >
>> >...Robert
>> >
>> Ok. Bad analogy. We have the tables setup to write data according
>> to the month it was loaded. We have a
On Wed, Jan 6, 2010 at 16:34, Alvaro Herrera wrote:
> Robert Haas escribió:
>> On Wed, Jan 6, 2010 at 9:42 AM, Stefan Kaltenbrunner
>> wrote:
>> > all services should be up now and again sorry for the delays...
>>
>> No, thank you for maintaining this for the rest of us!
>
> Seconded, many thanks
Magnus Hagander escribió:
> On Wed, Jan 6, 2010 at 16:34, Alvaro Herrera
> wrote:
> > Robert Haas escribió:
> >> On Wed, Jan 6, 2010 at 9:42 AM, Stefan Kaltenbrunner
> >> wrote:
> >> > all services should be up now and again sorry for the delays...
> >>
> >> No, thank you for maintaining this fo
Looks like somebody broke the snapshot generation script again:
Note: meta manvol : see http://docbook.sf.net/el/manvolnum
dblink_build_sql_delete
Note: Writing man1/dblink_build_sql_delete.1
Note: meta manvol : no refentry/refmeta/manvolnum
dblink_build_sql_update
Note: meta manvol : see htt
Tom Lane wrote:
> Andrew Dunstan writes:
> > Next question: what do we do if a direct-called function calls
> > return_next()? That at least must surely take effect in the caller's
> > context - the callee won't have anywhere to stash the the results at all.
>
> Whatever do you mean by "take ef
On Wed, Jan 6, 2010 at 9:43 AM, Robert Haas wrote:
> The fastgetattr() attempts to make provision for the case where isnull
> is a NULL pointer, but it doesn't seem to work. I tried it and got:
>
> relcache.c:494: error: invalid use of void expression
> relcache.c:494: error: invalid use of void
> /* Domains never accept typmods, so no typmodin/typmodout needed */
> but can we relax the restriction? This feature would be useful for migration
> from other DBMSes that have non-standard data types.
For migration, wouldn't it be adequate simply to ignore the typemod? Or
to allow it as p
Bruce Momjian 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. $PGDATA also has that issue, but that
> renaming has to be done by the user before pg_migrator is run, and
On Wed, Jan 6, 2010 at 12:42 PM, Alvaro Herrera
wrote:
>>
>> Oh, so you'r ecoming to FOSDEM?
>
> February this year? No way :-( I'm probably anchored at home until
> August or so ...
>
had your baby born now?
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desar
Robert Haas writes:
> The fastgetattr() attempts to make provision for the case where isnull
> is a NULL pointer, but it doesn't seem to work. I tried it and got:
> relcache.c:494: error: invalid use of void expression
> relcache.c:494: error: invalid use of void expression
> relcache.c:494: war
Jaime Casanova escribió:
> On Wed, Jan 6, 2010 at 12:42 PM, Alvaro Herrera
> wrote:
> >>
> >> Oh, so you'r ecoming to FOSDEM?
> >
> > February this year? No way :-( I'm probably anchored at home until
> > August or so ...
>
> had your baby born now?
Still waiting ...
--
Alvaro Herrera
Robert Haas escribió:
> The fastgetattr() attempts to make provision for the case where isnull
> is a NULL pointer, but it doesn't seem to work. I tried it and got:
>
> relcache.c:494: error: invalid use of void expression
> relcache.c:494: error: invalid use of void expression
> relcache.c:494:
Robert Haas writes:
> Spoke with Bruce on IM and we think the best option is to just remove
> the NULL tests. Since it's been this way for 11 years, presumably
> nobody is trying to use it with a NULL fourth argument.
> Proposed patch attached.
There are a number of is-null checks in related co
On Wed, Jan 6, 2010 at 1:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> The fastgetattr() attempts to make provision for the case where isnull
>> is a NULL pointer, but it doesn't seem to work. I tried it and got:
>
>> relcache.c:494: error: invalid use of void expression
>> relcache.c:494: err
> > To sum up:
> >
> > 1) a new function, "get_bit", that calls substring
> > 2) a new function, "overlay", that replaces bits (starting at a certain
> position)
> > 3) a new function, "set_bit", that calls overlay
>
> That seems reasonable to me. Not sure what others think.
Is anybody interes
On Wed, Jan 06, 2010 at 11:14:38AM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > Tom Lane wrote:
> >> spi_rv = SPI_execute(query, current_call_data->prodesc->fn_readonly,
> >> ^^^
>
> > OK, but won't that automatically supply t
In response to Alvaro Herrera :
> Jaime Casanova escribió:
> >
> > had your baby born now?
>
> Still waiting ...
You are pregnant?
;-)
Hey, and yes: i wish you and your wife all the best and many fun with
the baby.
Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/71
On Wed, Jan 6, 2010 at 1:16 PM, Tom Lane wrote:
> Robert Haas writes:
>> Spoke with Bruce on IM and we think the best option is to just remove
>> the NULL tests. Since it's been this way for 11 years, presumably
>> nobody is trying to use it with a NULL fourth argument.
>
>> Proposed patch attac
Takahiro Itagaki wrote:
> This feature would be useful for migration
> from other DBMSes that have non-standard data types.
Domains can indeed be useful to allow migration -- if they are used
as intended. If you identify all of the unique data domains on your
source platform and define the co
Robert Haas writes:
> Well, that comment is a bit misleading too, since a pointer with a
> NULL value might work but a literal NULL certainly doesn't.
I think "(bool *) NULL" would work. What your compiler is complaining
about is trying to dereference a "void *" expression.
In practice, the peo
On Wed, Jan 6, 2010 at 1:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> Well, that comment is a bit misleading too, since a pointer with a
>> NULL value might work but a literal NULL certainly doesn't.
>
> I think "(bool *) NULL" would work. What your compiler is complaining
> about is trying t
Stefan Kaltenbrunner writes:
> Looks like somebody broke the snapshot generation script again:
[ scratches head... ] "make dist" works for me. Can you get a
trace indicating what command was used to call genbki.pl?
regards, tom lane
--
Sent via pgsql-hackers mailing l
Garick Hamlin writes:
> If you want 'a perl compile time hook', those are called attributes.
> http://search.cpan.org/~dapm/perl-5.10.1/lib/attributes.pm
Hm ... first question that comes to mind is how far back does that work?
The comments on that page about this or that part of it being still
ex
Tom Lane wrote:
Stefan Kaltenbrunner writes:
Looks like somebody broke the snapshot generation script again:
[ scratches head... ] "make dist" works for me. Can you get a
trace indicating what command was used to call genbki.pl?
heh that's a nice one the snapshot generation script uses "
Tom Lane wrote:
Garick Hamlin writes:
If you want 'a perl compile time hook', those are called attributes.
http://search.cpan.org/~dapm/perl-5.10.1/lib/attributes.pm
Hm ... first question that comes to mind is how far back does that work?
The comments on that page about this or that
On Wed, Jan 6, 2010 at 1:16 PM, Tom Lane wrote:
> Robert Haas writes:
>> Spoke with Bruce on IM and we think the best option is to just remove
>> the NULL tests. Since it's been this way for 11 years, presumably
>> nobody is trying to use it with a NULL fourth argument.
>
>> Proposed patch attac
On Wed, Jan 6, 2010 at 1:21 PM, Leonardo F wrote:
>> > To sum up:
>> >
>> > 1) a new function, "get_bit", that calls substring
>> > 2) a new function, "overlay", that replaces bits (starting at a certain
>> position)
>> > 3) a new function, "set_bit", that calls overlay
>>
>> That seems reasonable
Here's a fix. Sorry, I didn't realize it was ever called without a
version number.
On Wed, Jan 6, 2010 at 11:18 AM, Stefan Kaltenbrunner
> heh that's a nice one the snapshot generation script uses "
> gmake -s VERSION=snapshot dist" and that leads to getting "
> --set-version=snapshot" passed to g
Stefan Kaltenbrunner writes:
> Tom Lane wrote:
>> [ scratches head... ] "make dist" works for me. Can you get a
>> trace indicating what command was used to call genbki.pl?
> heh that's a nice one the snapshot generation script uses "
> gmake -s VERSION=snapshot dist" and that leads to getting
On 1/6/10 9:13 AM, Robert Haas wrote:
> On Wed, Jan 6, 2010 at 12:06 PM, David Fetter wrote:
>> On Tue, Jan 05, 2010 at 08:50:25PM -0700, u235sentinel wrote:
>>> Robert Haas wrote:
Getting full?
...Robert
>>> Ok. Bad analogy. We have the tables setup to write data according
>
On Jan 6, 2010, at 11:27 AM, Andrew Dunstan wrote:
> That's a case of out of date docco more than anything else, AFAIK. It's been
> there at least since 5.6.2 (which is the earliest source I have on hand).
Which likely also means 5.6.1 and quite possibly 5.6.0. I don't recommend
anything earlie
Over the past few months, I've been attempting to keep tracks of which
postings on pgsql-bugs have not gotten a response and to respond to
those where I have a clue what the issue might be. However, there are
a few that I don't really have an idea about which look like they
might be real bugs... o
John Naylor writes:
> Here's a fix. Sorry, I didn't realize it was ever called without a
> version number.
It's not supposed to be. If it fails to put the correct version number
into the .bki file, initdb will spit up. This is really a makefile bug,
not genbki's fault.
"David E. Wheeler" writes:
> Which likely also means 5.6.1 and quite possibly 5.6.0. I don't recommend
> anything earlier than 5.6.2, though, frankly, and 5.8.9 is a better choice.
> 5.10.1 better still. Is there a documented required minimum version for
> PL/Perl?
One of the things on my to-d
Tom Lane wrote:
John Naylor writes:
Here's a fix. Sorry, I didn't realize it was ever called without a
version number.
It's not supposed to be. If it fails to put the correct version number
into the .bki file, initdb will spit up. This is really a makefile bug,
not genbki's fault.
really?
Robert Haas writes:
> The first of these in particular is a fairly detailed report of what
> looks might be a fairly serious problem.
> pg_listener entries deleted under heavy NOTIFY load only on Windows
> http://archives.postgresql.org/pgsql-bugs/2009-12/msg00274.php
Yeah, that needs to be look
Stefan Kaltenbrunner writes:
> really? there are provisions withing genbki.pl that are supposed to
> provide a proper error message(and would have likely helped to find the
> issue in that case as well):
> die "Version not specified or wrong format.\n" if !defined $major_version;
> however due t
Robert Haas escribió:
> Over the past few months, I've been attempting to keep tracks of which
> postings on pgsql-bugs have not gotten a response and to respond to
> those where I have a clue what the issue might be.
So you installed the bugzilla module on yourself? Neat. Keep at it!
> Should
On Wed, Jan 6, 2010 at 4:00 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> Over the past few months, I've been attempting to keep tracks of which
>> postings on pgsql-bugs have not gotten a response and to respond to
>> those where I have a clue what the issue might be.
>
> So you installed
Robert Haas wrote:
On Wed, Jan 6, 2010 at 4:00 PM, Alvaro Herrera
wrote:
Robert Haas escribió:
Over the past few months, I've been attempting to keep tracks of which
postings on pgsql-bugs have not gotten a response and to respond to
those where I have a clue what the issue might be.
So you i
Is there a reason tablespace.c::set_short_version() uses PG_VERSION, and
not the simpler PG_MAJORVERSION? initdb.c::get_short_version() does the
same thing.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a har
Robert Haas wrote:
> And use git so you can keep merging up to CVS HEAD easily.
Regarding this, I was thinking that it would make sense to use a
repository on git.postgresql.org to coordinate my work with any
other people interested in the project. I would clone from there
for the repository
On Wed, Jan 6, 2010 at 4:10 PM, Stefan Kaltenbrunner
wrote:
> Robert Haas wrote:
>>
>> On Wed, Jan 6, 2010 at 4:00 PM, Alvaro Herrera
>> wrote:
>>>
>>> Robert Haas escribió:
Over the past few months, I've been attempting to keep tracks of which
postings on pgsql-bugs have not gotte
On Wed, Jan 6, 2010 at 4:29 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> And use git so you can keep merging up to CVS HEAD easily.
>
> Regarding this, I was thinking that it would make sense to use a
> repository on git.postgresql.org to coordinate my work with any
> other people interest
Robert Haas escribió:
> On Wed, Jan 6, 2010 at 4:10 PM, Stefan Kaltenbrunner
> wrote:
> > hmm maybe I should resurrect the bugzilla testbed again :)
>
> If we're going to use a bug-tracker, Bugzilla wouldn't be my first
> choice, I don't think. Honestly what I'd like better than a
> full-fledge
On Fri, Jan 1, 2010 at 20:55, Magnus Hagander wrote:
> On Fri, Jan 1, 2010 at 20:41, Tom Lane wrote:
>> Magnus Hagander writes:
>>> The win64 port has showed that we have two sockets declared
>>> incorrectly. They are supposed to be declared as SOCKET on win32, but
>>> they are declared as int.
On Fri, Jan 1, 2010 at 10:45 PM, Simon Riggs wrote:
> CancelRequest's behaviour currently equates to SIGINT, so
> processCancelRequest() can only use SIGINT if SIGINT's behaviour remains
> same.
>
> I would recommend we make SIGINT do cancel-anything, and handle
> everything else via SIGUSR1, incl
Magnus Hagander writes:
> Is there a good trick to find out if you've touched every place you
> need to, because I'm very unsure I have. I don't even get a warning in
> more than those two places, but there ought to be some way to trick
> the system to tell me?
Can't think of one, but you could t
On Wed, Jan 6, 2010 at 4:37 PM, Joachim Wieland wrote:
> On Fri, Jan 1, 2010 at 10:45 PM, Simon Riggs wrote:
>> CancelRequest's behaviour currently equates to SIGINT, so
>> processCancelRequest() can only use SIGINT if SIGINT's behaviour remains
>> same.
>>
>> I would recommend we make SIGINT do
On Jan 6, 2010, at 12:20 PM, Tom Lane wrote:
> One of the things on my to-do list for today is to make configure reject
> Perl versions less than $TBD. I thought we had agreed a week or so back
> that 5.8 was the lowest safe version because of utf8 and other
> considerations.
+1, and 5.8.3 at a
"Kevin Grittner" writes:
> I've read through some git tutorials, but
> there's a lot to digest and I'm not entirely sure this is a good way
> to proceed.
I found that the following video is really helpful at grasping the
concepts of git, that it exposes pretty directly even though it's meant
to p
"David E. Wheeler" wrote:
> Last I heard, Andrew was willing to require Test::More for
> testing, so that a Perl script could handle multiple psql
> connections (perhaps forked) and output test results based on
> them. But he wasn't as interested in requiring DBI and DBD::Pg,
> neither of which
Robert Haas wrote:
On Tue, Jan 5, 2010 at 6:09 PM, Arie Bikker wrote:
Hi all,
Well I had to burn some midnight oil trying to figure out why a construct
like
SELECT xpath('name()','');
doesn't give the expected result. Kept getting an empty array:
xpath
-
{}
instead
Robert Haas wrote:
> I think you should have users/kgrittner/postgres.git rather than
> serializable.git. serializable sounds more like the branch name.
Hmmm On a multi-year project it seemed more than remotely
possible that responsibility for the project could shift, either to
an extern
Robert Haas writes:
> If we're going to use a bug-tracker, Bugzilla wouldn't be my first
> choice, I don't think. Honestly what I'd like better than a
> full-fledged trackers is just a webapp that lists all the unreplied-to
> emails in the pgsql-bugs archives.
For something like a flexible archi
On ons, 2010-01-06 at 15:52 -0600, Kevin Grittner wrote:
> "David E. Wheeler" wrote:
>
> > Last I heard, Andrew was willing to require Test::More for
> > testing, so that a Perl script could handle multiple psql
> > connections (perhaps forked) and output test results based on
> > them. But he w
Bruce Momjian writes:
> Is there a reason tablespace.c::set_short_version() uses PG_VERSION, and
> not the simpler PG_MAJORVERSION? initdb.c::get_short_version() does the
> same thing.
Probably that code predates the addition of the separate PG_MAJORVERSION
#define. +1 for simplifying. The cha
On Jan 6, 2010, at 1:52 PM, Kevin Grittner wrote:
>> Last I heard, Andrew was willing to require Test::More for
>> testing, so that a Perl script could handle multiple psql
>> connections (perhaps forked) and output test results based on
>> them. But he wasn't as interested in requiring DBI and DB
On Jan 6, 2010, at 2:08 PM, Peter Eisentraut wrote:
> Then I don't see much of a point in using Perl. You might as well fire
> up a few psqls from a shell script
If you're more comfortable with shell, then yes. Although then it won't run on
Windows, will it?
Best,
David
--
Sent via pgsql-hac
rh...@postgresql.org (Robert Haas) writes:
> Support ALTER TABLESPACE name SET/RESET ( tablespace_options ).
With this patch, a CLOBBER_CACHE_ALWAYS build starts falling apart all
over the place :-(. Looks like you blew the memory management somehow;
it appears to be using a previously pfree'd po
1 - 100 of 158 matches
Mail list logo
