On Wed, 18 May 2005, Tom Lane wrote:
* The major missing issue that I've come across so far is that
subtransaction and multixact state isn't preserved across a crash.
Assuming that we want to store only top-level XIDs in the shared-memory
list of prepared XIDs (which I think is important), it is es
On Wed, 2005-05-18 at 17:48 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Is there any particular reason that RelOptInfo doesn't have a debugging
> > output function?
>
> The planner structs involving RelOptInfo are self-referential, so if you
> just do the "obvious" thing y
Stephen Frost <[EMAIL PROTECTED]> writes:
>> Say, how are you doing on that front?
> Current status is- it now compiles with a few pieces still missing:
> [snip]
It's essential IMHO that we provide pg_shadow and pg_group as reasonably
backward-compatible views on the new pg_roles catalog. It's n
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Wed, May 18, 2005 at 07:29:38PM -0400, Tom Lane wrote:
>> What I had in mind was that each prepared xact's state file would just
>> list the MultiXactIds it belongs to.
> Hm, this assumes the transaction knows what MultiXactIds it belongs to.
> This
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
> > I havn't actually gotten anything real into PostgreSQL *yet*, but I've
> > been spending a fair bit of time on implementing support for SQL Roles
> > and have had alot of help developing the approach for best implementing
> > it (thanks Tom!) and help
Sergey Ten wrote:
We think that putting it in the backend will make access from other
components easier.
In what way?
It seems to me that this can be done just as easily in a client
application / library, without cluttering the backend with yet another
COPY output format. It would also avoid the
Josh Berkus wrote:
1) The TODO list is a bit impenetrable for new hackers wanting to get started
with PostgreSQL tasks.
[snip]
In fact, I'd
advocate a project task list for (1) (which we conveninetly have in
pgFoundry)
It belongs as part of the TODO list, I believe, or keeping it in sy
On Wed, May 18, 2005 at 08:16:47PM -0400, Tom Lane wrote:
> The reason things got this way is that we've been loading more and more
> functionality onto the array of PGPROC pointers that is, more or less
> incidentally, maintained by sinval.c. I'm thinking that it'd be a good
> idea to remove mos
On Wed, May 18, 2005 at 07:29:38PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > On Wed, May 18, 2005 at 05:15:09PM -0400, Tom Lane wrote:
> >> Similarly, we've got to reconstruct MultiXactIds that any prepared
> >> xacts are members of, else row-level locks taken out by p
While thinking about Heikki's 2PC patch, I've been getting annoyed about
how the SInvalLock is being overused. (The connection is that the
separate LWLock he proposes in his patch isn't going to work: addition
and removal of entries in the prepared-xact list has to be guarded by
SInvalLock, becaus
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Wed, May 18, 2005 at 05:15:09PM -0400, Tom Lane wrote:
>> Similarly, we've got to reconstruct MultiXactIds that any prepared
>> xacts are members of, else row-level locks taken out by prepared xacts
>> won't be enforced correctly. I think this can be
On Wed, May 18, 2005 at 05:15:09PM -0400, Tom Lane wrote:
> I've started to look seriously at Heikki's patch for two-phase commit.
Hum. I started a few days ago doing some reviewing, with the intention
of correcting some things here and there in order to present it all to
you later, with a pre-fi
On Wed, May 18, 2005 at 05:19:55PM -0400, Stephen Frost wrote:
> * Lamar Owen ([EMAIL PROTECTED]) wrote:
> > On Tuesday 17 May 2005 01:41, Josh Berkus wrote:
> > > > > To put it much more bluntly: PostgreSQL development (both the process
> > > > > and the codebase) has one of the steepest learning
Hi,
One thing I would suggest is to start a global transaction in begin, not in
prepare. That is way to be compliance with XA.
Thanks
Joe
On 5/18/05 2:15 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> I've started to look seriously at Heikki's patch for two-phase commit.
> There are a few issues
On Wed, 18 May 2005, Tom Lane wrote:
Oleg Bartunov writes:
unfortunately, no, because I deleted dump file. But, I just tried to
reproduce my problem with 8.0.3 and got no problem. I think, I tried
dump from 7.4.
Possibly it was just that 7.4's pg_dump isn't bright enough about dump
order? I can't
Simon Riggs <[EMAIL PROTECTED]> writes:
> Is there any particular reason that RelOptInfo doesn't have a debugging
> output function?
The planner structs involving RelOptInfo are self-referential, so if you
just do the "obvious" thing you will find outfuncs.c going into infinite
recursion. I haven
Is there any particular reason that RelOptInfo doesn't have a debugging
output function?
Seems too obvious an omission not have have some reasoning
there...perhaps just too complex and rapidly changing?
Best Regards, Simon Riggs
---(end of broadcast)
Oleg Bartunov writes:
> unfortunately, no, because I deleted dump file. But, I just tried to
> reproduce my problem with 8.0.3 and got no problem. I think, I tried
> dump from 7.4.
Possibly it was just that 7.4's pg_dump isn't bright enough about dump
order? I can't think of any other 7.4-to-8.0
On Wed, 18 May 2005, Tom Lane wrote:
Oleg Bartunov writes:
any problem in restore. Unfortunately, pg_dump explicitly defines
search path to 'public, pg_catalog' and any objects from 'contrib' schema
doesn't seen, which cause many errors, for example, table uses type tsvector,
which defined in tsea
* Lamar Owen ([EMAIL PROTECTED]) wrote:
> On Tuesday 17 May 2005 01:41, Josh Berkus wrote:
> > > > To put it much more bluntly: PostgreSQL development (both the process
> > > > and the codebase) has one of the steepest learning curves around,
>
> > You haven't looked at the OpenOffice.org code.
I've started to look seriously at Heikki's patch for two-phase commit.
There are a few issues that probably deserve discussion:
* The major missing issue that I've come across so far is that
subtransaction and multixact state isn't preserved across a crash.
Assuming that we want to store only top-
Neil,
We think that putting it in the backend will make access from other
components easier.
Thank you,
Sergey
> -Original Message-
> From: Neil Conway [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 17, 2005 7:11 PM
> To: Sergey Ten
> Cc: 'Bruce Momjian'; 'Christopher Kings-Lynne'; pgsql
Markus,
Thank you for your reply.
We considered embedding of an XML schema first followed by data. We decided
to stick to our current data format to make sure stateless XML parsers can
process it as well. Would it be better to add an option to the COPY command,
to allow embedding an XML schema, so
Oleg Bartunov writes:
> any problem in restore. Unfortunately, pg_dump explicitly defines
> search path to 'public, pg_catalog' and any objects from 'contrib' schema
> doesn't seen, which cause many errors, for example, table uses type tsvector,
> which defined in tsearch2 module, so that table do
Hi there,
I got a problem playing with schema and dump/restore process (8.0.3).
I created schema 'contrib' for my database and added it to search_path
in postgresql.conf. Then I loaded a bunch of modules to 'contrib schema' and
populated database with various tables. Everything is ok, I could dump
On Tuesday 17 May 2005 01:41, Josh Berkus wrote:
> > > To put it much more bluntly: PostgreSQL development (both the process
> > > and the codebase) has one of the steepest learning curves around,
> You haven't looked at the OpenOffice.org code.
Yes, I have. Yes, it's steeper.
--
Lamar Owen
D
Oleg Bartunov wrote:
Joshua,
does RT has full support of PostgreSQL ?
It support's Postgres, but it uses a dynamic query builder that is
pretty brain dead. It only implements features that are cross DB
compatible. It comes up with some pretty ugly queries.
--
Brad Nicholson 416-673-4106
Databas
On Wednesday 18 May 2005 04:54, Andrew Dunstan wrote:
> Meanwhile, how about the earlier suggestions related to improving the TODO
> list a bit (e.g. a "beginner's list")?
>
I think it would be simple enough to tag certain items on the list as low
hanging fruit that there is no reason not to do i
Thanks for the reply Tom!
I managed to get the cvs version and I made more progress compiling tsearch2
Here is where it errors out.
touch libtsearch2.a
../../src/backend/port/aix/mkldexport.sh libtsearch2.a > libtsearch2.exp
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels
-fn
People:
I think maybe we're putting on the frosting without the cake here. The
primary purpose of bug trackers is to help get bugs fixed. Over the last
couple of days, we've had a lot of comments from major bug-fixers that a BT
isn't *needed* to get bugs fixed. Let's look at tools which ad
On Wed, 2005-05-18 at 11:27 -0400, Tom Lane wrote:
> "Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> > Obviously in this case sequential scan was (would have been) a huge win.
> > Incrementing random_page_cost from 4 (the default) to 5 causes the
> > planner to make a better decision.
>
> But to
On Tue, May 17, 2005 at 11:24:19PM +0300, Hannu Krosing wrote:
> On T, 2005-05-17 at 11:22 -0400, Tom Lane wrote:
> > Hannu Krosing <[EMAIL PROTECTED]> writes:
> > > On T, 2005-05-17 at 00:42 -0400, Tom Lane wrote:
> > >> I seem to recall some discussion of how to do this in the past;
> > >> have y
Kaare,
I have a utility which will read Ingres r3 data files directly but I
don't think it would be that reliable to use. I suggest you get one of
the open source database conversion utilities written in Java, they work
pretty well. You can find a few of them on SourceForge/Freshmeat.
Thanks!
* Tom Lane ([EMAIL PROTECTED]) wrote:
> I think most of the real advantages of bug trackers that have been
> mentioned in this thread have to do with history and searchability.
> We have the raw info for that, in the pgsql-bugs and pgsql-commmitters
> mail archives, and so it seems to me that this
Tom Lane <[EMAIL PROTECTED]> writes:
> [ shrug... ] BZ sends me email too --- for the things *it* thinks I
> should know about.
Right, what I'm saying is that in RT it's more flexible; you can set it up to
send mail for the things *you* think people should know about.
Also, BZ and most bug track
"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> ... If bitmap
> scan is disabled, the planner will pick index scan even in cases when
> sequential scan is 10x faster:
> scratch=# set enable_bitmapscan to off;
> SET
> scratch=# explain analyze select count(1) from test where random >=
> 142907698
Oliver Jowett wrote:
> If you're unlucky, the server could go down while you're blocked waiting
> for a query response..
>
That is exactly what happens to us, and you have to be not so unlucky for
that happen if the engine have ~100 query at time.
Regards
Gaetano Mendola
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Oliver Jowett wrote:
If you're unlucky, the server could go down while you're blocked waiting
for a query response..
That is exactly what happens to us, and you have to be not so unlucky for
that happen if the engine have ~100 que
Tom Lane wrote:
> On the other hand, it seems to me a client-side SO_KEEPALIVE would only
> be interesting for completely passive clients (perhaps one that sits
> waiting for NOTIFY messages?) A normal client will try to issue some
> kind of database command once in awhile, and as soon as that ha
On K, 2005-05-18 at 12:57 +0200, Kaare Rasmussen wrote:
> Hi
>
> I have a dump from an Ingres database, one file per table it seems. I went
> looking on www.postgresql.org for documentation for people who want to move
> to PostgreSQL from other databases, but I couldn't find any such thing.
>
>
On Tue, 17 May 2005 22:12:17 -0700, "Jeffrey W. Baker" <[EMAIL PROTECTED]>
wrote:
>Incrementing random_page_cost from 4 (the default) to 5 causes the
>planner to make a better decision.
We have such a low default random_page_cost primarily to mask other
problems in the optimizer, two of which are
On Wed, 18 May 2005 01:12:26 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Wait, par for 32-bit CRCs? Or for 64-bit CRCs calculated using 32-bit ints?
>
>Right, the latter. We haven't actually tried to measure the cost of
>plain 32bit CRCs... although I seem to recall that when we originally
>deci
Hi
I have a dump from an Ingres database, one file per table it seems. I went
looking on www.postgresql.org for documentation for people who want to move
to PostgreSQL from other databases, but I couldn't find any such thing.
So, does a convert utility from ingres dump files to PostgreSQL alrea
Tom Lane said:
> Greg Stark <[EMAIL PROTECTED]> writes:
>> Tom Lane <[EMAIL PROTECTED]> writes:
>>> What it comes down to is that a mailing list encourages many-eyes-on-
>>> one-bug synergy, whereas Bugzilla is designed to send a bug report to
>>> just one pair of eyes, or at most a small number of
LAMBEAU Bernard wrote:
Hi,
On the TODO list, if found the following information :
Automatically create rules on views so they are updateable, per SQL99
Does anyone already work on such a tool inside PostgreSQL ? I'm
interessed by giving some contribution to this task ... if you're
interessed also ?
Hi,
On the TODO list, if found the following information :
Automatically create rules on views so they are updateable, per SQL99
Does anyone already work on such a tool inside PostgreSQL ? I'm
interessed by giving some contribution to this task ... if you're
interessed also ?
Bernard
--
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 18 May 2005 06:12
> To: Greg Stark
> Cc: Bruce Momjian; Manfred Koizar; Mark Cave-Ayland
> (External); pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations
>
>
> Greg Stark <[EM
On K, 2005-05-18 at 10:24 +0300, Hannu Krosing wrote:
> On T, 2005-05-17 at 22:37 -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > I don't understand why we are testing 64-bit CRC when I thought we
> > > agreed that 32-bit was good enough for our purposes.
> >
> > Well, we need to understan
On K, 2005-05-18 at 02:23 -0400, Bruce Momjian wrote:
> What we do now is not to require the reporter or the developers to
> classify the email traffic, and the burden is on the people looking for
> specific information to find it.
>
> I am not suggesting we change that, but this the trade-off we
On T, 2005-05-17 at 22:37 -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I don't understand why we are testing 64-bit CRC when I thought we
> > agreed that 32-bit was good enough for our purposes.
>
> Well, we need to understand exactly what is going on here. I'd not
> like to think that we
On T, 2005-05-17 at 11:22 -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > On T, 2005-05-17 at 00:42 -0400, Tom Lane wrote:
> >> I seem to recall some discussion of how to do this in the past;
> >> have you trolled the pghackers archives?
>
> > I think that Jasons inspiration
On E, 2005-05-16 at 12:35 -0400, Tom Lane wrote:
> Given the lack of impressive advantage to the 64-bit code even on 64-bit
> architectures, it might be best to go with the 32-bit code everywhere,
> but I also think we have grounds to file a gcc bug report.
Maybe on other platforms , but 20% on P
52 matches
Mail list logo
