Hi,
Greg Stark wrote:
> aaah... I think I see where we've gone off track in previous
> discussions...you think postgres keeps row level locks in a shared
> memory data structure. It doesn't it stores all row level locks *in*
> the tuple itself. It only stores the lock in memory briefly while
> a
Robert Haas wrote:
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 gotten a respo
On Jan 6, 2010, at 5:46 PM, Tom Lane wrote:
> I went with 5.8 as the cutoff, for a couple of reasons: we're not in
> the business of telling people they ought to be up-to-date, but only of
> rejecting versions that demonstrably fail badly; and I found out that
> older versions of awk are not suffi
On ons, 2010-01-06 at 16:44 -0800, Josh Berkus wrote:
> > Personally, I was more hoping we could consider fixing some of them...
>
> Agreed. I really don't think a bug tracker helps us. We need two things:
>
> (1) to respond to bug submissions immediately and fix them, and
> (2) if we can't fix
On Wed, Jan 6, 2010 at 11:11 PM, Magnus Hagander wrote:
> I haven't read up on the rest of the patch, but where do we put the
> rest of the information about the replication master? Like which IP
> and port to connect to? Perhaps it could/should go there?
Such information are supplied in the para
On ons, 2010-01-06 at 20:49 -0500, Robert Haas wrote:
> Another idea would be to make a set of Perl libpq bindings that is
> simpler than DBD::Pg and don't go through DBI. If we put those in the
> main source tree (perhaps as a contrib module) they would be available
> wherever we need them.
htt
Peter Eisentraut writes:
> On mån, 2010-01-04 at 13:07 -0500, Bruce Momjian wrote:
>> Yea, I am not excited about having vacuumdb do only analyze, but it
>> seems the most minimal solution. I spelled it --only-analyze and just
>> posted the reason and patch.
> I can't find the patch and the rea
On ons, 2010-01-06 at 14:10 -0800, David E. Wheeler wrote:
> 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
Robert Haas wrote:
It just seems crazy to me to try to test anything without proper
language bindings. Opening a psql session and parsing the results
seems extraordinarily painful.
I've written a Python based program that spawns a captive psql and talks
to it--twice for different people--that
On mån, 2010-01-04 at 13:07 -0500, Bruce Momjian wrote:
> Yea, I am not excited about having vacuumdb do only analyze, but it
> seems the most minimal solution. I spelled it --only-analyze and just
> posted the reason and patch.
I can't find the patch and the reason, but note that we already have
Robert Haas writes:
> On Wed, Jan 6, 2010 at 10:13 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> What tools do we have for identifying memory leaks?
>>
>> User complaints :-(
> YGTBFKM.
Not really. Given the memory context architecture, leaks are simply not
a big deal in 99% of the system.
Dave Page wrote:
On Tue, Jan 5, 2010 at 3:15 PM, Tom Lane wrote:
Dave Page writes:
After chatting with Magnus, we feel that a good solution would be to
rename libpq on Win64 to libpq64.dll to distinguish it from the 32 bit
equivalent.
Isn't that going to break applications? Where by "break"
On Wed, Jan 6, 2010 at 10:00 PM, Kevin Grittner
wrote:
>> For basic regression tests, yeah, we'd probably like to keep that
>> Perl-free.
>
> OK. Is parallel psql the only reasonable option?
It seems so, assuming you're willing to concede that it is a
reasonable option in the first place.
>> Fo
On Wed, Jan 6, 2010 at 10:13 PM, Tom Lane wrote:
> Robert Haas writes:
>> What tools do we have for identifying memory leaks?
>
> User complaints :-(
YGTBFKM.
It seems like we should have a tool that dumps out every memory
context in the system, with the number of allocations and frees and
numb
Robert Haas writes:
> What tools do we have for identifying memory leaks?
User complaints :-(
> I think I'll just copy Alvaro's existing pattern in relcache.c, which
> just uses palloc0 and memcpy.
OK.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-ha
Kevin Grittner escribió:
> Well, if that's the consensus, I have to choose between trying to
> implement multi-session psql and using testing which can't carry over
> to long-term regular use. Are we anywhere close to an agreement on
> what the multi-session psql implementation would look like?
Robert Haas wrote:
> I'm not exactly sure what Kevin's goal is here.
I think it would be insane to try to do something like serializable
isolation mode without having regression tests. I would want more
tests than could reasonably go into the 'make check' suite to support
development, but it
On Wed, Jan 6, 2010 at 6:11 PM, Tom Lane wrote:
> 3. Invoking tablespace_reloptions while switched into
> CacheMemoryContext. This isn't a crasher, but it strikes me as a bad
> idea because if reloptions.c happens to leak anything, that'll represent
> a permanent (session-lifespan) memory leak.
On Wed, Jan 6, 2010 at 9:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> It just seems crazy to me to try to test anything without proper
>> language bindings. Opening a psql session and parsing the results
>> seems extraordinarily painful. I wonder if it would make sense write
>> a small wrapp
On Thu, Jan 7, 2010 at 12:57 AM, Chuck McDevitt wrote:
> Windows always uses UNICODE to store file and directory names.
So what does that mean when the filesystem is a shared filesystem or
one mounted in Windows but originally written out by another OS?
I think the answer is that it interprets t
Tom Lane wrote:
> We have not yet fully accepted the notion that you must have Perl
> to build (and, in fact, I am right now trying to verify that you
> don't). I don't think that requiring Perl to test is going to fly.
Well, if that's the consensus, I have to choose between trying to
impleme
Andrew Dunstan wrote:
> Robert Haas wrote:
>> Doing this without DBI is going to be ten times harder than doing
>> it with DBI. Are we really sure that's not a viable option?
> In the buildfarm? Yes, I think so. The philosophy of the buildfarm
> is that it should do what you would do yourself
Robert Haas writes:
> It just seems crazy to me to try to test anything without proper
> language bindings. Opening a psql session and parsing the results
> seems extraordinarily painful. I wonder if it would make sense write
> a small wrapper program that uses libpq and dumps out the results in
On Wed, Jan 6, 2010 at 8:40 PM, Andrew Dunstan wrote:
>> Doing this without DBI is going to be ten times harder than doing it
>> with DBI. Are we really sure that's not a viable option?
>
> In the buildfarm? Yes, I think so. The philosophy of the buildfarm is that
> it should do what you would do
Tim Bunce writes:
> On Wed, Jan 06, 2010 at 01:45:45PM -0800, David E. Wheeler wrote:
>> 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
Robert Haas wrote:
On Wed, Jan 6, 2010 at 4:52 PM, 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
Chuck McDevitt wrote:
> Just an FYI regarding this bug:
> http://archives.postgresql.org/pgsql-bugs/2009-12/msg00267.php
>
> The wide-char version of any WIN32 API call will accept or return
> data in UTF-16 encoded Unicode, regardless of the local environment's
> single-byte (MBCS) encoding se
On Wed, Jan 6, 2010 at 4:52 PM, 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 wasn't as
Just an FYI regarding this bug:
http://archives.postgresql.org/pgsql-bugs/2009-12/msg00267.php
Windows always uses UNICODE to store file and directory names.
The wide-char version of any WIN32 API call will accept or return data in
UTF-16 encoded Unicode, regardless of the local environment's s
Greg Stark wrote:
On Thu, Jan 7, 2010 at 12:44 AM, Josh Berkus wrote:
Agreed. I really don't think a bug tracker helps us. We need two things:
(1) to respond to bug submissions immediately and fix them, and
(2) if we can't fix the bugs immediately, to add them to a TODO list
Adding stu
On Thu, Jan 7, 2010 at 12:44 AM, Josh Berkus wrote:
> Agreed. I really don't think a bug tracker helps us. We need two things:
>
> (1) to respond to bug submissions immediately and fix them, and
> (2) if we can't fix the bugs immediately, to add them to a TODO list
>
> Adding stuff to a bug trac
On Thu, 2010-01-07 at 00:45 +, Greg Stark wrote:
> On Wed, Jan 6, 2010 at 11:09 PM, Andrew Dunstan wrote:
> > Oh, wow, I didn't realize it was time for another round of this. Whe!
> >
>
> Actually I suspect it is time.
>
> My preferences have changed. While they used to go something like
On Wed, Jan 6, 2010 at 5:04 PM, Kevin Grittner
wrote:
> 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
On Wed, Jan 6, 2010 at 6:11 PM, Tom Lane wrote:
> I wrote:
>> 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 pointer:
>
> Actually, there were three dif
On Wed, Jan 6, 2010 at 11:09 PM, Andrew Dunstan wrote:
> Oh, wow, I didn't realize it was time for another round of this. Whe!
>
Actually I suspect it is time.
My preferences have changed. While they used to go something like
debbugs > RT > nothing > bugzilla they now go something like debbu
> Personally, I was more hoping we could consider fixing some of them...
Agreed. I really don't think a bug tracker helps us. We need two things:
(1) to respond to bug submissions immediately and fix them, and
(2) if we can't fix the bugs immediately, to add them to a TODO list
Adding stuff t
Tom Lane wrote:
> Because the domain is supposed to be opaque as to exactly what its
> underlying type is. In particular, you're supposed to do this:
>
> CREATE DOMAIN varchar2 AS pg_catalog.varchar(10);
>
> If you look in the SQL spec you will not find any suggestion that it
> should w
On Wed, Jan 6, 2010 at 6:09 PM, Andrew Dunstan wrote:
> Alvaro Herrera wrote:
>> 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
Arie Bikker wrote:
Sorry for the previous NUUUB post, didn't now the mailing list doesn't
support html ;(
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()',''
Alvaro Herrera wrote:
decibel wrote:
We've actually run into similar issues. Alvaro came up with a patch
that fixes our specific issue, but I think he said there were some
other cases that needed to be fixed as well. Anyone looking to fix
this should ping Alvaro first.
No, what I fi
decibel wrote:
> We've actually run into similar issues. Alvaro came up with a patch
> that fixes our specific issue, but I think he said there were some
> other cases that needed to be fixed as well. Anyone looking to fix
> this should ping Alvaro first.
No, what I fixed was the contrib/xml2 cra
On Jan 6, 2010, at 5:46 PM, Andrew Dunstan wrote:
> Tim Bunce wrote:
>> I was investigating a bug in an 8.4.1 production system and distilled a
>> test case down to this:
>>
>>CREATE OR REPLACE FUNCTION bar() RETURNS integer AS $$
>>#die 'BANG!'; # causes server process to exit(2)
>>
Tim Bunce wrote:
I was investigating a bug in an 8.4.1 production system and distilled a
test case down to this:
CREATE OR REPLACE FUNCTION bar() RETURNS integer AS $$
#die 'BANG!'; # causes server process to exit(2)
# alternative - causes server process to exit(255)
I was investigating a bug in an 8.4.1 production system and distilled a
test case down to this:
CREATE OR REPLACE FUNCTION bar() RETURNS integer AS $$
#die 'BANG!'; # causes server process to exit(2)
# alternative - causes server process to exit(255)
spi_exec_query("inv
On Jan 6, 2010, at 3:31 PM, Tim Bunce wrote:
> For 8.5 I don't think I'll even attempt direct inter-plperl-calls.
>
> I'll just do a nicely-sugared wrapper around spi_exec_prepared().
> Either via import, as I outlined earlier, or Garick Hamlin's suggestion
> of attributes - which is certainly wo
On Wed, Jan 06, 2010 at 11:41:46AM -0500, 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
Tom Lane wrote:
> 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.
On Wed, Jan 06, 2010 at 01:45:45PM -0800, David E. Wheeler wrote:
> 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 s
I wrote:
> 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 pointer:
Actually, there were three different problems there:
1. Relying on a HASH_REMOVE'd has
Alvaro Herrera wrote:
> Open a few psql with -f pointing to a pipe, and from the shell
> write into the pipe? I don't think it's straightforward, but it
> should be possible.
I'll play with it and see what I can do.
Thanks,
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
Alvaro Herrera wrote:
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
Marko Tiikkaja wrote:
> On 2010-01-07 00:08 +0200, 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.
>
> I don't see how that would work, but I might have misunderstood what
> we're reaching for here. What I
Sorry for the previous NUUUB post, didn't now the mailing list doesn't
support html ;(
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 e
Marko Tiikkaja wrote:
> On 2010-01-07 00:08 +0200, 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.
>
> I don't see how that would work, but I might have misunderstood
> what we're reaching for here. What
Magnus Hagander writes:
> On Wed, Jan 6, 2010 at 23:17, Tom Lane wrote:
>> BTW, I trust the non-windows case should be "int".
> Haha, yeah, that was my attempt at producing a warning. Which didn't work :-)
Hmm ... "char *" would provoke warnings, but only in the places that
were using the new d
On Wed, Jan 6, 2010 at 23:17, Tom Lane wrote:
> Magnus Hagander writes:
>> + /* socket has a different definition on WIN32 */
>> + #ifndef WIN32
>> + typedef char pgsocket;
>> + #else
>> + typedef SOCKET pgsocket;
>> + #endif
>
> BTW, I trust the non-windows case should be "int".
Haha, yeah, tha
Magnus Hagander writes:
> + /* socket has a different definition on WIN32 */
> + #ifndef WIN32
> + typedef char pgsocket;
> + #else
> + typedef SOCKET pgsocket;
> + #endif
BTW, I trust the non-windows case should be "int".
regards, tom lane
--
Sent via pgsql-hackers mai
On 2010-01-07 00:08 +0200, Peter Eisentraut wrote:
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 te
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
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
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
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 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
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
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 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
"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
"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
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
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
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 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
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.
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 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
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
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
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:
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
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 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
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 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
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?
"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
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.
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
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
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
>
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
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
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
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
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
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 "
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
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
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
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
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
1 - 100 of 158 matches
Mail list logo
