> Hmm... the problem is that an empty array is really zero-dimensional.
> So for what values of the second argument ought we to return 0?
>
> It certainly seems inconsistent to say that array_length({}, 6) = 0
> and array_length({1}, 6) is null.
Ugh. I meant rather:
It certainly seems inconsiste
>> There is a tiny problem with this implementation: It returns null for an
>> empty array, not zero. This is because array_lower and/or array_upper
>> return null for an empty array, which makes sense for those cases. We
>> could fix this by putting a coalesce around the expression, but since
>>
Tom Lane wrote:
> KaiGai Kohei <[EMAIL PROTECTED]> writes:
>> However, I wonder if the oid field should be also preserved at same
>> place, not inside a specific trigger function.
>
> Possibly. I wasn't planning to mess with it now; but if you've fixed
> the other problems with assigning to a sys
On Thursday 06 November 2008 17:35:58 Josh Berkus wrote:
> Joshua D. Drake wrote:
> > On Thu, 2008-11-06 at 17:24 -0500, Tom Lane wrote:
> >> Josh Berkus <[EMAIL PROTECTED]> writes:
> >>> The way the SQL scripts currently work, there is no way to manage what
> >>> schema the contrib modules get bui
On Thu, 6 Nov 2008, Tom Lane wrote:
-Is it worth considering making CRCs an optional compile-time feature, and
that (for now at least) you couldn't get them and the in-place upgrade at
the same time?
Hmm ... might be better than not offering them in 8.4 at all, but the
thing is that then you a
Greg Smith <[EMAIL PROTECTED]> writes:
> On Thu, 6 Nov 2008, Tom Lane wrote:
>> Another thought here is that I don't think we are yet committed to any
>> changes that require extra space between 8.3 and 8.4, are we? The
>> proposed addition of CRC words could be put off to 8.5, for instance.
> I
Josh Berkus <[EMAIL PROTECTED]> writes:
> Eh, Tom has a point. If we build module loading for 8.5, we shouldn't
> change the functionality in the interim for 8.4. Annoying as it is.
The main reason I'm concerned about it is that when we do modules
(which I certainly hope happens for 8.5) we wou
On Thu, Nov 6, 2008 at 5:31 PM, Lawrence, Ramon <[EMAIL PROTECTED]> wrote:
>> -Original Message-
>> > Minor question on this patch. AFAICS there is another patch that
> seems
>> > to be aiming at exactly the same use case. Jonah's Bloom filter
> patch.
>> >
>> > Shouldn't we have a dust off
"Nikhil Sontakke" <[EMAIL PROTECTED]> wrote:
> What is the reason for not having heap_blks_write kind of stats in the
> pg_statio system views? Is it because bgwriter does the writing (we do have
> bg stats there) most of the times? Wouldn't the write stats help to get the
> complete IO picture f
> -Original Message-
> > Minor question on this patch. AFAICS there is another patch that
seems
> > to be aiming at exactly the same use case. Jonah's Bloom filter
patch.
> >
> > Shouldn't we have a dust off to see which one is best? Or at least a
> > discussion to test whether they overlap
> The idea that you're going to get in-place upgrade all the way back to 8.2
> without taking the database down for a even little bit to run such a utility
> is hard to pull off, and it's impressive that Zdenek and everyone else
> involved has gotten so close to doing it.
I think we should at leas
--On Donnerstag, November 06, 2008 11:35:54 +0100 Guillaume Lelarge
<[EMAIL PROTECTED]> wrote:
Guillaume Lelarge a écrit :
v4 patch attached.
v5 patch attached.
Thanks Guillaume.
Maybe this is nit-picking, but i see that you have to rmdir() an existing
empty tablespace directory to use
On Thu, 6 Nov 2008, Tom Lane wrote:
Another thought here is that I don't think we are yet committed to any
changes that require extra space between 8.3 and 8.4, are we? The
proposed addition of CRC words could be put off to 8.5, for instance.
I was just staring at that code as you wrote this
On Thu, Nov 6, 2008 at 3:52 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2008-11-06 at 15:33 -0700, Joshua Tolley wrote:
>
>> Stay tuned.
>
> Minor question on this patch. AFAICS there is another patch that seems
> to be aiming at exactly the same use case. Jonah's Bloom filter patch.
>
>
On Thu, 2008-11-06 at 15:33 -0700, Joshua Tolley wrote:
> Stay tuned.
Minor question on this patch. AFAICS there is another patch that seems
to be aiming at exactly the same use case. Jonah's Bloom filter patch.
Shouldn't we have a dust off to see which one is best? Or at least a
discussion to
Joshua D. Drake wrote:
On Thu, 2008-11-06 at 17:24 -0500, Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
The way the SQL scripts currently work, there is no way to manage what
schema the contrib modules get built in *except* to edit the scripts.
Right, that's the intended and documen
On Thu, 2008-11-06 at 17:24 -0500, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > The way the SQL scripts currently work, there is no way to manage what
> > schema the contrib modules get built in *except* to edit the scripts.
>
> Right, that's the intended and documented way to d
On Wed, Nov 5, 2008 at 5:06 PM, Bryce Cutt <[EMAIL PROTECTED]> 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 a
Josh Berkus <[EMAIL PROTECTED]> writes:
> The way the SQL scripts currently work, there is no way to manage what
> schema the contrib modules get built in *except* to edit the scripts.
Right, that's the intended and documented way to do it.
> In fact, because of the SET statements, a DBA who mi
Tom,
I don't recall that having been proposed, and I don't think it's really
a good idea. We intentionally put those SETs in, not that long ago.
I haven't been able to find any reasoning on any list why those SETs
where a good idea. Bruce put them in, but apparently without
discussion. Un
Josh Berkus <[EMAIL PROTECTED]> writes:
> 1) Take the "SET search_path=public" out of all contrib SQL scripts so
> that DBAs can determine the correct schema by using PGOPTIONS.
I don't recall that having been proposed, and I don't think it's really
a good idea. We intentionally put those SETs i
All,
Looking at my old thread I realized I never got an answer on whether
people agreed with these two items:
1) Take the "SET search_path=public" out of all contrib SQL scripts so
that DBAs can determine the correct schema by using PGOPTIONS.
2) Add BEGIN/COMMIT to all SQL scripts.
--Josh
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Adding catalog columns seems rather complicated, and not back-patchable.
Agreed, we'd not be able to make them retroactively appear in 8.3.
> I imagined that you would have just a single cluster-wide variable, a
> GUC perhaps, indicating how much
"Robert Haas" <[EMAIL PROTECTED]> writes:
> That means, in essence, that the earliest possible version that could
> be in-place upgraded would be an 8.4 system - we are giving up
> completely on in-place upgrade to 8.4 from any earlier version (which
> personally I thought was the whole point of th
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I envision a similar system where we have utilities to guarantee all
> pages have enough free space, and all pages are the current version,
> before allowing an upgrade-in-place to the next version. Such a
> consistent API will make the job for users eas
Hi,
I figure that you're the maintainer for the dugong Postgres buildfarm
member.
I noticed that this member does not run tests for 8.3 or older stable
branches, only CVS HEAD. Is there a reason for this? I was just
checking IA64 machines and this seems to be the only one; it would be
very usef
"Robert Haas" <[EMAIL PROTECTED]> writes:
> OK, here's an updated version...
Applied with some small stylistic revisions.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
> And almost guarantee that the job will never be completed, or tested
> fully. Remember that in-place upgrades would be pretty painless so
> doing multiple major upgrades should not be a difficult requiremnt, or
> they can dump/reload their data to skip it.
Regardless of what design is chosen, t
Robert Haas wrote:
> > That's all fine and dandy, except that it presumes that you can perform
> > SELECT/UPDATE/DELETE on V3 tuple versions; you can't just pretend that
> > A-E aren't there until they get converted. Which is exactly the
> > overhead we were looking to avoid.
>
> I don't understa
Tom Lane wrote:
I think we can have a notion of pre-upgrade maintenance, but it would
have to be integrated into normal operations. For instance, if
conversion to 8.4 requires extra free space, we'd make late releases
of 8.3.x not only be able to force that to occur, but also tweak the
normal co
Robert Haas wrote:
> The second point could probably be addressed with a GUC but the first
> one certainly can't.
>
> 3. What about multi-release upgrades? Say someone wants to upgrade
> from 8.3 to 8.6. 8.6 only knows how to read pages that are
> 8.5-and-a-half or better, 8.5 only knows how to
> An external utility doesn't seem like the right way to approach it.
> For example, given the need to ensure X amount of free space in each
> page, the only way to guarantee that would be to shut down the database
> while you run the utility over all the pages --- otherwise somebody
> might fill s
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 most common case might well be like
Kevin Grittner wrote:
> Note that the 150 disk writes were for the CREATE and the DROP. Does
> that mean that we'd actually shave 84 of 150 writes?
Hmm, you'd shave more than 42 but not 84, because index entries are not
deleted until a later vacuum. (I'd say about 56 -- 42 plus the 14 heap
dele
Tom Lane wrote:
> Teodor Sigaev <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> It seems awkward; why can't we just have a
> >> single --locale switch that selects both settings at once?
>
> > Sometimes it's needed to use C-collate with non-C-ctype. But for most
> > users it's enough j
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> It seems awkward; why can't we just have a
>> single --locale switch that selects both settings at once?
> Sometimes it's needed to use C-collate with non-C-ctype. But for most
> users it's enough just a locale switch. What abou
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> That would make the file creation and unlink just under half the load.
Worst possible case :-( ... means that we wouldn't get much improvement
without addressing both aspects.
It strikes me however that this does put some urgency into the question
of
Alvaro Herrera wrote:
Hi,
I just noticed that the interface for choosing a different locale at db
creation time is
createdb --lc-collate=X --lc-ctype=X. Is there a reason for having
these two separate switches? It seems awkward; why can't we just have a
single --locale switch that selects both
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 module known to man.
I see. I t
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I envision a similar system where we have utilities to guarantee all
> > pages have enough free space, and all pages are the current version,
> > before allowing an upgrade-in-place to the next version. Such a
> > consistent API will
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> it's difficult to tell how much
> physical I/O results from the create or unlink syscalls. It might
be
> interesting to make a test program that just creates 4000 files
We use xfs with noatime for our databases.
In a fresh subdirectory of such a mount
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
No, we get the ldopts from Embed and then *remove* the ccldflags from
Config from that string. What is left is set as perl_embed_flags, and
that's what mustn't be empty.
Got it. Sounds good then.
What about the MakeMaker d
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> No, we get the ldopts from Embed and then *remove* the ccldflags from
> Config from that string. What is left is set as perl_embed_flags, and
> that's what mustn't be empty.
Got it. Sounds good then.
What about the MakeMaker dependency?
On Wed, 2008-11-05 at 13:23 -0500, Jonah H. Harris wrote:
> On Wed, Nov 5, 2008 at 12:35 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> >> The "Join Removal" item fails to point to a patch, also.
> >
> > I've removed that entry now. The patch was being worked on by Jonah but
> > it looks like we did
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I'm thinking of something like this change to config/perl.m4:
! if test -z "$perl_embed_ldflags" ; then
! AC_MSG_RESULT(no)
! AC_MSG_ERROR([unable to determine flags to link embedded Perl])
Hm, is it ce
Josh Berkus <[EMAIL PROTECTED]> writes:
> Unicron,
>> 4. Since it is just an alternative to "select * from Table", I think
>> this feature is unneccessary.
> Heh. I agree, but tell that to the SQL committee.
> I don't think we need to argue out the merits of adding standard syntax.
We can, ho
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> IMO, the client only build should be fixed, so we can:
> *) put the makefile hack I proposed in
> *) implement the keywords.c change suggested above
> *) set up backend/parser symlink from different/additional place.
The last of these seems the correc
On Thu, Nov 6, 2008 at 12:26 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> This looks caused by a change to clean up
>> some quoting issues:
>
> No, that patch is unrelated --- it didn't modify the inclusion situation
> at all.
oopright againcv
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I'm thinking of something like this change to config/perl.m4:
> ! if test -z "$perl_embed_ldflags" ; then
> ! AC_MSG_RESULT(no)
> ! AC_MSG_ERROR([unable to determine flags to link embedded Perl])
Hm, is it certain that "empty" is never a va
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> This looks caused by a change to clean up
> some quoting issues:
No, that patch is unrelated --- it didn't modify the inclusion situation
at all.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
Unicron,
4. Since it is just an alternative to "select * from Table", I think
this feature is
unneccessary.
Heh. I agree, but tell that to the SQL committee.
I don't think we need to argue out the merits of adding standard syntax.
This patch is Ready for Code Review.
--Josh
--
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Tom Lane escribió:
BuildRequires: perl(ExtUtils::MakeMaker) glibc-devel bison flex autoconf gawk
BuildRequires: perl(ExtUtils::Embed), perl-devel
Huh, but the requirement for ExtUtils::Embed is at runtime, so shou
Tom Lane wrote:
> One place that I've always wanted to look at was suppressing the
> creation of a btree metapage until there's some useful data in the
> table. We managed to avoid creating a root page until there's data,
> but at the time avoiding the metapage seemed too invasive. (Admittedly,
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> I think a large fraction of the writes you're measuring are coming from
>> the file create/unlink operations. It would certainly be important to
>> identify where the bulk of the cost *really* is before we start
Hi,
I just noticed that the interface for choosing a different locale at db
creation time is
createdb --lc-collate=X --lc-ctype=X. Is there a reason for having
these two separate switches? It seems awkward; why can't we just have a
single --locale switch that selects both settings at once?
--
On Thu, Nov 6, 2008 at 11:09 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> I'm trying to do client only builds on a bunch of legacy platforms and
>> noticed that the include path is messed up...if keywords.o is not
>> already built, it fails to build be b
On Thu, Nov 6, 2008 at 10:08 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I have no objection to cleaning up the backend internals, but system
> catalog definitions are client-visible. I don't think we should thrash
> the catalog definitions for minor aesthetic improvements. Since 8.3 is
> already o
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> I think a large fraction of the writes you're measuring are coming
from
> the file create/unlink operations. It would certainly be important
to
> identify where the bulk of the cost *really* is before we start
> expending effort on a solution.
Any ideas
Ron Mayer wrote:
Brendan Jurd wrote:
'T' ...
Indeed that's a bug in my code; where I was sometimes
requiring the 'T' (in the ISO8601 "alternative format") and
sometimes not (in the ISO8601 format from 5.5.4.2.1).
Below's a test case. If I read the spec[1] right both of those
should mean 1
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane escribi�:
> >> BuildRequires: perl(ExtUtils::MakeMaker) glibc-devel bison flex autoconf
> >> gawk
> >> BuildRequires: perl(ExtUtils::Embed), perl-devel
>
> > Huh, but the requirement for ExtUtils::Embed is at runtime, so
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> BuildRequires: perl(ExtUtils::MakeMaker) glibc-devel bison flex autoconf gawk
>> BuildRequires: perl(ExtUtils::Embed), perl-devel
> Huh, but the requirement for ExtUtils::Embed is at runtime, so shouldn't
> it be a plain Requires i
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Right -- I don't expect we can make use of such an idea readily. Not
> creating unnecessary pg_attribute entries for system columns is probably
> a lot easier to do.
I seem to recall having proposed that in the past, and getting shot down
on the basis
Brendan Jurd wrote:
I've applied them with a couple minor changes.
* If ISO 8601 5.5.3.1.d's statement "The designator T shall be
absent if all of the time components are absent." also applies
to 5.5.4.2.2; then I think the 'T' needed to be inside the
tags, so I moved it there. The link to the
Kevin Grittner wrote:
> It sounds like you were counting the 8kB pages pushed from the
> PostgreSQL cache to the OS cache, and I was counting the 1kB blocks
> pushed from the OS cache to the RAID controller cache. By watching
> vmstat results after pushing this to a more-or-less steady state, I
>
One more point on pg_am: amsearchnull is equal to "f" however the index
stores and could find nulls perfectly.
Regards,
Vladimir Sitnikov
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Note that the 150 disk writes were for the CREATE and the DROP. Does
> that mean that we'd actually shave 84 of 150 writes?
It really shouldn't be the case that each system catalog tuple insertion
generates a separate write --- especially not for mul
On Tue, Nov 4, 2008 at 4:17 PM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
> One open question is how to translate arrays with non-default subscript
> values
>
> Quote: "Subscripted assignment allows creation of arrays that do not use
> one-based subscripts. For example one might assign to myarray[-2
Alvaro Herrera wrote:
Tom Lane escribió:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
OK, I have got to the bottom of this. It appears that the Fedora people
have for some reason best known to themselves decided to stop bundling
the ExtUtils::Embed module with base perl, as it was befo
2008/11/6 Tom Lane <[EMAIL PROTECTED]>:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> OK, I have got to the bottom of this. It appears that the Fedora people
>> have for some reason best known to themselves decided to stop bundling
>> the ExtUtils::Embed module with base perl, as it was before.
>
>>> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Kevin Grittner wrote:
>
>> Note that the 150 disk writes were for the CREATE and the DROP.
Does
>> that mean that we'd actually shave 84 of 150 writes?
>
> Hmm, you'd shave more than 42 but not 84, because index entries are
not
> deleted until a l
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I'm trying to do client only builds on a bunch of legacy platforms and
> noticed that the include path is messed up...if keywords.o is not
> already built, it fails to build be because src/backend/parser but not
> src/backend is in the include path. (k
Tom Lane escribió:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > OK, I have got to the bottom of this. It appears that the Fedora people
> > have for some reason best known to themselves decided to stop bundling
> > the ExtUtils::Embed module with base perl, as it was before.
>
> That's been
>>> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Kevin Grittner wrote:
>> An idea for a possible enhancement to PostgreSQL: allow creation of
a
>> temporary table without generating any disk I/O. (Creating and
>> dropping a three-column temporary table within a database
transaction
>> currently ge
I'm trying to do client only builds on a bunch of legacy platforms and
noticed that the include path is messed up...if keywords.o is not
already built, it fails to build be because src/backend/parser but not
src/backend is in the include path. (keywords.c includes
parser/gram.h).
The following fix
Hello all,
( I posted already in pgsql-general and got no replies. )
I am in the process of updating my DB on Postgres 8.1.11 to 8.3.4. I
also use Slony 1.2.14 for replication.
Is there a safe path on how to accomplish this, please advice on what
steps I will need to consider. Bear
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
1) Sometimes index doesn't find all matching rows:
postgres=# SELECT * FROM qq WHERE t ='asd';
i | t
---+-
2 | asd
1 | asd
2 | asd
(3 rows)
postgres=# SET enable_seqscan=off;
SET
postgres=# SELECT * FROM qq WHERE t ='asd';
i |
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> On a recent test the last command of the last test has failed:
>> DROP TABLESPACE testspace;
>> ERROR: tablespace "testspace" is not empty
> Maybe it is failing due to files that are scheduled to be deleted by
> next checkpoint?
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> On Thu, Nov 6, 2008 at 9:01 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> It would have been useful to make this criticism before 8.3 was
>> released. I don't think it's reasonable to change it now.
> Well, I didn't have time to review code back in the
Simon Riggs wrote:
> I've run regression tests many, many times recently, usually in the form
> of a looping installcheck, rather than just make check.
>
> On a recent test the last command of the last test has failed:
> DROP TABLESPACE testspace;
> ERROR: tablespace "testspace" is not empty
>
>
On Thu, Nov 6, 2008 at 9:01 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> It would have been useful to make this criticism before 8.3 was
> released. I don't think it's reasonable to change it now.
Well, I didn't have time to review code back in the 8.3 days, and ugly
is ugly regardless of when it wa
> That's all fine and dandy, except that it presumes that you can perform
> SELECT/UPDATE/DELETE on V3 tuple versions; you can't just pretend that
> A-E aren't there until they get converted. Which is exactly the
> overhead we were looking to avoid.
I don't understand this comment at all. Unless
KaiGai Kohei <[EMAIL PROTECTED]> writes:
> However, I wonder if the oid field should be also preserved at same
> place, not inside a specific trigger function.
Possibly. I wasn't planning to mess with it now; but if you've fixed
the other problems with assigning to a system column then maybe we
s
Tom Lane napsal(a):
"Robert Haas" <[EMAIL PROTECTED]> writes:
To spell this out in more detail:
Suppose page 123 is a V3 page containing 6 tuples A, B, C, D, E, and
F. We examine the page and determine that if we convert this to a V4
page, only five tuples will fit. So we need to get rid of
Tom Lane wrote:
> KaiGai Kohei <[EMAIL PROTECTED]> writes:
>> Andrew Dunstan wrote:
>>> Wouldn't this omit comparing the null bitmap?
>
>> Oops, I added the comparison of null bitmap here.
>
> That's really, really ugly code. Why would it be necessary anyway?
> Shouldn't the security tag be expe
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 messages.
Rebased to the current HEAD.
2- Patch contains unnecessary spaces and tab
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> While working on the join elimination patch, I was going through the
> trigger code and found quite a bit of nastiness in regard to naming
> and variable repurposing related to the addition of replication roles
> in 8.3. The most obvious issue is tha
I've run regression tests many, many times recently, usually in the form
of a looping installcheck, rather than just make check.
On a recent test the last command of the last test has failed:
DROP TABLESPACE testspace;
ERROR: tablespace "testspace" is not empty
The directory was confirmed as non
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Why is InitIndexFreeSpaceMap coded to test for the FSM file already
>> existing? AFAICS it cannot yet exist and it should be an error anyway
>> if it does.
> Hmm. The FSM file can exist, if the index isn't created anew, but
> tr
"Robert Haas" <[EMAIL PROTECTED]> writes:
> To spell this out in more detail:
> Suppose page 123 is a V3 page containing 6 tuples A, B, C, D, E, and
> F. We examine the page and determine that if we convert this to a V4
> page, only five tuples will fit. So we need to get rid of one of the
> tup
KaiGai Kohei <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> Wouldn't this omit comparing the null bitmap?
> Oops, I added the comparison of null bitmap here.
That's really, really ugly code. Why would it be necessary anyway?
Shouldn't the security tag be expected to match? I suppose tha
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> OK, I have got to the bottom of this. It appears that the Fedora people
> have for some reason best known to themselves decided to stop bundling
> the ExtUtils::Embed module with base perl, as it was before.
That's been true since F-9, so I'm not quit
"Tim Keitt" <[EMAIL PROTECTED]> writes:
> [questions]
Switching memory contexts, in itself, only switches which context a bare
palloc() will allocate from (as opposed to MemoryContextAlloc). It
cannot have some magic impact on the validity of existing pointers.
> One last question: if I call SPI
On Thu, Nov 6, 2008 at 9:24 AM, Matteo Beccati <[EMAIL PROTECTED]> wrote:
> Hi,
>
>> Attached test shows a regression in analyze command.
>> Expected rows in an empty table is 2140 even after an ANALYZE is executed
>
> Doesn't seem to be a regression to me, as I've just checked that 8.0 did
> behav
On Thu, Nov 6, 2008 at 7:01 AM, Tim Keitt <[EMAIL PROTECTED]> wrote:
> I am working on a set returning function and have a question about
> switching memory contexts. Basically, what I want to know is whether
> memory allocated in one context can be referenced when a different
> context is current.
On Thu, 6 Nov 2008, "xie jiong" <[EMAIL PROTECTED]> writes:
> what's mean of pageno? or what 's "page" of a large object refer to?
> is this "page"(pageno) refer to "chunk"(chunk number) of lob, as
> opposed to real data page? (or just one data page to store one chunk
> of lob)
Checked the explana
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
> necessary. For example, after the standby falls down, the
> database at that time is applicable to
Hi,
I am reading code about large object of pgsql and have a question:
in pg_largeobject.h:
CATALOG(pg_largeobject,2613) BKI_WITHOUT_OIDS
{
Oid loid; /* Identifier of large object */
int4 pageno; /* Page number (starting from 0) */
bytea data; /* Data for page (may be zero-length
Hi,
I am reading code about large object of pgsql and have a question:
in pg_largeobject.h:
CATALOG(pg_largeobject,2613) BKI_WITHOUT_OIDS
{
Oid loid; /* Identifier of large object */
int4 pageno; /* Page number (starting from 0) */
bytea data; /* Data for page (may be zero-length)
Guillaume Lelarge a écrit :
> v4 patch attached.
>
v5 patch attached.
Fixes two issues :
* I forgot about Bernd's advice : "And i think we can avoid to call
database_file_update_needed() in this case then." This is fixed.
* I forgot to remove a debug ereport.
Sorry about this.
--
Guil
KaiGai Kohei wrote:
> KaiGai Kohei wrote:
>> Simon Riggs wrote:
>>> On Tue, 2008-10-21 at 18:48 +0900, KaiGai Kohei wrote:
>>>
I started to rework the SE-PostgreSQL documentation to catch up
the latest implementation, because the existing PDF documents are
a bit legacy to be updated.
1 - 100 of 105 matches
Mail list logo
