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
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 and
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
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
--
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.
--
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
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
behave the
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
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 quite
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 that it
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
tuples. We
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
truncated
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
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 that
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.
You
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
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.
In addition, I
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 explanation[1] in
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 expected to
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
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 was
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
The
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 8.3 days,
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? If it runs a
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.
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
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 generates about
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 true since
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.
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 later vacuum.
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.
That's
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
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:7] to
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 multiple
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
was
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
optional tags, so I moved it there. The link
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 that
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 instead
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 shouldn't
it
Ron Mayer wrote:
Brendan Jurd wrote:
'T' ... optional
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
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 a
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 out,
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 because
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
expending
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
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
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 valid value
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 againcvs annotate
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 correct fix.
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, however,
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
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 didn't make the
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
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 mountpoint:
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 make the
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 think
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
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 how
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 about
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 just a locale
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
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 some
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 read
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
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 understand this
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,
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:
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
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 easier
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 this
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 in,
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.
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 might
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
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 do it.
I
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
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.
Shouldn't
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 least
-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? Perhaps
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 for the
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 to see which one
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 would
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 was just
1 - 100 of 105 matches
Mail list logo
