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
behave the same. However the question also was raised a few days ago on
the italian maili
On Thu, Nov 6, 2008 at 3:59 PM, Fujii Masao <[EMAIL PROTECTED]> wrote:
> 1) Start postgres in the primary
> 2) Get an online-backup in the primary
> 3) Locate the online-backup in the standby
> 4) Start postgres (with walreceiver) in the standby
># Configure restore_command, host of the primary
Hello,
I'm submitting 2 contrib modules and there 3 patches to core for them
from me and Martin, but they confict each other and there are some hunks
and rejections already. Here is an assorted patch of them.
Can I ask you to review the patches in this form?
- Martin's querydesc patch
http://
Tom Lane a écrit :
> Bernd Helmle <[EMAIL PROTECTED]> writes:
>> * We really should error out when trying to copy into the same tablespace
>> the database already lives in.
>
> No, I think that should just be a no-op. We don't for instance throw
> error when you ALTER OWNER to the existing owner
Hi,
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 for the relation?
Regards,
Nikhils
--
http://www.
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
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
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
"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
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
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
"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
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
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
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
"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
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.
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
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.
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
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
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
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
> 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
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
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
>
>
"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
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?
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 |
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
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
>>> 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
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
"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
>>> 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
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 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
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
"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
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 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
>
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
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
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
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
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 <[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
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
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
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?
--
"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
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,
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
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
--
"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
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
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
"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
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
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
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
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?
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
>>> 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:
> 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
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
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
"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
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
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
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
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
> 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
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
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:
> > 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
> 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" <[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
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
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
"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
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
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
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
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:
> 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
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
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
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 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
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, 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 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
> 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
> -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
"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
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
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
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
1 - 100 of 105 matches
Mail list logo