M') FROM pg_stat_activity WHERE
current_query LIKE '%';
--
Rod Taylor
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
PGP Key: http://www.rbt.ca/signature.asc
signature.asc
Description: This is a digitally signed message part
> I suspect (but cannot prove) that performance would jump for systems
> like ours if WAL was done away with entirely and the individual data
> files were synchronized on commit.
You know.. thats exactly what WAL is designed to prevent? Grab a copy of
7.0 and 7.1. Do a benchmark between the 2 wi
> > I can see that in a multipostmaster setting how you might want some
> > differentiation between postmasters, but ISTM that the tool reading these
> > logs should be trained in how to separate loglines out.
>
> Different postmasters = different conf files. Just set your syslog_facility
> and/
On Fri, 2004-03-12 at 13:30, Marc G. Fournier wrote:
> On Fri, 12 Mar 2004, Rod Taylor wrote:
>
> > Having all PostgreSQL related material under one domain is beneficial to
> > the project. Our big issue isn't the domain is too long, it is difficult
> > find the
On Fri, 2004-03-12 at 11:52, Jeroen T. Vermeulen wrote:
> On Fri, Mar 12, 2004 at 10:43:34AM -0600, Thomas Swan wrote:
> >
> > foundry.postgresql.org?
>
> Been through that one... Too long when you have to add project name as
> well.
I don't understand why. Presumably the postgresql.org website
On Thu, 2004-03-11 at 21:04, Marty Scholes wrote:
> I can see that and considered it.
>
> The seed state would need to be saved, or any particular command that is
> not reproducible would need to be exempted from this sort of logging.
>
> Again, this would apply only to situations where a small
> If a transaction will do large updates or inserts, why don't we just log
> the parsed statements in the WAL instead of the individual data blocks
UPDATE table SET col = random();
---(end of broadcast)---
TIP 2: you can get off all lists at onc
> >>After this is applied (fingers crossed) and everyone is happy, I will
> >>submit a patch to remove log_timestamp, log_pid and (if we are agreed on
> >>it) log_source_port.
> Is there agreement on removing these 3 config vars?
There is from me.
---(end of broadcast
On Mon, 2004-03-08 at 11:57, Joe Maldonado wrote:
> Hello,
> I see that there is an item "Queries across databases or servers (two-phase
> commit)" on the todo list's urgent header. I have tried asking this question on the
> other lists and have not yet gotten a suitable answer to this ques
On Mon, 2004-03-01 at 20:43, Bruno Wolff III wrote:
> On Mon, Mar 01, 2004 at 20:28:02 -0500,
> Tom Lane <[EMAIL PROTECTED]> wrote:
> > Michael Glaesemann <[EMAIL PROTECTED]> writes:
> > > In both cases, the CHECK constraint uses a function that is stable or
> > > volatile. It was suggested that
> Rod, can you lay out some psdueo code / logic involved in the process? I'm
> guessing you lock the entry in pg_class, you up dependent objects, lock them,
> update them all... is there more to it?
It was one an offline database at the time with only a single user -- so
locking wasn't a concer
> I vote for the GUC. Imho it is not comparable to the "autocommit" case,
> since it does not change the way your appl needs to react (appl needs to
> react to deadlock already).
Wrote one program a while ago that was very time sensitive. By the time
deadlock detection had been kicked off, the dat
> The question is whether we should have a GUC variable to control no
> waiting on locks or add NO WAIT to specific SQL commands.
>
> Does anyone want to vote _against_ the GUC idea for nowait locking. (We
> already have two voting for such a variable.)
I vote against. We got bit by both the reg
On Mon, 2004-02-16 at 13:03, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > The real question is why does DROP INDEX take more than a couple of
> > seconds to complete? It is not held up by locked.
>
> AFAICS it shouldn't take any time to complete.
I have an IO congested database (PostgreSQL 7.2) with too many
(overlapping) indexes, so the obvious solution is to drop them.
DROP INDEX seems to want to take several minutes to complete, which
causes a backup of clients and me to eventually abort the process to let
all the backed up queries go t
ike indexes to the new schema),
> but some form of this functionality would be a useful thing to add,
> IMHO.
It's not that hard to do either (I've done about 100 tables by hand at
this point).
Anyway, this should be supported by all RENAME commands, not just ALTER
TABLE.
--
Rod T
> and I'm willing to entertain other suggestions.
Very nice, but you missed the most important. Command Tag.
--
Rod Taylor
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
PGP Key: http://www.rbt.ca/rbtpub.asc
signature.asc
Description: This is a digitally signed message part
> > > BEGIN WORK;
> > > LOCK oldtab;
> > > CREATE_X TABLE newtab AS SELECT * FROM oldtab;
> > > DELETE oldtab;
> > > COMMIT
> > >
> > > In this case, you would want the database to abort on a syntax error, right?
> >
> > Certainly not if I was typing this from the command line. Imagine
> But for seperating out applications from each other, there's really
> nothing to be gained by putting each seperate database application into
> it's own cluster.
I believe the initial email requested individual logs, and presumably
the ability to grant superuser access without risking a user c
On Wed, 2004-02-11 at 22:30, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > There have been a few discussions about triggers on system tables in
> > the past and the problems with such triggers seem to be:
>
> I think the killer problem is that we couldn't allow triggers on system
On Tue, 2004-02-10 at 15:37, Robert Treat wrote:
> On Tue, 2004-02-10 at 13:20, Rod Taylor wrote:
> > > >http://www.microsoft.com/sql/yukon/productinfo/top30features.asp
> >
> > > Notice the Snapshot Isolation. Sounds like MVCC for MSSQL?
> >
> > Actu
> >http://www.microsoft.com/sql/yukon/productinfo/top30features.asp
> Notice the Snapshot Isolation. Sounds like MVCC for MSSQL?
Actually, the one I noticed was the ability to add or rebuild indexes on
the fly. That is a pretty slick trick.
---(end of broadcast)
On Mon, 2004-02-09 at 01:54, Alex J. Avriette wrote:
> On Sun, Feb 08, 2004 at 09:20:07PM -0500, Rod Taylor wrote:
> > On Sun, 2004-02-08 at 21:01, Alex J. Avriette wrote:
> > > On Sun, Feb 08, 2004 at 08:01:38PM -0500, Rod Taylor wrote:
> > >
> > > >
> replication. Am I hearing that nobody believes scalability is a
> concern? I think many of us would like to see features that would
> allow large scale installations to be more practical. I also think most
> of us would agree that the current "graft-on" replication methods are
> sub-ideal.
You
On Sun, 2004-02-08 at 21:01, Alex J. Avriette wrote:
> On Sun, Feb 08, 2004 at 08:01:38PM -0500, Rod Taylor wrote:
>
> > Replication won't help if those are all mostly write transactions. If a
> > small percentage, even 1% would be challenging, is INSERTS, UPDATES or
>
> The fact is, there are situations in which such extreme traffic is
> warranted. My concern is that I am not able to use postgres in such
> situations because it cannot scale to that level. I feel that it would
> be possible to reach that level with support in the postmaster for
> replication.
R
DB is hosed'.
One thing we could use (and I have no idea how to do it) is a "This
hardware is not appropriate for a database" test kit.
Something to detect lying disks, battery backed write cache that isn't
so battery backed, etc.
--
Rod Taylor
Build A Brighter Lamp
On Thu, 2004-02-05 at 15:37, Josh Berkus wrote:
> Folks,
>
> Just occurred to me that we have no code to prevent a user from running two
> simultaneos lazy vacuums on the same table.I can't think of any
> circumstance why running two vacuums would be desirable behavior; how
> difficult woul
our sort memory value (total sort memory for individual
backend -- not operation).
--
Rod Taylor
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
PGP Key: http://www.rbt.ca/rbtpub.asc
signature.asc
Description: This is a digitally signed message part
> As a more direct response, there *are* reasons for people to put ORDER
> BY in a subselect and expect it to be honored. The typical example
> that's been discussed several times in the archives is that you want to
> use an aggregate function that is sensitive to the ordering of its input
Not to
> The only question now is if it should be that we call the function with
> the variable x AS the value 13, or if we call the function with 13 AS the
> variable x. I.e.
...
> I don't know if one is more natural then the other in english. To my
> swedish ear both sounds as good. I like (x as 13) a
On Fri, 2004-01-23 at 16:00, Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Now I can start it up! Thanks!
>
> > What should I do now?
>
> Go home and get some sleep ;-). If the WAL replay succeeded, you're up
> and running, nothing else to do.
Granted, running out o
> Rewriting the declaration seems like a workable solution, but it
> would break the transparency of the client/server encoding conversion.
> Also, some people might dislike that their documents are being changed
> as they are stored.
I presume that the XML type stores the textual representat
> Anything other than simple, short commands is a waste, IMHO. I can easily
> remember SHOW DATABASES and SHOW TABLES and DESC , because they
> reflect
> my intensions directly and 'make sense'.
Can you remember how to get a list of indexes on a particular table? How
about a specific indexes bui
On Mon, 2003-12-22 at 10:55, Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
> > In that sample mentioned the index might be used mostly with a,b
> > columns. Dropping the index silently might damage the application
> > because it relies on an (a,b) index to be present. IMHO only Inde
On Thu, 2003-12-18 at 10:20, Tom Lane wrote:
> Is there any good reason for this restriction?
>
> regression=# begin;
> BEGIN
> regression=# declare c cursor for select * from tenk1 for update;
> ERROR: DECLARE CURSOR ... FOR UPDATE is not supported
> DETAIL: Cursors must be READ ONLY.
>
> Whil
> k, there was no options file already, so I just added it containing the
> one line ...
>
> And tested in on GNUMakefile.in, and appears okay:
>
> #
> # $PostgreSQL: pgsql-server/GNUmakefile.in,v 1.36 2003/11/28 20:32:09 pgsql Exp $
> #
Looks good. Once you are comfortable with the changes, you
> > Looks good. Once you are comfortable with the changes, you will need to
> > add another line to CVSROOT/options to disable processing of the $Id$
> > and $Header$ tags should one accidentally be added.
> >
> > tagexpand=iPostgreSQL
>
> 'K, where do you find docs on the options file? t
On Thu, 2003-11-27 at 09:28, Stephen Frost wrote:
> * Bruno Wolff III ([EMAIL PROTECTED]) wrote:
> > On Thu, Nov 27, 2003 at 09:15:20 -0500,
> > Stephen Frost <[EMAIL PROTECTED]> wrote:
> > > I don't believe it's possible, currently, to correctly import this
> > > data with copy. I'm not sur
On Thu, 2003-11-27 at 00:50, Marc G. Fournier wrote:
> Based on discussions on -hackers, and baring any objections betwen now and
> then, I'm going to go through all files in CVS and change:
>
> $Id$ -> $PostgreSQL$
>
> I will do this the evening of Friday, November 29th ...
I presume you
On Wed, 2003-11-26 at 23:32, Marc G. Fournier wrote:
> On Wed, 26 Nov 2003, Rod Taylor wrote:
>
> > > So, what does changing it to $PostgreSQL$ do? Or am I reading the wrong
> > > part of the manual?
> >
> > After applying the patch in -patches to CVSRO
> So, what does changing it to $PostgreSQL$ do? Or am I reading the wrong
> part of the manual?
After applying the patch in -patches to CVSROOT and running the update
script...
It will allow Chris and other to import the PostgreSQL source into their
own CVS tree without having do to a ton of dif
On Thu, 2003-11-20 at 08:34, Rod Taylor wrote:
> > I think maybe the simplest thing is for me to prepare a patch that rips
> > that code out and replaces it with a (slightly simpler - less umask
> > hacking required, I think) piece of code that I will write.
>
> The Fre
On Mon, 2003-11-24 at 01:07, Christopher Kings-Lynne wrote:
> Hi,
>
> Is there demand for this syntax:
>
> ALTER SEQUENCE ON table(col) CYCLE 100;
>
> It would allow us to become sequence-name independent...
I think the right approach to this problem would be to implement
IDENTITIES and GENERAT
> >CREATE TABLE a (col integer primary key);
> >CREATE TABLE b (col integer primary key);
> >ALTER TABLE a ADD FOREIGN KEY (col) REFERENCES b INITIALLY DEFERRED;
> >ALTER TABLE b ADD FOREIGN KEY (col) REFERENCES a;
> Still, using cyclic references is IMHO bad design style. I can't accept
They'r
On Sat, 2003-11-22 at 16:53, Andreas Pflug wrote:
> Stephan Szabo wrote:
>
> >You're going to potentially have the constraints scattered in any case due
> >to circular dependency chains. I'd think that having all the constraints
> >in one place would be easier than trying to go through the list of
> I don't have a better choice of name offhand, but if we spend 1% of the
> time already spent arguing about these issues on finding a better name,
> I'm sure we can think of one ;-)
virtual (attvirtnum)
external (attextnum)
atttisoywnum -> attribute this is the one you want number
---
> I think maybe the simplest thing is for me to prepare a patch that rips
> that code out and replaces it with a (slightly simpler - less umask
> hacking required, I think) piece of code that I will write.
The FreeBSD folks sorted it out for us.
Everyones names should be in the copyright for th
On Wed, 2003-11-19 at 11:17, Don Sceifers wrote:
> My company is fairly new at Postgresql, but we have hit a problem, where
> we modify a table using ALTER, and our stored procedures stop working. We
> have a grasp as to why this happens, but I was wondering if this v7.4
> upgrade fixes this issue?
On Tue, 2003-11-18 at 14:33, James Rogers wrote:
> Hi folks,
>
> Is there any pre-existing protocol for a company to pay for specific
> features to be added to PostgreSQL?
There are several people who do this type of work (Neil, Joe, David, the
folks are Command Prompt Inc., etc.).
Personally, I
On Mon, 2003-11-17 at 20:24, Christopher Kings-Lynne wrote:
> > Right -- AFAICS, the only change in COPY compatibility would be if you
> > COPY TO'd a table and then changed the logical column order in some
> > fashion, you would no longer be able to restore the dump (unless you
> > specified a col
The PostgreSQL group has recently had a patch submitted with a snippet
of code from FreeBSDs src/bin/mkdir/mkdir.c.
http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c?annotate=1.27
Is this intentionally under the 4 clause license or does the copyright
from the website (2 clause) applied
-- moving to -hackers
> Do you have special cases for type changes which don't need data
> transforms.
> I mean things like changing VARCHAR(10) to VARCHAR(20), dropping the NOT
> NULL constraint or changing CHECK A < 3 to CHECK A < 4.
There are basically 3 types of change.
The first is simpl
-- moved to -hackers
On Thu, 2003-11-13 at 11:35, Hannu Krosing wrote:
> Rod Taylor kirjutas N, 13.11.2003 kell 16:59:
> >
> > Can you please suggest a better term to use in place of TRANSFORM?
> > Perhaps UPDATE WITH?
>
> or perhaps USING, based loosely on our u
On Tue, 2003-11-11 at 14:29, Peter Eisentraut wrote:
> Marc G. Fournier writes:
>
> > > Do we have any data on how many people download the partial tarballs
> > > (-base, -opt, etc.)? I have a feeling that more people are confused by
> > > them than use them.
> >
> > on ftp.postgresql.org itself,
On Thu, 2003-11-06 at 10:35, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> >> -> Hash Join (cost=3D1230.79..60581.82 rows=3D158 width=3D54)=
> > (actual time=3D1262.35..151200.29 rows=3D1121988 loops=3D1)
> >> Hash Cond: ("outer".ac
a large
I think there are a number of people out there who would be willing to
do this, myself included.
--
Rod Taylor
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: don't forget to increa
> > Could we see the pg_stats rows for service.account_id and
> > account.account_id?
Sorry, ignore previous numbers. My prior tests were done in a
transaction (to roll back stats changes) and I forgot to re-analyze.
relname | attname | stanullfrac | stawidth | stadistinct | stakind1
| staki
On Thu, 2003-11-06 at 10:35, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> >> -> Hash Join (cost=3D1230.79..60581.82 rows=3D158 width=3D54)=
> > (actual time=3D1262.35..151200.29 rows=3D1121988 loops=3D1)
> >> Hash Cond: ("outer".ac
On Wed, 2003-11-05 at 19:18, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Effectively, the planner has amazingly inaccurate row estimates.
>
> It seems the key estimation failure is in this join step:
>
> -> Hash Join (cost=1230.79..60581
On Wed, 2003-11-05 at 18:57, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> >> I'm not sure if that will actually change the default_statistics_target
>
> > Hmm.. I was under the impression that it would work for any tables that
> > haven't
> I'm not sure if that will actually change the default_statistics_target of
> the tables you're analyzing, I think it will only apply to newly created
> tables.
>
> I believe you have to alter table alter column set statistics 1000 for
> each column you want a statistic of 1000. You might w
Since this is a large query, attachments for the explains / query.
Configuration:
dev_iqdb=# select version();
version
PostgreSQL 7.4beta1 on i386-portbld-freeb
On Tue, 2003-11-04 at 14:14, Joshua D. Drake wrote:
> Hello,
>
> As Command Prompt is about to release it's Replication product we are
> open sourcing our
> pgManage. pgManage is similar to pgAdmin but as it is java based it is
> truly cross platform
> and should easily support most if not all
On Sat, 2003-11-01 at 20:58, Mark Wong wrote:
> I don't remember making a conscious decision between the number and integer
> database type. Is that a significant oversight on my part?
Numerics do exact math with support for arbitrary numbers. Unlike
Oracle, PostgreSQL does not retype NUMBER to
Excellent.
I just noticed that most of the numbers in the system are given the
numeric data type. Is there any particular reason you don't use integer
(test enforced?)?
On Fri, 2003-10-31 at 19:18, [EMAIL PROTECTED] wrote:
> I thought someone might be interested in a data point I have comparing
>
On Wed, 2003-10-29 at 06:54, Thiago Fernandes Moesch wrote:
>I have a comment on something like that to: Why - when creating a view
> using explicit * on select - postgresql reads all the fields in the query
> and especify them one by one on the view definition? Developers always have
> to chec
On Tue, 2003-10-28 at 19:34, scott.marlowe wrote:
> On Tue, 28 Oct 2003, Tom Lane wrote:
>
> > "scott.marlowe" <[EMAIL PROTECTED]> writes:
> > > Is it possible to remove the implicit search path of pg_catalog from a
> > > psql session without it breaking lots of stuff?
> >
> > Do you consider "+
On Tue, 2003-10-28 at 18:49, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > I say leave it the way it is. If you want system table tab completion,
> > simply:
> > ALTER USER ... SET search_path =3D pg_catalog,...;
>
> Unfortunately, that *do
> Anyway, it seems like we need a vote to see how many people prefer
> each choice.
I say leave it the way it is. If you want system table tab completion,
simply:
ALTER USER ... SET search_path = pg_catalog,...;
I would like to see the information_schema be a part of the default
search_p
Linux ns2 2.4.20-xfs #2 Tue Apr 15 10:04:43 EDT 2003 i686 unknown
<-- SNIP -->
stats... FAILED
== shutting down postmaster ==
===
1 of 93 tests failed.
===
*** ./expected/stats.outSat Se
> >Nay... I would expect a PostgreSQL specific information_schema to get
> >just as much mucking around as the system tables, which means you are
> >still maintaining a set of queries per release.
> >
> >
> The problem about information_schema is that it's restricted to show
> objects of the own
On Wed, 2003-10-22 at 12:08, scott.marlowe wrote:
> On Wed, 22 Oct 2003, Tom Lane wrote:
>
> > Rod Taylor <[EMAIL PROTECTED]> writes:
> > > That said, perhaps the TODO for changing LIMIT / OFFSET to be expression
> > > based should also mention bumping them
On Wed, 2003-10-22 at 10:22, Christopher Kings-Lynne wrote:
> > I see you're point, but nobody is going to be interested in the first 2
> > billion rows of a table without using a cursor and having some other
> > process do the math in the background.
>
> You have the same problem:
> test=# move
On Wed, 2003-10-22 at 04:01, Christopher Kings-Lynne wrote:
> Hi guys,
>
> What is the limit on the number of rows in a PostgreSQL table? If it's
> more than MAXINT, we have a problem:
>
> phppgadmin# select * from test limit 2147483648;
> ERROR: integer out of range
>
> Same problem with OFF
On Tue, 2003-10-21 at 21:24, Christopher Kings-Lynne wrote:
> > There is always the biggest evil of all... Putting SHOW / DESCRIBE /
> > HELP commands into the backend itself. I'm sure the pgAdmin group likes
> > that idea (they're probably tired of maintaining 4 different versions of
> > queries f
On Tue, 2003-10-21 at 09:33, Andreas Pflug wrote:
> Rod Taylor wrote:
>
> >
> >Of course, psql has the same issue in hiding functionality that doesn't
> >exist. My biggest beef is the psql help is often misleading if you're
> >connected to a different back
On Tue, 2003-10-21 at 09:03, Andreas Pflug wrote:
> Rod Taylor wrote:
>
> > I'm sure the pgAdmin group likes that idea (they're probably tired of maintaining
> > 4 different versions of
> >queries for getting a list of tables). Any solution to make psql backwar
On Tue, 2003-10-21 at 00:08, Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > It had occurred to me that we could move support for each version of the
> > backend into a shared lib.
> > eg. libpsql70.so, libpsql71.so, etc.
> > Then all we do is load the appropriate lib and
On Mon, 2003-10-20 at 23:15, Christopher Kings-Lynne wrote:
> > I suppose if all you want is backward compatibility which makes sense
> > for pg_dump, but surely psql should be forward thinking.
> >
> > Normally it's old clients with new server, not the other way around --
> > at least with big co
On Mon, 2003-10-20 at 22:39, Christopher Kings-Lynne wrote:
> > The tricky part seems to be dealing with i10n issues since the text to
> > translate would be release specific it needs to go into the backend --
> > but that isn't so nice.
>
> Why tricky? I'm just going to make the 7.5 psql utility
> Going forward if we put the sql for all the psql commands into fuctions,
> then psql could be less tied to the backend version. I thought this was
> a TODO item already.
The tricky part seems to be dealing with i10n issues since the text to
translate would be release specific it needs to go int
On Fri, 2003-10-17 at 10:22, Tom Lane wrote:
> Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > What part of plain vacuum takes disk bandwidth?
>
> Reading (and possibly rewriting) all the pages.
Would it be possible for the backend to keep a list of the first N (N
being a large number but not
> So, pg_autovacuum does deal with them separately, but doesn't make an
> effort to spread out the vacuums if all / multiple databases happen to
> need it at the same time.
>
> In practice, I don't see this as a big problem right now, but it should
> still be handled better by pg_autovacuum.
I un
> The vacuum man page says, "FREEZE is not recommnded for routine use".
> That was enough to keep me away. However if vacuum freeze was
> considerably lighter than normal database wide vacuums then there might
> be an advantage to using it. Especially since when pg_autovaccum
> decides it's tim
> > I wouldn't want the whole diff on the mail, but a link to the relevant
> > diffs in cvsweb would be most useful (one for each changed file -- not ideal,
> > but much better than nothing). You're not the first one to suggest it ...
>
> I agree, it would be very useful. Marc, would it be possib
> >> Some dumb-user/fat-finger/ooops protection is surely welcome, but there
> >> is a limit. A system console has to be behind a locked door instead of
> >> the single-user boot being root-password protected. As soon as people
> >
> > Unfortunately, as more and more companies start to outsourc
On Mon, 2003-10-13 at 21:26, Jan Wieck wrote:
> Rod Taylor wrote:
> >> >> > Allow superuser (dba?) the ability to turn off foreign key checks/all
> >> >> > constraints/triggers, not settable from postgresql.conf?
> >> >>
> >> >&
> I think another way it could be handled is with nested transactions.
> Just have the promise phase be an inner transaction commit but have an
> outer transaction bracket that one for the actual commit.
Not really. In the event of a crash, most 2PC systems will expect the
participant to come back
> >> > Allow superuser (dba?) the ability to turn off foreign key checks/all
> >> > constraints/triggers, not settable from postgresql.conf?
> >>
> >> Is that one really necessary for 7.4 now that adding foreign keys is
> >> apparently much faster?
> If you reconfigure your systems to force fs
May have posted this earlier...
It would seem that caching the plans for foreign keys has some unwanted
side effects.
test=# select version();
version
PostgreSQL 7.4beta4 on i386-portbld-fr
Below is a short script which causes an error in the foreign key plan
caching. It appears to cause the error with or without the transaction,
but closing the connection between steps causes it to go away.
Can the cache be cleared after each statement?
Error reported:
psql:/home/rbt/bugte
On Thu, 2003-10-09 at 11:14, Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > If you want cross-server transactions, what other methods are there that
> > are more reliable?
>
> 3-phase commit
How about a real world example of a transaction manager that has
actually implemented 3PC?
But ye
On Tue, 2003-10-07 at 21:31, Christopher Kings-Lynne wrote:
> > Should we add a variable that is set from the dump filew that identifies
> > the version of PostgreSQL that generated the dump?
> >
> > SET dumped_version = 7.3
>
> With something like that, does it have to be reissued after ever
Below is a 7.2.4 example of the rserv log with inet data type. You will
notice that inet cast to text, and the log entry are differently (one
from unknown directly to text via a trigger, the other from inet cast to
text).
I see this hasn't been changed in the 7.4 version. Is there intent on
removi
> It almost certainly would, but I was assuming we had to consider this in
> the context of loading existing dump files. We could think about having
> pg_dump emit an automatic ANALYZE after the data loading step in the
> future though.
Rather than running ANALYZE, how about simply dumping out an
> Hm. The parallel regression tests require at least 20. I deliberately
> allowed initdb to select values as small as 10 on the theory that
> installing and not being able to run the parallel regression tests is
> better than not installing at all. Does anyone want to argue the
> opposite? Perh
On Tue, 2003-09-30 at 00:10, Steve Yalovitser wrote:
> Hello,
>
> I'd like to know if its possible to coopt the postgres storage subsystem to
> rely entirely on ram based structures, rather than disk. Any documentation
> or ideas would be appreciated.
Just so you know, this isn't going to make th
>+ CREATE SCHEMA: Sometimes a schema created in PostgreSQL
> disappears if there is nothing in it.
If true, this would be a bug. Do you have a reproducible test case?
>+ CREATE INDEX: PostgreSQL should allow specifying a namespace
> for the index, even if the namespace is requi
> For example, if you have a timestamp index and you routinely clean out
> all entries older than N-days-ago, you won't have a problem in 7.4.
> If your pattern is to delete nine out of every ten entries (maybe you
> drop minute-by-minute entries and keep only hourly entries after awhile)
> then y
301 - 400 of 994 matches
Mail list logo
