On Mon, Nov 3, 2008 at 8:41 PM, ITAGAKI Takahiro
<[EMAIL PROTECTED]> wrote:
> Hello, Saito-san:
>
> "Hiroshi Saito" <[EMAIL PROTECTED]> wrote:
>> next patch is this.
>
> I'm reviewing your patch and cleanup some parts:
i'm confused, original patch has this signature:
+ conv_strftime(char *src, siz
Hi,
Trying to review some patches on windows... mingw: 5.1.4; msys:
1.0.10; gcc 3.4.5
This is not current head but this morning snapshot tarball... but i
saw this same error with yesterday tarball...
I get this failure on regression tests:
expected output:
SELECT '10e-400'::float8;
! ERROR:
On Mon, Nov 10, 2008 at 8:27 PM, Unicron <[EMAIL PROTECTED]> wrote:
> I got a problem when reviewing patch "Automatically update view", the code
> can be built and executed successfully, but when i tried the eaxmple below,
> it seemed that the patch didn't work
>
AFAIR, this patch only supports S
On Mon, Nov 10, 2008 at 10:40 PM, Unicron <[EMAIL PROTECTED]> wrote:
> Here is another example for testing "Automatic update view", seems that
> "check option" doesn't work, i am not sure any other things i need to do, or
> it is a bug for the patch, anyone give me a help?
>
actually that is inten
Hi,
On Thu, Nov 6, 2008 at 3:59 PM, Fujii Masao <[EMAIL PROTECTED]> wrote:
>> Again, I would expect this to be integrated with server. I would expect
>> code to live in src/postmaster/walreceiver.c, with main logic in a file
>> alongside xlog.c, perhaps xreceive.c. We would start WALReceiver when
Andrew Dunstan wrote:
>
>
> Alvaro Herrera wrote:
> > Andrew Dunstan wrote:
> >
> >> OK, I have spent some time generating and filtering typdefs via objdump
> >> on various platforms. I filtered them and Bruce's list to eliminate
> >> items not actually found in the sources thus:
> >>
Here is another example for testing "Automatic update view", seems that "check
option" doesn't work, i am not sure any other things i need to do, or it is a
bug for the patch, anyone give me a help?
Thanks
postgres=# create view old_customer as
postgres-# select name,
postgres-# age,
po
I have a comment about reloptions of autovacuum parameters:
I'd like to have an easier way to extract individual parameters.
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Euler Taveira de Oliveira wrote:
> > What did I already do? I refactored reloptions.c to support multiple
> > options. I tried t
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> Do you have a proposal for a different API, or do you just want to
>> improve the comment for the function? Bear in mind that a lot of the
>> callers do know the string length, and so we shouldn't impose an
>> un
R Mayer <[EMAIL PROTECTED]> writes:
> Applied and pushed to the website http://0ape.com/postgres_interval_patches/
Applied with nontrivial revisions --- I fear I probably broke your third
patch again :-(. There were still a number of parsing bugs, and I also
didn't like the lack of error checking
I got a problem when reviewing patch "Automatically update view", the code can
be built and executed successfully, but when i tried the eaxmple below, it
seemed that the patch didn't work
create view v_name_account
as
select customer.name,
customer.age,
customer.city,
> -Original Message-
> From: Jonah H. Harris [mailto:[EMAIL PROTECTED]
> I have a new patch which does not create a bloom filter unless it sees
> that the hash join is going to batch. I'll send it along later
> tonight.
>
> Currently it's additional space not accounted for by work_mem.
>
R Mayer <[EMAIL PROTECTED]> writes:
> Applied and pushed to the website http://0ape.com/postgres_interval_patches/
I ran into an interesting failure case:
regression=# select interval 'P-1Y-2M3DT-4H-5M-6';
interval
---
P-1Y-2M3DT-10H-5M
(1 row)
This isn't the result I
Tom Lane <[EMAIL PROTECTED]> wrote:
> Do you have a proposal for a different API, or do you just want to
> improve the comment for the function? Bear in mind that a lot of the
> callers do know the string length, and so we shouldn't impose an
> unnecessary strlen() operation on those cases.
We
Gregory Stark wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> >> 1) Data does not fit on the new page. It will be solve by pre-upgrade
> >> check
> >> which reserve space on each page, before upgrade.
> >
> > Rather than specifying free space as an amount, I was thinking of having
> > a b
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> 1) Data does not fit on the new page. It will be solve by pre-upgrade check
>> which reserve space on each page, before upgrade.
>
> Rather than specifying free space as an amount, I was thinking of having
> a boolean like 'ready_for_upgrade' and the s
Simon Riggs <[EMAIL PROTECTED]> writes:
> More thought tells me that we should have a
> LockRelationForCatalogUpdate() that uses nearly the same design pattern
> as LockRelationForExtension(). There is no lockmode since we always take
> the lock in exclusive mode.
This works only for updaters that
On Mon, 2008-11-10 at 18:22 +0900, Fujii Masao wrote:
> Yeah, I also add walsender as new auxiliary process at first. But,
> during coding,
> I made out that this is more complicated for code and user.
>
> First problem : Which process accepts the connection from standby?
> IMO, *postmaster* sho
Joshua D. Drake escribió:
> On Mon, 2008-11-10 at 20:48 +, David Rowley wrote:
> > Josh Berkus Wrote:
> > > >> I would suggest submitting it to pgsql-jobs.
>
> >
> > Apart from the post during a commitfest does this not fit in with the
> > details given here:
> >
> > http://wiki.postgresql.o
David Rowley escribió:
> Or is sponsoring a feature paying money to people that already plan to
> implement something?
Nobody on their mind would plan to implement the features being proposed
here ... I didn't look very far but it seems mainly nonsense.
--
Alvaro Herrera
Zdenek Kotala wrote:
> In the last week community made decision about pg_upgrade project and its
> implementation. I would like to try summarize this conclusion and I add other
> topic which should be finished for 8.4.
>
> Convert on read has been selected as a good way, because it is not invasi
Andrew Dunstan wrote:
>
>
> David E. Wheeler wrote:
> > On Nov 10, 2008, at 11:17 AM, Andrew Dunstan wrote:
> >
> >> David, how is your awk-fu? If it's any good then I'm happy to leave
> >> it to you. Otherwise I will try to make a few hours somewhere to
> >> un-uglify this.
> >
> > My Perl is
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>
>> I think you could checksum the block including the hint bits then go back and
>> remove them from the checksum.
>
> I'm not sure what you're proposing here. It sounds to me like you are
> saying that we can read the page, make
Gregory Stark wrote:
> I think you could checksum the block including the hint bits then go back and
> remove them from the checksum.
I'm not sure what you're proposing here. It sounds to me like you are
saying that we can read the page, make it available to other users, and
then check the CRC.
On Sun, 2008-11-09 at 20:18 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Will think some more and report back.
>
> If you want to do some more development, here's the portion of the
> patch as yet unapplied --- will save you extracting it for yourself.
Thanks.
More thoug
Tom Lane <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Greg Stark wrote:
>>> I'm beginning to think just excluding the hint bits would be simpler and
>>> safer. If we're double buffering then it might be possible to do that
>>> pretty cheaply. Copy the whole buffer
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> I *was* going to question the inconsistent use of a space between the
> pointer qualifier and the argument name, for example:
> ...
> But then I noticed that there's a lot of this going on in datetime.c,
> some of it appears to predate your patches.
Any
David E. Wheeler wrote:
On Nov 10, 2008, at 11:17 AM, Andrew Dunstan wrote:
David, how is your awk-fu? If it's any good then I'm happy to leave
it to you. Otherwise I will try to make a few hours somewhere to
un-uglify this.
My Perl is excellent, but my awk is remedial. What part does awk
On Nov 10, 2008, at 11:17 AM, Andrew Dunstan wrote:
David, how is your awk-fu? If it's any good then I'm happy to leave
it to you. Otherwise I will try to make a few hours somewhere to un-
uglify this.
My Perl is excellent, but my awk is remedial. What part does awk play?
Best,
David
--
On Mon, 2008-11-10 at 20:48 +, David Rowley wrote:
> Josh Berkus Wrote:
> > >> I would suggest submitting it to pgsql-jobs.
>
> Apart from the post during a commitfest does this not fit in with the
> details given here:
>
> http://wiki.postgresql.org/wiki/How_to_sponsor_a_feature
>
> Or is
Tom Lane wrote:
> Michael Meskes <[EMAIL PROTECTED]> writes:
>> Also included is a perl version of the script created by a2p
>> and fixed by me. Unfortunately a2p did not generate working code, so I guess
>> eventually we have to only work with the perl version. I guess a perl hacker
>> can beautif
Josh Berkus Wrote:
> >> I would suggest submitting it to pgsql-jobs.
> >
> > Except that it's not a job offer - it's more of a "solicitation for
> > implementation of something," so I'm not sure that's the right place
> > either.
>
> No, but that's where the right people would see it.
>
> Realist
On Mon, Nov 10, 2008 at 2:42 PM, Lawrence, Ramon <[EMAIL PROTECTED]> wrote:
> I have tested the Bloom filter patch. It compiles cleanly against HEAD.
Thank you for testing this!
> As indicated, the performance improvements for hash join are good,
> especially when the build table is filtered wit
On Nov 9, 2008, at 11:09 PM, Joshua D. Drake wrote:
I think it's time for people to stop asking for the moon and realize
that if we don't constrain this feature pretty darn tightly, we will
have *nothing at all* for 8.4. Again.
Gotta go with Tom on this one. The idea that we would somehow upg
On Mon, 2008-11-10 at 21:21 +0100, Josh Berkus wrote:
> Josh,
>
> > I would note that the individual has been hitting *everyone* directly
> > and via list. So either he is quite serious, doesn't understand
> > etiquette or is a spammer.
>
> I think there is a language barrier at work.
Oh certain
Hitoshi Harada wrote:
> > The spec says: "The ROW_NUMBER function computes the sequential row
> number,
> > starting with 1 (one) for the first row, of the row within its window
> > partition according to the window ordering of the window."
> >
> > I'm just not sure if we should block this or not.
Josh,
I would note that the individual has been hitting *everyone* directly
and via list. So either he is quite serious, doesn't understand
etiquette or is a spammer.
I think there is a language barrier at work.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Mon, 2008-11-10 at 21:13 +0100, Josh Berkus wrote:
> Chris Browne wrote:
> No, but that's where the right people would see it.
>
> Realistically, this means most likely contracting with 2nd Quadrant,
> Command Prompt or Peter Eisentraut.
I would note that the individual has been hitting *ev
On Sat, Nov 1, 2008 at 3:42 PM, Ron Mayer <[EMAIL PROTECTED]> wrote:
> # Patch 3: "cleanup.patch"
> Fix rounding inconsistencies and refactor interval input/output code
>
Compile, testing and regression tests all checked out.
I've picked up on a few code style issues, fixes attached.
If I'm rea
Chris Browne wrote:
[EMAIL PROTECTED] ("Jonah H. Harris") writes:
On Sun, Nov 9, 2008 at 7:41 PM, Decibel! <[EMAIL PROTECTED]> wrote:
I think you're barking up the wrong tree here; the community can't really do
hacking for hire. If you want to pay for something to be implemented (which
is great
Brendan Jurd wrote:
On Tue, Nov 11, 2008 at 2:36 AM, Ron Mayer
I get the expected result from 'P0001', but oddly enough if I specify
only the year and month, it pukes:
postgres=# select interval 'P0001-01';
Indeed. Thanks again.
I've fixed this and added regression tests to check the handling
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I have had a quick look at it. The perl is more than ugly - it's
unmaintainable IMNSHO. It violates perl best practice in many ways, and
reflects the age of the a2p utility quite badly.
There is no guarantee that the scri
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> I'm ready to sign off on this patch now and move on to the final
> cleanup patch. I'll update the commitfest to show this one as "ready
> for committer".
OK, I'll pick this one up now.
regards, tom lane
--
Sent via pgsql-hack
> -Original Message-
> On Sun, Nov 2, 2008 at 10:49 PM, Jonah H. Harris
> <[EMAIL PROTECTED]> wrote:
> It's effective as-is for a preliminary patch. The GUC code is the
> least of my worries.
>
> > Can you provide some figures on the performance impact of the bloom
> filter?
I have teste
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I have had a quick look at it. The perl is more than ugly - it's
> unmaintainable IMNSHO. It violates perl best practice in many ways, and
> reflects the age of the a2p utility quite badly.
> There is no guarantee that the script won't have to be look
David E. Wheeler wrote:
On Nov 10, 2008, at 8:03 AM, Tom Lane wrote:
We should probably standardize on the perl version, ugly or not, because
otherwise we'll have a difference in build process between Unix and
Windows machines. Personally I don't really care how ugly it is as long
as no one
On Tue, Nov 11, 2008 at 5:51 AM, R Mayer
<[EMAIL PROTECTED]> wrote:
> Applied and pushed to the website http://0ape.com/postgres_interval_patches/
>
This latest version works as expected and I don't detect any other
issues with the code or documentation ... seems I've run out of things
to gripe ab
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
What about the MakeMaker dependency?
The call to ldopts will fail if MakeMaker is not present, so this will
cover it. It's very unlikely to be absent - it's required to build
almost every Perl mod
Michael Meskes <[EMAIL PROTECTED]> writes:
> The attached version now is able to generate an ecpg parser without a single
> change in gram.y.
Sweet.
> Also included is a perl version of the script created by a2p
> and fixed by me. Unfortunately a2p did not generate working code, so I guess
> even
Alvaro Herrera wrote:
> I like Teodor's proposal; I'll see about implementing that.
Attached.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Index: src/bin/scripts/createdb.c
===
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> I like Teodor's proposal; I'll see about implementing that.
> Attached.
You missed updating the sgml docs, and personally I'd be inclined to
list -l before the individual --lc switches; otherwise it looks fine.
Michael Meskes <[EMAIL PROTECTED]> writes:
> On Mon, Nov 10, 2008 at 08:12:49AM -0500, Tom Lane wrote:
>> Which direction are you hoping to go --- remove Iconst/Sconst, or use
>> them everywhere?
> For ecpg I don't care, I have to make some changes during translation anyway.
> Right now my script
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Seems to me there's one there already.
>
> > You're thinking of initdb maybe? I'm talking about createdb.
>
> Oh, okay. But how often is someone going to be changing locales during
> createdb? I think the mos
Ron Mayer wrote:
Ah! That 5.5.4.2.1 comes from apparently an old Oct 2000
draft version of the spec titled ISO/FDIS 8601. (For now you can
see it here: http://0ape.com/postgres_interval_patches/ISO-FDIS-8601.pdf )
I'll fix all the links to point to the 2004 spec.
I updated my web site[1] wi
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Greg Stark wrote:
>> I'm beginning to think just excluding the hint bits would be simpler and
>> safer. If we're double buffering then it might be possible to do that
>> pretty cheaply. Copy the whole buffer with memcpy then loop through the
>> line p
[EMAIL PROTECTED] ("Jonah H. Harris") writes:
> On Sun, Nov 9, 2008 at 7:41 PM, Decibel! <[EMAIL PROTECTED]> wrote:
>> I think you're barking up the wrong tree here; the community can't really do
>> hacking for hire. If you want to pay for something to be implemented (which
>> is great!), you'll ne
On Mon, 2008-11-10 at 09:14 -0500, Matthew T. O'Connor wrote:
> Tom Lane wrote:
> > Decibel! <[EMAIL PROTECTED]> writes:
> >
> >> I think that's pretty seriously un-desirable. It's not at all
> >> uncommon for databases to stick around for a very long time and then
> >> jump ahead many versi
On Nov 10, 2008, at 8:03 AM, Tom Lane wrote:
We should probably standardize on the perl version, ugly or not,
because
otherwise we'll have a difference in build process between Unix and
Windows machines. Personally I don't really care how ugly it is as
long
as no one has to look at it ;-) .
On Tue, Nov 11, 2008 at 2:36 AM, Ron Mayer
<[EMAIL PROTECTED]> wrote:
> I updated my web site[1] with the latest version of this patch.
I'm just testing this latest version out now.
I get the expected result from 'P0001', but oddly enough if I specify
only the year and month, it pukes:
postgres=
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Alvaro Herrera wrote:
I like Teodor's proposal; I'll see about implementing that.
Attached.
You missed updating the sgml docs, and personally I'd be inclined to
list -l before the individual --lc switches; other
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> I like Teodor's proposal; I'll see about implementing that.
>
> > Attached.
>
> You missed updating the sgml docs, and personally I'd be inclined to
> list -l before the individual --lc switches; otherwise
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Otherwise, looks good.
> OK. Should we backpatch this? Arguably it's a build bug.
Yeah, probably.
> (Also it would be good if someone were to whisper in the ears of the
> Fedora people that removing ExtUtils::Embed entirely from th
Greg Stark wrote:
> I think double buffering solves the torn page problem but not the lack
> of wal logging. Alvarro solved the wal logging by deferring the wal
> logs. But I'm not sure how confident we are that it's logging enough.
>
Right now, it's WAL-logging HeapTupleHeader hint bits (inf
In the last week community made decision about pg_upgrade project and its
implementation. I would like to try summarize this conclusion and I add other
topic which should be finished for 8.4.
Convert on read has been selected as a good way, because it is not invasive and
does not limit fresh d
The attached version now is able to generate an ecpg parser without a single
change in gram.y. Also included is a perl version of the script created by a2p
and fixed by me. Unfortunately a2p did not generate working code, so I guess
eventually we have to only work with the perl version. I guess a p
On Mon, Nov 10, 2008 at 08:12:49AM -0500, Tom Lane wrote:
> Which direction are you hoping to go --- remove Iconst/Sconst, or use
> them everywhere?
For ecpg I don't care, I have to make some changes during translation anyway.
Right now my script just sets both to ecpg_iconst. There is a small adv
Brendan Jurd wrote:
On Sat, Nov 8, 2008 at 2:19 AM, Ron Mayer <[EMAIL PROTECTED]> wrote:
Hmmm... Certainly what I had in datatype.sgml was wrong, but I'm
now thinking 5.5.4.2.1 and 5.5.4.2.2 would be the most clear?
Sorry, I don't understand what you mean by "5.5.4.2.1". In the spec
Ah! T
2008/11/9 David Rowley <[EMAIL PROTECTED]>:
> I'm having a little trouble understanding the standard for NTH_VALUE(). I
> would have assumed that NTH_VALUE(name,1) would return the first name in the
> window. The current patch is using 0 for the first.
>
Hmmm, good point... I haven't thought about
2008/11/9 David Rowley <[EMAIL PROTECTED]>:
>
> I've done a little testing with NTILE(). I think a check should be added to
> the ntile() function in wfunc.c.
>
> david=# select name,salary,ntile(0) over (order by salary) as n from
> employees;
> ERROR: floating-point exception
> DETAIL: An inval
Tom Lane wrote:
Decibel! <[EMAIL PROTECTED]> writes:
I think that's pretty seriously un-desirable. It's not at all
uncommon for databases to stick around for a very long time and then
jump ahead many versions. I don't think we want to tell people they
can't do that.
Of course they
2008/11/10 David Rowley <[EMAIL PROTECTED]>:
> Hitoshi Harada wrote:
>> I found how to do it, though it's only on the case you gave. Thinking
>> about the planner optimization of the Window nodes (and its attached
>> Sort nodes), we must consider the execution order of more than one
>> node. In the
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Tom Lane napsal(a):
>> What is the point of this? We don't need it for 8.3->8.4, we aren't
>> going to back-patch such a thing into 8.2 or before (certainly not
>> before, since reloptions didn't exist before 8.2), and I would hope we
>> put in a more ge
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> I have a question about the result contract of pg_do_encoding_conversion().
It's poorly designed :-(
As near as I can tell, all uses of the function either pass a
null-terminated string or special-case the result == src case in such a
way that it doe
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Attached patch allows to setup storage parameter for space
reservation.
What is the point of this? We don't need it for 8.3->8.4, we aren't
going to back-patch such a thing into 8.2 or before (certainly not
before, since reloptions
Michael Meskes <[EMAIL PROTECTED]> writes:
> is there a reason why we sometimes use ICONST and SCONST directly in a rule in
> gram.y yet in other rules use Iconst and Sconst which in turn resolve to
> ICONST
> and SCONST? Some rules even use ICONST and Sconst, so there does not be any
> consistenc
Dirk Riehle wrote:
>
> I have a short CVS question please: How do I go from a particular file
> revision like
>
> pgsql/cvs/pgsql/src/backend/parser/parse_relation.c.1.3
>
> to the complete commit?
Also try cvs2cl, which might help you:
common_args="--revisions --no-indent --no-wrap --sepa
I have a question about the result contract of pg_do_encoding_conversion().
It can receive non null-terminated string because its arguments are
a char array and a byte length.
And it only returns a string, so the string should be null-terminated.
However, if conversions are not required, the funct
--On Sonntag, November 09, 2008 18:25:50 -0600 Decibel!
<[EMAIL PROTECTED]> wrote:
On Nov 7, 2008, at 9:53 AM, Tom Lane wrote:
FWIW, I don't see this patch as being terribly useful in the real world
until it can take place in the background, without locking stuff for a
huge amount of time. T
On Thu, Nov 6, 2008 at 8:08 PM, Benedek László
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> Thanks for your review.
>
> I created an updated patch according to your notices.
>
>> 1 - Patch does not apply cleanly on latest git repository, although
>> there is no hunk failed but there are some hunk succeeded
Hi,
is there a reason why we sometimes use ICONST and SCONST directly in a rule in
gram.y yet in other rules use Iconst and Sconst which in turn resolve to ICONST
and SCONST? Some rules even use ICONST and Sconst, so there does not be any
consistency. If this has no reason I'd like to make all rul
I updated the patch set of SE-PostgreSQL (revision 1206)
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1206.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1206.patch
[3/6]
http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4d
Hi, Pavan,
On Thu, Nov 6, 2008 at 9:35 PM, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 6, 2008 at 2:12 PM, Fujii Masao <[EMAIL PROTECTED]> wrote:
>>
>> If the database whose timeline is the same as the primary's
>> exists in the standby, 2)3) getting new online-backup is not
>> necessa
Hi, Simon
Thank you for the review.
On Fri, Nov 7, 2008 at 5:49 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-11-05 at 23:17 +0900, Fujii Masao wrote:
>
>> Authentication
>> ---
>> As pointed out at another thread, for authentication, I defined the database
>> on
Thank you for reviewing.
Jeff Davis <[EMAIL PROTECTED]> wrote:
> Another question: what is explain.log_analyze supposed to do? Changing
> it doesn't seem to have an effect; it always prints out the actual time.
That's because explain.log_analyze requires executor instruments,
and it's not free. I
On Wed, Nov 05, 2008 at 04:06:11PM -0800, Bryce Cutt wrote:
> The error is causes by me Asserting against the wrong variable. I
> never noticed this as I apparently did not have assertions turned on
> on my development machine. That is fixed now and with the new patch
> version I have attached al
Robert Haas napsal(a):
Let's suppose, for example, that in 8.5 we decide to change some type
that is presently 16 bits to 32 bits, or 8 bits to 16 bits, etc. This
will make some tuples bigger, and potentially much bigger, but since
it presumably won't be a commonly used data-type, most tuples w
Decibel! napsal(a):
Unless I'm mistaken, there are only two cases we care about for
additional space: per-page and per-tuple.
Yes. And maybe special space indexes could be extended, but it is covered in
per-page setting.
Those requirements could also
vary for different types of pg_class o
On Sun, Nov 09, 2008 at 11:28:50PM -0500, Robert Haas wrote:
> > Well, if that's what it is, I think it's a fairly poor design
> > decision. When I upgrade Oracle, SQL Server, or MySQL, I don't need
> > to plan the amount of free space in my blocks a year or more before an
> > upgrade. In fact, I
88 matches
Mail list logo
