I tried running 'make installcheck' in contrib just now, and didn't
get past btree_gist :-(
The interval test fails with the attached diffs. text, varchar, char,
bytea, bit, varbit and numeric either dump core or go into infinite
loops during CREATE INDEX. (It's probably significant that these
On Tue, 2004-06-01 at 01:33, Tom Lane wrote:
First you might want to check which flavor of strerror_r() your platform
has --- does it return int or char* ?
I made the following change to the strerror_r call, which makes it work
correctly with threading enabled:
--- src/port/thread.c 23 Apr
Ok, I'll have a look.
Tom Lane wrote:
I tried running 'make installcheck' in contrib just now, and didn't
get past btree_gist :-(
The interval test fails with the attached diffs. text, varchar, char,
bytea, bit, varbit and numeric either dump core or go into infinite
loops during CREATE INDEX.
In article [EMAIL PROTECTED],
Chris Campbell [EMAIL PROTECTED] writes:
Harald Fuchs wrote:
Why don't you just do
( echo -- This is my comment
pg_dump whatever
) dumpfile
?
How could I dump using the custom format, and then use dumpfile with
pg_restore to restore the dump? If I just
On Tue, 2004-06-01 at 01:24, Tom Lane wrote:
I was just about to commit a patch that revises the btree index build
procedure as discussed here:
http://archives.postgresql.org/pgsql-general/2004-05/msg00480.php
specifically, not using shared buffers during index build and bypassing
WAL-logging
On Monday 31 May 2004 22:00, Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
Right now following are measured in pages
wal_buffers
shared_buffers
effective_cachesize
while rest of the memory parameters are in kb. I thought being uniform
would be good. Besides it will
On Tuesday 01 June 2004 14:12, Shridhar Daithankar wrote:
Actually I need to find out few more things about it. It is not as simple
as adding a assign_hook. When I tried to initdb with changes, it demanded
64MB of shared buffers which I (now) think that somewhere NBuffers are used
before
On Fri, 28 May 2004 14:47:01 -0400, Tom Lane [EMAIL PROTECTED] wrote:
If putting back xmax is the price we must pay for nested transactions,
then we *will* pay that price. Maybe not in this release, but it will
inevitably happen.
we = every Postgres user, even those that do not use
On Fri, 28 May 2004 21:59:53 -0400, Alvaro Herrera
[EMAIL PROTECTED] wrote:
So the assumption was that when we see that this has
happenned, the Cmin is no longer important (== every future command can
already see the tuple)
If it was that simple, we wouldn't have had to invent the CMIN_IS_CMAX
On Tue, Jun 01, 2004 at 02:37:37PM +0200, Manfred Koizar wrote:
On Fri, 28 May 2004 21:59:53 -0400, Alvaro Herrera
[EMAIL PROTECTED] wrote:
So the assumption was that when we see that this has
happenned, the Cmin is no longer important (== every future command can
already see the tuple)
If
I think an actually implementable version of this would be:
1. Don't log any index operations at all in WAL.
2. When recovering from WAL, restore all the table contents by WAL
replay. (This would of course include the system catalog contents that
describe the indexes.) Then sit there
This may be out of scope but I'm goign to mention it. Would error trapping
help any of these issues. In Oracle PL/SQL you have an exception section to
handle any known or unknown errors. Is this for the future or does the
nested xacts code include this at all?
On 12 Feb, Tom Lane wrote:
[EMAIL PROTECTED] writes:
Ok, I have EXPLAIN ANALYZE results for both the power and throughput
tests:
http://developer.osdl.org/markw/dbt3-pgsql/
Thanks. I just looked at Q9 and Q21, since those are the slowest
queries according to your chart. (Are all the
Simon Riggs [EMAIL PROTECTED] writes:
The mechanism you suggest would also break crash recovery, not just PITR
No it wouldn't.
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose
Mark Gibson wrote:
I've found the problem, although I'm still a bit confused by it.
I hate to do this to you now, but after some thought I think I have a
better approach -- I'd be interested in opinions on that assessment.
The attached eliminates pgresultGetTupleDesc() entirely and instead
Oliver Elphick [EMAIL PROTECTED] writes:
- strerror_r(errnum, strerrbuf, buflen);
+ char buf[256];
+ StrNCpy(strerrbuf, strerror_r(errnum, buf, 256), buflen);
return strerrbuf;
Easier and safer would be
- strerror_r(errnum, strerrbuf, buflen);
- return
Sometime between yesterday and today queries in the form of
select * from t where t.f like 'k%' have been broken so that they
never use the index (on win32, not sure about others).
On win32, at least, they have been broken for a while but this was
due
to a known issue based on the
Sometime between yesterday and today queries in the form of
select * from t where t.f like 'k%' have been broken so that they
never use the index (on win32, not sure about others).
On win32, at least, they have been broken for a while but this was
due
to a known issue based on the
It looks to me like you have an index of type bpchar but are
searching
with type text. I find type conversions very limited with LIKE.
I would create an index on 'vin_no' using a cast to TEXT. This should
work
on both queries.
Not in this case. Just to be sure, I created a new column as
Sounds like a project manager type should be put into place to organize
this information into a straight stream instead of 50 random mists of water
|-+--
| | Andrew Dunstan |
| | [EMAIL PROTECTED] |
|
Marc G. Fournier wrote:
Just so that everyone is aware, we are going to push the freeze date
for 7.5 to July 1st.
Although we feel that there are enough improvements and features
already in place for 7.5, Tom's felt that if we gave it that extra
month, we could also have PITR in place for 7.5
Christopher Browne [EMAIL PROTECTED] writes:
PITR may turn out to be a don't care item if Slony1 winds up
providing its own approach to PITR. (e.g. - if you write out to
disk the sets of SQL statements that are to be applied to a replica,
then the spooled sets of these statements represent
Tom Lane [EMAIL PROTECTED] writes:
I thought for a little bit about a magic reconstruct the index WAL
entry that would invoke the index build procedure in toto, but that
doesn't look like it will fly either. (Two problems: during crash
recovery, you couldn't be sure that what's on disk for
On Tue, 1 Jun 2004, Andrew Dunstan wrote:
Marc G. Fournier wrote:
Just so that everyone is aware, we are going to push the freeze date for
7.5 to July 1st.
Although we feel that there are enough improvements and features already
in place for 7.5, Tom's felt that if we gave it that extra month,
Marc G. Fournier wrote:
On Tue, 1 Jun 2004, Andrew Dunstan wrote:
Marc G. Fournier wrote:
Just so that everyone is aware, we are going to push the freeze date
for 7.5 to July 1st.
Although we feel that there are enough improvements and features
already in place for 7.5, Tom's felt that if we
On Tue, Jun 01, 2004 at 12:52:32PM -0400, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
I thought for a little bit about a magic reconstruct the index WAL
entry that would invoke the index build procedure in toto, but that
doesn't look like it will fly either. (Two problems:
I really hate seeing all the developers wasting time and brain cycles on
this type of stuff. I would much rather that time and brain cycles be put
to the design and development of the code.
Would a project manager type position be of any value to take some of this
off the developers and
Alvaro Herrera [EMAIL PROTECTED] writes:
The big problem I see with this kind of approaches is that building an
index from scratch can take a huge amount of time, because you have to
sort the data. Building from WAL does not have this problem, so it can
be much faster.
I'm not clear that
Having a good hard copy (not having to search mailing list archives)
of release dates would be really nice, not just for developers, but
users too. Even if they are subject to change without notice.
I think Mozilla has a great concept with there Milestone Schedule, the
gray table at:
Greg Stark [EMAIL PROTECTED] writes:
I'm not clear that building from WAL is really going to be that much faster.
A) algorithmically it's only the factor of log(n) that you're talking about.
and B) the WAL will have records for every write, not just the final product,
so it might potentially
On Tue, Jun 01, 2004 at 01:55:38PM -0400, Greg Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
The big problem I see with this kind of approaches is that building an
index from scratch can take a huge amount of time, because you have to
sort the data. Building from WAL does not
Or even KDE as an example where they have both a document on the website
for release schedule and another one that is a list of features that are
desired for the next release, have been worked on, and have been
completed.
http://developer.kde.org/development-versions/
Having a good hard copy
On Thu, 27 May 2004, Christopher Browne wrote:
[EMAIL PROTECTED] (Bruce Momjian) wrote:
Win32 has 98% of its code in CVS, so it will make it
Tablespaces - Christopher says it is ready, and has run tests
PITR - some functionality might be in 7.5, but we aren't sure
Nested
On Tue, 2004-06-01 at 18:26, Andrew Dunstan wrote:
Marc G. Fournier wrote:
On Tue, 1 Jun 2004, Andrew Dunstan wrote:
Marc G. Fournier wrote:
Just so that everyone is aware, we are going to push the freeze date
for 7.5 to July 1st.
Although we feel that there are enough
Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
I'm not clear that building from WAL is really going to be that much faster.
A) algorithmically it's only the factor of log(n) that you're talking about.
and B) the WAL will have records for every write, not just the final product,
so
On Tue, 2004-06-01 at 03:21, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I assume if someone turns on archiving in postgresql.conf, sighups the
postmaster, then does a tar backup, they should be able to do archiving,
no?
I would have zero problem
On Tue, 2004-06-01 at 03:13, Alvaro Herrera wrote:
A completely different idea would be to log a logical index creation,
so that during normal recovery those entries are saved somewhere; after
the rest of WAL recovery is done, the system is taken into a more normal
post-recovery pre-usable
Shridhar, Tom,
As long as we're messing around with PostgreSQL.conf, I propose that we
comment the file much more thouroughly -- in the style of Apache's httpd.conf
and our own pg_hba.conf (though maybe not quite as long as hba). Someone
proposed this for 7.4 and we ran out of time, and as
Josh Berkus [EMAIL PROTECTED] writes:
As long as we're messing around with PostgreSQL.conf, I propose that we
comment the file much more thouroughly -- in the style of Apache's httpd.conf
and our own pg_hba.conf (though maybe not quite as long as hba).
ISTM we had decided that putting vast
Heikki Linnakangas [EMAIL PROTECTED] writes:
There is also a lot of other functionality that throws not implemented
errors if you try to use 2PC with them. For example, DDL and
notifications.
Why would DDL be different from any other query?
regards, tom lane
I've noticed yet another hole in our handling of object permissions,
which is that ALTER OWNER doesn't modify the object ACL list at all.
This leads to unpleasant results. For example, in CVS tip:
regression=# \c - alice
You are now connected as new user alice.
regression= create table atable
Alvaro Herrera wrote:
Yes, I did follow it (you mean XMAX_IS_XMIN, right? I suppose no tuple
can really have Cmin == Cmax). I'm not claiming I understood it fully
though. But as you see, since the assumption is not valid we have to
drop the idea and put back the Xmax as a field on its own
On Tue, Jun 01, 2004 at 06:40:07PM -0400, Bruce Momjian wrote:
So, we need a way to record the xmin and xmax while keeping cmin and
cmax in the tuple header. My idea is for subtransactions to create
additional xid's that represent the opposite of the commit state for
changing tuples created
Bruce Momjian [EMAIL PROTECTED] writes:
BEGIN; xid=1
INSERT a;
BEGIN; xid=2
INSERT b;
DELETE a; xid=3
COMMIT;
COMMIT;
When DELETE a happens, we remove the xmin=1 from the tuple header and
replace it with xmin=3.
You can't change xmin --- this
Tom Lane wrote:
ISTM we had decided that putting vast amounts of documentation into the
file comments was exactly the thing *not* to do. It duplicates the SGML
documentation, thereby doubling the maintenance effort, to very little
purpose.
I agree. If people really think that adding more comments
It looks to me like you have an index of type bpchar but are
searching
with type text. I find type conversions very limited with LIKE.
I would create an index on 'vin_no' using a cast to TEXT. This should
work
on both queries.
Not in this case. Just to be sure, I created a new column as
Diego Montenegro [EMAIL PROTECTED] writes:
Also, in released versions, MM.c is included but not used, does anyone
know if it should work if we define the STABLE_MEMORY_STORAGE, or do a
lot coding has to be done for it to work?
Actually, I removed that file a few days ago because I didn't see
On Tuesday 01 June 2004 16:08, Simon Riggs wrote:
The June 1st date was first mentioned on list in mid-March (to me), but
wasn't generally announced until May under a specific heading. If it was
set in January, I was never knowingly party to that info.
Well, it should not have surprised
Hello,
I just saw a different documents not translate in the progresql project.
So i want participate to the translation in English to French, i am
just a french guy using linux since 8 years. It's time for me to give
some of my time to the Open Source Community .
So if it's possible:
-- I
Hi there fellow admins,
One of our databases had to be restored from a backup tape. Since there
weren't any dumps made. All I had was a live backup (I know I know) of
/var/lib/postgres/data/base/number. The number for the corresponding
database I manages to discover after some searching with
Lamar Owen wrote:
On Tuesday 01 June 2004 16:08, Simon Riggs wrote:
The June 1st date was first mentioned on list in mid-March (to me), but
wasn't generally announced until May under a specific heading. If it was
set in January, I was never knowingly party to that info.
Well, it should
Hackers,
Is there a reason why repalloc() does not behave the same as realloc?
realloc(NULL, size) behaves the same as malloc(size), and it seems
useful behavior -- I wonder why repalloc() chooses to Assert() against
this exact condition?
I assume this is because the NULL pointer would not know
Neil Conway wrote:
Tom Lane wrote:
ISTM we had decided that putting vast amounts of documentation into the
file comments was exactly the thing *not* to do. It duplicates the SGML
documentation, thereby doubling the maintenance effort, to very little
purpose.
I agree. If people really
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
BEGIN; xid=1
INSERT a;
BEGIN; xid=2
INSERT b;
DELETE a; xid=3
COMMIT;
COMMIT;
When DELETE a happens, we remove the xmin=1 from the tuple header and
replace it with xmin=3.
You can't change
Andrew Dunstan wrote:
That seems to indicate that at that stage, barely 2 months ago, the
month was not definite, let alone the day.
I confess that as a newcomer I was not around before the 7.4 cycle, so
saying that people should have known the freeze date because it is
following past
Alvaro Herrera [EMAIL PROTECTED] writes:
Is there a reason why repalloc() does not behave the same as realloc?
realloc(NULL, size) behaves the same as malloc(size), and it seems
useful behavior -- I wonder why repalloc() chooses to Assert() against
this exact condition?
We don't allow
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
You can't change xmin --- this would break visibility tests.
Basically the phantom xid's are a shorthand for saying the tuple was
created by xid1 and deleted by xid2, both part of the same main
transaction.
That would be fine if the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
You can't change xmin --- this would break visibility tests.
Basically the phantom xid's are a shorthand for saying the tuple was
created by xid1 and deleted by xid2, both part of the same main
transaction.
On Tue, Jun 01, 2004 at 11:17:40PM -0400, Bruce Momjian wrote:
Basically the phantom xid's are a shorthand for saying the tuple was
created by xid1 and deleted by xid2, both part of the same main
transaction.
Hmm... this would spread the ugliness elsewhere (hopefully only
On Tue, Jun 01, 2004 at 11:39:57PM -0400, Tom Lane wrote:
I assume this is because the NULL pointer would not know what context it
belongs to,
That's a sufficient reason from my point of view.
Right, you've convinced me. Just wanted to know if I could save three
lines of code. Probably
Alvaro Herrera wrote:
Also, we will need a phantom xid for every xid1/xid2 pair. You can't
just create one phantom xid per subtransaction because you must be able
to control independently commit/rollback rows based on the status of the
insert transaction.
Oh, sure. This could get huge
61 matches
Mail list logo
