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 Ap
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. (I
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
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-log
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. Besid
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 po
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 subtran
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_CMA
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 tup
> 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 t
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. (Ar
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 choo
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
de
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);
> -
> > 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 base
>> > 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 is
> 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 co
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 rep
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 di
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, w
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 gav
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 p
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 onto
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
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: http://www
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 potentia
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 doe
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
> >
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 fe
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
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 ha
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-usabl
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 I'
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 vas
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
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 creat
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 xm
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 creat
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
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 anyo
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 wa
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/. The number for the corresponding
database I manages to discover after some searching with strings and
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 not
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 w
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 peop
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
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
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 pa
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
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
> > trans
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
HeapTupleHeaderGet
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. Prob
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
60 matches
Mail list logo
