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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>> 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
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
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
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
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
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
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
---
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
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'
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
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
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 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
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
> >
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 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
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
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
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
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
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
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, 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
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
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
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 .
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]> |
|
> 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
>> > 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
> > 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
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);
> -
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
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
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
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?
|-+---
> 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
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
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 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 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 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 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
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
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
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
60 matches
Mail list logo