I wrote:
> * the psql command seemed to have some ideas about supplying a blank
> CREATE OR REPLACE FUNCTION command for a nonexistent function, but this
> didn't actually work. In any case it seemed poorly thought out, because
> you'd really need to pay some attention to *why* the regproc/regproc
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> On Sat, Sep 6, 2008 at 10:10 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> ... I changed
>> the exit code to PSQL_CMD_NEWEDIT instead of PSQL_CMD_SEND, which causes
>> the command to wait in the query buffer.
> The principle of least astonishment suggests
Updated patch attached, based on comments from Ryan Bradetich and Tom
Lane, and sync'd to latest CVS version.
...Robert
On Mon, Sep 1, 2008 at 9:33 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Ryan Bradetich" <[EMAIL PROTECTED]> writes:
>> On Mon, Sep 1, 2008 at 1:00 PM, Tom Lane <[EMAIL PROTECTED]
On Sat, Sep 6, 2008 at 10:10 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> * the way you had it set up, the CREATE OR REPLACE FUNCTION command
> would be sent to the backend instantaneously upon return from the
> editor, with no opportunity for the user to decide he didn't want his
> changes applied.
Heikki Linnakangas wrote:
> The way my rewritten FSM works at the moment is that pages are handed
> out of the FSM in random order, to spread the load of multiple backends
> to different pages. That's good for spreading the load, but it occurred
> to me while observing a test case that inserts a
Andriy Bakay escreveu:
> I have problems to setup SSL for PostgreSQL server. I did all the steps
> which described in the documentation (17.8. Secure TCP/IP Connections
> with SSL), but when I try to start the PostgreSQL server the pg_ctl gave
> me: "could not start server". And nothing in the logs
Euler Taveira de Oliveira <[EMAIL PROTECTED]> writes:
> If you can't afford a 500 msec pgstat time, then you need to make it
> tunable. Another ideas are (i) turn on/off pgstat per table or database
> and (ii) make the pgstat time tunable per table or database. You can use
> the reloptions column t
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
> I have attached two patches:
> - funcdef.diff implements pg_get_functiondef()
> - edit.diff implements "\ef function" in psql based on (1).
I've applied this with some corrections (mostly around proper quoting)
and some outright editorialization:
*
Martin Pihlak escreveu:
> I suspected that, but somehow managed to overlook it :( I guess it was
> too tempting to use it. I'll start looking for alternatives.
>
If you can't afford a 500 msec pgstat time, then you need to make it
tunable. Another ideas are (i) turn on/off pgstat per table or data
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout wrote:
>> I suppose what happens is the original patch comes with design and
>> later a newer version is posted with just changes. The commitfest page
>> points to the latter, losing former in the archive somewhere.
> Hmm, IMO thi
Gregory Stark wrote:
> I wonder if it's worth keeping two variants at all really. Why not just make
> psql's native table formatting exactly ReST? Is there any part of it that we
> don't like as much as our existing tables?
It doubles the number of display lines; a very obvious shortcoming.
--
Martijn van Oosterhout wrote:
> Just one thing though, I picked a random patch and started reading.
> However, the commitfest page doesn't link to anywhere that actually
> describes *what* the patch is trying to do. Many patches do have the
> design and the patch in one page, but some don't.
>
>
On Thu, Sep 04, 2008 at 09:54:02PM +0100, Simon Riggs wrote:
> * coding review - does it follow standard code guidelines? Are there
> portability issues? Will it work on Windows/BSD etc? Are there
> sufficient comments?
>
> * code review - does it do what it says, correctly?
Just one thing though
Andrew Chernow escribió:
> Alvaro Herrera wrote:
>> Andrew Chernow escribió:
>>>* PQclear -
>>>* free's the memory associated with a PGresult
>>>*/
>>
>> I'd add a comment here stating why the event name is not deallocated;
>> otherwise it just looks like it's being leaked.
>
Tom Lane wrote:
> Martin Pihlak <[EMAIL PROTECTED]> writes:
>> So, as a simple optimization I am proposing that the file should be
>> only written when some backend requests statistics. This would
>> significantly reduce the undesired write traffic at the cost of
>> slightly slower stats access.
>
Andrew Chernow escribió:
> /*
>* PQmakeEmptyPGresult
>* returns a newly allocated, initialized PGresult with given status.
>* If conn is not NULL and status indicates an error, the conn's
>* errorMessage is copied.
>*
>* Note this is exported --- you wouldn't think
On Fri, 05 Sep 2008 15:23:18 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Martin Pihlak <[EMAIL PROTECTED]> writes:
> > So, as a simple optimization I am proposing that the file should be
> > only written when some backend requests statistics. This would
> > significantly reduce the undesired write
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> Also, does the leak still occur if
> you just run the query as-is rather than EXPLAIN ANALYZE it?
The machine became unresponsive similar to the early symptoms of the
apparent memory leak cited in this post:
http://archives.postgresql.org/pgsql-bugs/
Martin Pihlak <[EMAIL PROTECTED]> writes:
> So, as a simple optimization I am proposing that the file should be
> only written when some backend requests statistics. This would
> significantly reduce the undesired write traffic at the cost of
> slightly slower stats access.
How necessary is this g
On Fri, Sep 5, 2008 at 9:54 AM, Andrew Chernow <[EMAIL PROTECTED]> wrote:
> Andrew Chernow wrote:
>>
>> I think it got confused with the instanceData feature, which has nothing
>> to do with the event system and requires public functions. libpqtypes
>> happens to use the instanceData functions wit
Howdy,
The statistics collector currently dumps the stats file at every 500ms. This
is a major problem if the file becomes large -- occasionally we've been forced
to disable stats collection to cope with it. Another issue is that while the
file is frequently written, it is seldom read. Typically
On Fri, Sep 5, 2008 at 2:52 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
>> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> > yeah the "code coverage" changes broke it - the buildfarm dashboard is
>> > pretty telling:
>>
>> Yes --- it looks like the configure.in patch is desi
Tom Raney <[EMAIL PROTECTED]> writes:
> Why does the planner consider both input variations of each symmetric merge
> join? The README says "there is not a lot of difference" between the two
> options. When are there any differences?
The righthand side needs to support mark/restore, the left d
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> > yeah the "code coverage" changes broke it - the buildfarm dashboard is
> > pretty telling:
>
> Yes --- it looks like the configure.in patch is designed to look for
> gcov AND lcov (do we really need both?) AND genhtml, and err
Volkan YAZICI wrote:
> BTW, Alvaro fixed my string concatenations which yielded in lines
> exceeding 80 characters width, but I'd want to ask twice if you're sure
> with this. Because, IMHO, PostgreSQL is also famous with the quality and
> readability of its source code -- that I'm quite proud of
On Fri, 2008-09-05 at 11:21 -0700, Tom Raney wrote:
> Why does the planner consider both input variations of each symmetric merge
> join? The README says "there is not a lot of difference" between the two
> options. When are there any differences?
>
> -Tom Raney
>
http://archives.postgresql.
On Sep 5, 2008, at 11:30, Tom Lane wrote:
Thanks for reviewing. I've committed this with your suggestions and
one additional non-cosmetic change: schema-qualify names in the
bodies of the SQL functions so that they are not search_path
dependent.
Thanks, I'll check that out.
One thing that
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
The patch seems to be missing the new htup.c file.
I'm sorry. I attached new version which is synchronized with current
head. I would like to say more comments as well.
1) The patch contains also changes which was discussed during July
commi
"Ryan Bradetich" <[EMAIL PROTECTED]> writes:
> Here is my review of the Test citext casts written by David Wheeler:
Thanks for reviewing. I've committed this with your suggestions and
one additional non-cosmetic change: schema-qualify names in the
bodies of the SQL functions so that they are not
On Fri, 05 Sep 2008, Tom Lane <[EMAIL PROTECTED]> writes:
> I think the best way is to use
>
> subroutine(..., gettext_noop("special error message here"))
>
> at the call sites, and then
>
> errmsg("%s", _(msg))
>
> when throwing the error. gettext_noop() is needed to have the string
>
Why does the planner consider both input variations of each symmetric merge join? The
README says "there is not a lot of difference" between the two options. When
are there any differences?
-Tom Raney
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
On Fri, Sep 5, 2008 at 7:37 PM, Heikki Linnakangas <
[EMAIL PROTECTED]> wrote:
> So, you'll implement the part of SQL-MED that deals with specifying remote
> connections, e.g something like "CREATE CONNECTION" (no, I haven't looked at
> what the syntax actually is)?
>
> Yeah, that sounds like a go
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> The tables and views aren't that hard; finding a way to generate
> enough fake data may be a challenge. (I assume that since it took
> over a half hour to run out of memory, the volume of data needs to be
> sufficient to get there.)
We don't really n
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> yeah the "code coverage" changes broke it - the buildfarm dashboard is
> pretty telling:
Yes --- it looks like the configure.in patch is designed to look for
gcov AND lcov (do we really need both?) AND genhtml, and error out
if they're not presen
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> PortalHeapMemory: 1620992 total in 200 blocks; 5856 free (8
chunks);
> 1615136 used
>> ExecutorState: 2787288448 total in 364 blocks; 328 free (5
chunks);
> 2787288120 used
>
> Ouch. We have cre
Andrew Chernow wrote:
Getting this, my cvs copy is as of 1:00PM EST.
[EMAIL PROTECTED] pgsql]# ./configure --prefix=/usr
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking which template to use... linux
checking whether to build with 64-bit in
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The vices in the error message are not the translator's fault: missing
> quotes and "plpgsql" instead of "PL/pgSQL":
It's been message style policy for quite some time to not quote the
output of format_type. I think this is because format_type sometime
Getting this, my cvs copy is as of 1:00PM EST.
[EMAIL PROTECTED] pgsql]# ./configure --prefix=/usr
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking which template to use... linux
checking whether to build with 64-bit integer date/time support
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> PortalHeapMemory: 1620992 total in 200 blocks; 5856 free (8 chunks);
> 1615136 used
> ExecutorState: 2787288448 total in 364 blocks; 328 free (5 chunks);
> 2787288120 used
Ouch. We have created a memory leak someplace, but it's hard to te
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Actually this is wrong -- since the library is going to run with
> > "postgres" text domain, we need to add the files to the backend's
> > nls.mk:
>
> Can't we give it its own text domain? It seems fundamentally wrong
> for a plug-i
So, you'll implement the part of SQL-MED that deals with specifying
remote connections, e.g something like "CREATE CONNECTION" (no, I
haven't looked at what the syntax actually is)?
Yeah, that sounds like a good idea. We should get that into core, and
modify contrib/dblink to use it as well. I
On Fri, 2008-09-05 at 09:19 -0400, Andrew Dunstan wrote:
>
> Simon Riggs wrote:
> > On Thu, 2008-09-04 at 10:45 -0700, Josh Berkus wrote:
> >
> >
> >> If you are a postgresql hacker at all, or even want to be one, we need
> >> your
> >> help reviewing patches! There are several "easy" patch
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Actually this is wrong -- since the library is going to run with
> "postgres" text domain, we need to add the files to the backend's
> nls.mk:
Can't we give it its own text domain? It seems fundamentally wrong
for a plug-in language to require core sup
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > In reviewing Volkan Yazici's (sorry for the dots) patch to improve
> > plpgsql's error messages, I noticed that we have no PO files for plpgsql
> > at all!
>
> Ugh. Yeah, we should fix that. Does it actually just work, seeing
> tha
On 9/5/08, Marko Kreen <[EMAIL PROTECTED]> wrote:
> The list is correct but too verbose. And it does not attack the core
> of the problem. I think the problem is not:
>
> What can/should I do?
>
> but instead:
>
> Can I take the responsibility?
To clarify it - that was the problem I faced
Volkan YAZICI <[EMAIL PROTECTED]> writes:
> On Thu, 04 Sep 2008, Tom Lane <[EMAIL PROTECTED]> writes:
>> This is not ready to go: you've lost the ability to localize most of
>> the error message strings.
> How can I make this available? What's your suggestion?
I think the best way is to use
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> In reviewing Volkan Yazici's (sorry for the dots) patch to improve
> plpgsql's error messages, I noticed that we have no PO files for plpgsql
> at all!
Ugh. Yeah, we should fix that. Does it actually just work, seeing
that plpgsql is a loadable librar
Alvaro Herrera wrote:
> It doesn't seem hard to add; I just had to create a nls.mk file and
> things seem ready to go. Obviously, we'll need to add plpgsql to the
> pgtranslation files in pgfoundry.
Actually this is wrong -- since the library is going to run with
"postgres" text domain, we need
Hello again,
I received the following email from a helpful fellow off-list,
pointing out an error in my review:
On Fri, Sep 5, 2008 at 7:03 PM, Ragnar <[EMAIL PROTECTED]> wrote:
> On fös, 2008-09-05 at 15:07 +1000, Brendan Jurd wrote:
>> Wouldn't this be better written as:
>>
>>
Hi,
In reviewing Volkan Yazici's (sorry for the dots) patch to improve
plpgsql's error messages, I noticed that we have no PO files for plpgsql
at all!
It doesn't seem hard to add; I just had to create a nls.mk file and
things seem ready to go. Obviously, we'll need to add plpgsql to the
pgtrans
On Fri, 5 Sep 2008, Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Please use the patch I posted yesterday, as it had all the issues I
> found fixed. There were other changes in that patch too.
My bad. Patch is modified with respect to suggestions[1][2] from
Tom. (All 115 tests passed in cvs tip.)
On Fri, 2008-09-05 at 17:19 +0300, Marko Kreen wrote:
> >
> > I think this should be organised with different kinds of reviewer:
>
> The list is correct but too verbose. And it does not attack the core
> of the problem. I think the problem is not:
>
> What can/should I do?
>
> but instead:
On 9/5/08, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-09-05 at 16:03 +0200, Markus Wanner wrote:
> > > I don't *want* the rule, I just think we *need* the rule because
> > > otherwise sponsors/managers/etc make business decisions to exclude that
> > > aspect of the software dev proce
I was testing a very complex statistical query, with (among other
things) many EXISTS and NOT EXISTS tests against a build of the source
snapshot from 3 September. (The query looks pretty innocent, but
those aren't tables, they're complicated views.) Under 8.3.3 this
query runs successfully, but
Gregory Stark wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>
> > I have uploaded an example run here:
> > http://developer.postgresql.org/~petere/coverage/
> >
> > Current test coverage is about 66% overall.
>
> With some pretty glaring gaps: 0% coverage of geqo, 0% coverage of logtape
>
Hi,
Simon Riggs wrote:
Such as?
Dunno. Rules for sponsors? It would probably make sense to not only pay
a single developer to create and submit a patch, but instead plan for
paying others to review the code as well.
You might think those arguments exist and work, but I would say
they mani
Hi,
In PGCon 2008, I proposed synchronous log shipping replication.
Sorry for late posting, but I'd like to start the discussion
about its implementation from now.
http://www.pgcon.org/2008/schedule/track/Horizontal%20Scaling/76.en.html
First of all, I'm not planning to put the prototype which I
On 9/4/08, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-09-04 at 10:45 -0700, Josh Berkus wrote:
> > We currently have 38 patches pending, and only nine people reviewing them.
> > At this rate, the September commitfest will take three months.
> >
> > If you are a postgresql hacker at
On Fri, 2008-09-05 at 16:03 +0200, Markus Wanner wrote:
> > I don't *want* the rule, I just think we *need* the rule because
> > otherwise sponsors/managers/etc make business decisions to exclude that
> > aspect of the software dev process.
>
> I agree that making sponsors/managers/etc aware of
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I have uploaded an example run here:
> http://developer.postgresql.org/~petere/coverage/
>
> Current test coverage is about 66% overall.
With some pretty glaring gaps: 0% coverage of geqo, 0% coverage of logtape
which implies no tuplesorts are spilli
Hi Bruce and Team,
I have problems to setup SSL for PostgreSQL server. I did all the steps
which described in the documentation (17.8. Secure TCP/IP Connections
with SSL), but when I try to start the PostgreSQL server the pg_ctl gave
me: "could not start server". And nothing in the logs (I enable
Hi,
Simon Riggs wrote:
On Fri, 2008-09-05 at 09:19 -0400, Andrew Dunstan wrote:
All this would do is to deter people from submitting patches. Hard rules
like this don't work in FOSS communities. I know it's like herding cats,
but persuasion is really our only tool.
+1
I don't *want* the ru
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> I don't *want* the rule, I just think we *need* the rule because
> otherwise sponsors/managers/etc make business decisions to exclude that
> aspect of the software dev process.
How exactly would you even begin to enforce such a rule? Retroact
Andrew Chernow wrote:
I think it got confused with the instanceData feature, which has nothing
to do with the event system and requires public functions. libpqtypes
happens to use the instanceData functions within its eventproc, but this
is not a requirement.
I forgot to mention that the
I would like to remove the PQpassThroughData and PQresultPassThroughData
functions.The passThrough pointer should be added as a 3rd argument
to the PGEventProc:
typedef int (*PGEventProc)(PGEventId evtId, void *evtInfo,
void *passThrough);
Having a public accessor function for the passTh
Jorgen Austvik - Sun Norway wrote:
Alvaro Herrera wrote:
In my opinion, the need
for running tests outside the test dir is not very strong (or we would
have heard complaints before), and thus the solution is to remove
--inputdir and --outputdir.
Attached is a patch that removes --inputdir and
Simon Riggs wrote:
On Thu, 2008-09-04 at 10:45 -0700, Josh Berkus wrote:
If you are a postgresql hacker at all, or even want to be one, we need your
help reviewing patches! There are several "easy" patches in the list, so
I can assign them to beginners.
It would be a reasonable
Michelle Caisse wrote:
Thanks, I'll take a look at these issues.
I have committed your patch with some rework that mainly addresses the
concerns also found by Alvaro with regard to cleaning and dependency
handling. I have renamed the out target to coverage-html, to be more in
line with our
Volkan YAZICI wrote:
> On Thu, 4 Sep 2008, Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Cool, thanks. I had a look and you had some of the expected vs.
> > returned reversed.
>
> I'll happy to fix the reversed ones if you can report them in more
> details.
Please use the patch I posted yesterd
Hi,
Gregory Stark wrote:
I definitely like the int_array_append_aggregate function but I don't see
anything int[] specific about it. We should be able to have a generic
array_union() aggregate which uses the same IsA(fcinfo->context, AggState)
trick to scribble on its state variable. It don't ev
In the previous discussion there was mentioned that Postgres should
move to the SQL-MED direction in remote connection handling.
SQL-MED specifies that connections should have names and referenced
everywhere using names. PL/Proxy currently does not conform to that
standard - it uses connection st
Hi,
Gregory Stark wrote:
The naming 'bidx' seems a bit weired to me, but otherwise I'm also optimistic
about it.
If we wanted to put that in core
Uh.. ATM it's just a patch against contrib. I don't think 'bidx' needs
to go into core. Otherwise we'd have to move the whole intarr contrib
mod
Markus Wanner <[EMAIL PROTECTED]> writes:
> Hi,
>
> Gregory Stark wrote:
>> Regarding the patch listed on the commitfest "3 new functions into intarray
>> and intagg" (which I just noticed has a reviewer listed -- doh):
>
> ..well, just add your name as well, no?
Yeah, people should feel free to
Josh Berkus wrote:
Hackers,
We currently have 38 patches pending, and only nine people reviewing them.
At this rate, the September commitfest will take three months.
If you are a postgresql hacker at all, or even want to be one, we need your
help reviewing patches! There are several "easy
On Fri, 2008-09-05 at 12:18 +0100, Simon Riggs wrote:
>
> It would be a reasonable rule that all patch submitters also have to
> do patch reviews.
This is almost the only way to be accepted as a contributor to Fedora --
and I like it.
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.
> That way, instead of just an appeal to the masses to volunteer for
> $NEBULOUS_TASK, we can say something like "Please volunteer to review
> patches. Doing an initial patch review is easy, please see our guide
> to learn more."
+1. I'll review a patch if you like, but the patch I have in this
Josh Berkus wrote:
Hackers,
We currently have 38 patches pending, and only nine people reviewing them.
At this rate, the September commitfest will take three months.
If you are a postgresql hacker at all, or even want to be one, we need your
help reviewing patches! There are several "easy
Hi,
Gregory Stark wrote:
Regarding the patch listed on the commitfest "3 new functions into intarray
and intagg" (which I just noticed has a reviewer listed -- doh):
..well, just add your name as well, no?
I definitely like the int_array_append_aggregate function but I don't see
anything int
On Thu, 2008-09-04 at 10:45 -0700, Josh Berkus wrote:
> If you are a postgresql hacker at all, or even want to be one, we need your
> help reviewing patches! There are several "easy" patches in the list, so
> I can assign them to beginners.
It would be a reasonable rule that all patch submi
Regarding the patch listed on the commitfest "3 new functions into intarray
and intagg" (which I just noticed has a reviewer listed -- doh):
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
I definitely like the int_array_append_aggregate function but I don't see
anything int[] specif
Hi,
Stephen Frost wrote:
I would suggest you review the updated patch (linked off the wiki page)
here:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
That's the patch I've been talking about: file
colprivs_wip.20080902.diff.gz, dated Sept, 2nd.
It includes my comments about wh
Hi Markus,
* Markus Wanner ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
>> Comments welcome, apologies for it not being ready by 9/1. I'm
>> planning to continue working on it tomorrow, and throughout September
>> as opportunity allows (ie: when Josh isn't keeping me busy).
>
> I'm try
Zdenek Kotala wrote:
OK. You convinced me that information could be collected from other
sources.
Great, I'm glad we're in agreement.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
AFAICS you can get all the same information from pg_controldata. We have
a pretty good idea of the alignments of all the usual platforms anyway.
If someone says in a bug report that they're running on x86_64 o
On Fri, 2008-08-08 at 11:47 +0900, Fujii Masao wrote:
> On Thu, Aug 7, 2008 at 11:34 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, 2008-08-07 at 14:59 +0100, Simon Riggs wrote:
> >
> >> I'll do a patch. Thanks for your input.
> >
> > Please review attached patch.
>
> Thank you for yo
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
I'm afraid I still fail to see the usefulness of this. gdb knows how
to deal with structs,
If I correct that GDB knows structure only if you have debug version.
But usually you don't have debug version on production system.
Using gdb witho
Gregory Stark napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Hmm, good question. For example ZFS is platform independent, you can take disk
from SPARC machine and plug it into x86 and ZFS works perfectly.
FWIW as far as I know *all* filesystems are platform independent. (Of course
now
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Hmm, good question. For example ZFS is platform independent, you can take
> disk
> from SPARC machine and plug it into x86 and ZFS works perfectly.
FWIW as far as I know *all* filesystems are platform independent. (Of course
now someone is surely go
Heikki Linnakangas napsal(a):
The patch seems to be missing the new htup.c file.
Upps, I'm sorry I'm going to fix it and I will send new version asap.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hacker
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
The original proposal
(http://archives.postgresql.org/message-id/[EMAIL PROTECTED])
contains two parts. First part is implementation of --footprint cmd
line switch which shows you page layout structures footprint. It is
useful for development
Simon Riggs wrote:
On Thu, 2008-09-04 at 11:07 +0300, Heikki Linnakangas wrote:
Scenario: The binary tree on a page is corrupt, so that the value of an
upper node is > Max(leftchild, rightchild).
Consequence: Searchers will notice the corruption while trying to
traverse down that path, and thro
Hello Stephen,
Stephen Frost wrote:
Comments welcome, apologies for it not being ready by 9/1. I'm
planning to continue working on it tomorrow, and throughout September
as opportunity allows (ie: when Josh isn't keeping me busy).
I'm trying to review this patch. I could at least compile
92 matches
Mail list logo
