Christopher Kings-Lynne wrote:
> >>Errr, unlike all the other uses for alter table and friends? ie:
> >>
> >>OWNER TO
> >
> >Which changes the attributes of the table...
>
> And indexes.
Sure. But not *just* indexes.
> >>RENAME TO
> >
> >Same.
>
> And indexes.
It does? I thought the indexes
Tom Lane wrote:
[EMAIL PROTECTED] writes:
The improvements were REALLY astounding, and I would like to know if other
Linux users see this performance increase, I mean, it is almost 8~10 times
faster than using fsync.
Furthermore, it seems to also have the added benefit of reducing the I/O
storm
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> How is that possible? I have heaps of columns that use the timestamp type:
We don't make dependency entries for pinned objects (which includes all
built-in datatypes).
regards, tom lane
---(end
Hi,
I'm looking to find all records in pg_depend that show that some columns
in my db depend on the 'timestamp' type. So I do this:
select * from pg_depend where refclassid=1247 and refobjid=1114;
1257 is the oid of the pg_type table and 1114 is the oid of the
timestamp type.
It returns just t
On Monday 09 August 2004 13:15, Josh Berkus wrote:
> 1) track platform tests, namely which platforms have been tested, what they
> reported, and which have not, including soliciting on the lists for more
> platform testers;
I wonder, would folks be interested in keeping a "supported programs" list
> Okay, so theoretically it should work ... I'm trying it now to see
> if I can reproduce the problem locally.
It took several tries, but eventually I did reproduce it. It seems
the triggering condition is for the REDO pointer to be before the
checkpoint record itself. Not sure why, yet, but it
On 8/9/2004 7:41 PM, Gaetano Mendola wrote:
If I remember well this is the first command that need to change
GUC in order to change behaviour, I don't think we wrote:
set vacuum_mode = full;
set vacuum_verbosity = on;
vacuum;
You got a point here. However, we don't have
SELECT foo FROM bar WHER
[EMAIL PROTECTED] writes:
>> Just out of interest, what happens to the difference if you use *ext3*
>> (perhaps with data=writeback)
>
> Actually, I was working for a client, so it wasn't a general exploritory,
> but I can say that early on we discovered that ext3 was about the worst
> file system
> Just out of interest, what happens to the difference if you use *ext3*
> (perhaps with data=writeback)
Actually, I was working for a client, so it wasn't a general exploritory,
but I can say that early on we discovered that ext3 was about the worst
file system for PostgreSQL. We gave up on it an
Errr, unlike all the other uses for alter table and friends? ie:
OWNER TO
Which changes the attributes of the table...
And indexes.
RENAME TO
Same.
And indexes.
SET TABLESPACE
Which again changes the attributes of the table..
And indexes.
Chris
---(end of broadcast)--
Christopher Kings-Lynne wrote:
> >Hmm...not ALTER INDEX? Now that there's an operation that actually
> >modifies an index instead of the table itself, should there be an ALTER
> >INDEX? It would be cleaner and more consistent, IMO...
>
> Errr, unlike all the other uses for alter table and friend
Gaetano Mendola wrote:
> However I think is annoying to write:
>
> set vacuum_cost_delay = 100;
> vacuum table ;
> set vacuum_cost_delay = 0;
> set ;
> vacuum table ;
>
>
Well, you are already seting it to zero for night, so why not just set
it to non-zero for day? Seems the same to me
OKADA Satoshi <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Is this actually the official beta1 version, or is it a snapshot from
>> last week sometime?
>>
> I got it from
> ftp.postgresql.org/pub/source/v8.0.0beta/postgresql-8.0.0beta1.tar.gz, and
> xlog.c revision number is 1.157.
Okay, so
OK, added.
---
Christopher Kings-Lynne wrote:
> >>>1. there is no COMMENT ON TABLESPACE support
> >>
> >>That's right.
>
> That's deliberate.
>
> > Added to TODO:
> >
> > * Add COMMENT for tablespaces
>
> You may as
Tom Lane wrote:
>OKADA Satoshi <[EMAIL PROTECTED]> writes:
>
>>I'm testing PITR using pgbench and postgresql ver.8.0bata.
>>
>
>Is this actually the official beta1 version, or is it a snapshot from
>last week sometime?
>
I got it from
ftp.postgresql.org/pub/source/v8.0.0beta/postgresql-8.0.0bet
1. there is no COMMENT ON TABLESPACE support
That's right.
That's deliberate.
Added to TODO:
* Add COMMENT for tablespaces
You may as well make that:
* Add COMMENT ON for all cluster global objects (users, groups,
databases and tablespaces)
Chris
---(end of broadcast)
Hmm...not ALTER INDEX? Now that there's an operation that actually
modifies an index instead of the table itself, should there be an ALTER
INDEX? It would be cleaner and more consistent, IMO...
Errr, unlike all the other uses for alter table and friends? ie:
OWNER TO
RENAME TO
SET TABLESPACE
etc.
I wouldn't try this without running it against a test database copy first.
I've already discovered that a backend change to a column data type like your
describing can disrupt indexes, views, and analyze rows based on the table --
the last time I did such, I ended up having to dump and reload t
Let me be one of the first to say thank you to all of you guys for yet
another awesome version of PgSQL, beta or not. My company and I
appreciate all the hard work and such that has gone into making this
version happen. Keep up the good work and let me know where I can help.
Sincerely,
Gavin
Updated ...
On Mon, 9 Aug 2004, Marc G. Fournier wrote:
I'll be modifying that tonight ...
On Mon, 9 Aug 2004, Serguei A. Mokhov wrote:
Maybe this should be brought up-to-date slightly?
http://developer.postgresql.org/beta.php
Or maybe point elsewhere at least where the more up-to-date info actuall
Kevin Brown <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Use ALTER TABLE on the index.
> Hmm...not ALTER INDEX? Now that there's an operation that actually
> modifies an index instead of the table itself, should there be an ALTER
> INDEX? It would be cleaner and more consistent, IMO...
[ sh
Just out of interest, what happens to the difference if you use *ext3*
(perhaps with data=writeback)
regards
Mark
[EMAIL PROTECTED] wrote:
I did a little test on the various options of fsync.
...
create table testndx (value integer, name varchar);
create index testndx_val on testndx (value);
for
Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> Added to TODO:
>>>
>>> * Add COMMENT for tablespaces
> Oh, that shared thing! OK, removed.
Well, it's a legitimate thing to have in TODO, just as long as you don't
think it's trivial ;-). But don't we already have a TODO item about
properly support
On Sat, 07 Aug 2004 10:24:34 -0400, Jan Wieck <[EMAIL PROTECTED]>
wrote:
>I have not heard of "updatable subselects" yet.
http://asktom.oracle.com/pls/ask/f?p=4950:8:6693556430011788783::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:273215737113,
| Here we update a join. [...]
| [EMAIL PROTECTED]> upd
I'll be modifying that tonight ...
On Mon, 9 Aug 2004, Serguei A. Mokhov wrote:
Maybe this should be brought up-to-date slightly?
http://developer.postgresql.org/beta.php
Or maybe point elsewhere at least where the more up-to-date info actually
is.
--
Serguei A. Mokhov| /~\The ASCI
On Mon, Aug 09, 2004 at 06:47:45PM -0400, Bruce Momjian wrote:
> Gavin Sherry wrote:
> > Well, Chris did bring this up but it will have the same problem as other
> > shared tables, from memory. That is, you can add the comment in one
> > database, but wont see if from another.
>
> Oh, that shared
This is the kind of thing I can usually help with.
However, right now I'm a little swamped with customer work.
I can back someone up, though.
--elein
On Mon, Aug 09, 2004 at 06:28:33PM -0400, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Mon, 9 Aug 2004, Josh Berkus wrote:
> >
> > > Folk
On Mon, 9 Aug 2004, Hicham G. Elmongui wrote:
> Hi everybody,
> I never meant my emails to be spam. That's why i am just asking whether my
> questions here are out of subject. Typically my questions are about
> postgresql source code, like the question below. Please advise me whether
> i should fo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jan Wieck wrote:
| On 8/9/2004 1:19 PM, Gaetano Mendola wrote:
|
|> Jan Wieck wrote:
|>
|>> On 8/9/2004 7:19 AM, Gaetano Mendola wrote:
|>>
|>>> Hi all,
|>>> I have seen the big debat about to have the delay
|>>> off or on by default.
|>>>
|>>> Why not
Hello Peter,
backend/po/fr.po had 99% translations done for 7.4, and nos it is totally
missing for the current CVS tip (it is in the Attic)... why? Most
of those messasge are still applicable to the current, no? Commit message
from you from 2 weeks ago says:
2 weeks petere branch
Maybe this should be brought up-to-date slightly?
http://developer.postgresql.org/beta.php
Or maybe point elsewhere at least where the more up-to-date info actually
is.
--
Serguei A. Mokhov| /~\The ASCII
Computer Science Department | \ / Ribbon Campaign
Concordia University
On Thursday 05 August 2004 04:43 pm, Hicham G. Elmongui wrote:
> In "join_selectivity" function (plancat.c), a function call is made to
> "OidFunctionCall4" (fmgr.c), which in turn calls a function pointer.
>
> In need to know what is the actual function being called from
> OidFunctionCall4 if the
On 8/9/2004 3:46 PM, Bruce Momjian wrote:
Jan Wieck wrote:
On 8/8/2004 11:58 AM, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> The only open issue I see for beta1 is perhaps disabling vacuum delay.
>
> Given that Jan is clearly in the minority on that, I suggest we just
> turn it
Gavin Sherry wrote:
> On Mon, 9 Aug 2004, Bruce Momjian wrote:
>
> > Tom Lane wrote:
> > > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> > > > 1. there is no COMMENT ON TABLESPACE support
> > >
> > > That's right.
> >
> > Added to TODO:
> >
> > * Add COMMENT for tablespaces
>
> Well, Chr
[EMAIL PROTECTED] writes:
> The improvements were REALLY astounding, and I would like to know if other
> Linux users see this performance increase, I mean, it is almost 8~10 times
> faster than using fsync.
> Furthermore, it seems to also have the added benefit of reducing the I/O
> storm at checkp
On Mon, 9 Aug 2004, Bruce Momjian wrote:
> Tom Lane wrote:
> > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> > > 1. there is no COMMENT ON TABLESPACE support
> >
> > That's right.
>
> Added to TODO:
>
> * Add COMMENT for tablespaces
Well, Chris did bring this up but it will have the sa
[EMAIL PROTECTED] wrote:
> Furthermore, it seems to also have the added benefit of reducing the I/O
> storm at checkpoints over a system running with fsync off.
>
> I'm really serious about this, changing this one parameter had dramatic
> results on performance. We should have a general call to us
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> > 1. there is no COMMENT ON TABLESPACE support
>
> That's right.
Added to TODO:
* Add COMMENT for tablespaces
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (
Marc G. Fournier wrote:
> On Mon, 9 Aug 2004, Josh Berkus wrote:
>
> > Folks,
> >
> > Per our discussion earlier this year, I really think that we could shorten the
> > beta process and make it more effective if someone can step forward to be the
> > "8.0 Beta Leader." This person would have to:
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> > 1. there is no COMMENT ON TABLESPACE support
>
> That's right.
>
> > 2. how is one supposed to move indexes(not tables) to another tablespace?
>
> Use ALTER TABLE on the index.
Hmm...not ALTER INDEX? Now that there's an ope
> [EMAIL PROTECTED] writes:
>> I did a little test on the various options of fsync.
>
> There were considerably more extensive tests back when we created the
> different WAL options, and the conclusions seemed to be that the best
> choice is platform-dependent and also usage-dependent. (In particu
On Mon, 9 Aug 2004, Peter Eisentraut wrote:
Tom Lane wrote:
Would it be possible to automatically generate an un-fixed-up version
for beta releases? I'd rather have the right info in an ugly format
than the wrong info ...
In doc/src/, run "make man.tar.gz". The required software should be
listed
Tom Lane wrote:
> Would it be possible to automatically generate an un-fixed-up version
> for beta releases? I'd rather have the right info in an ugly format
> than the wrong info ...
In doc/src/, run "make man.tar.gz". The required software should be
listed in the documentation. I don't actua
[EMAIL PROTECTED] writes:
> I did a little test on the various options of fsync.
There were considerably more extensive tests back when we created the
different WAL options, and the conclusions seemed to be that the best
choice is platform-dependent and also usage-dependent. (In particular,
it ma
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> 1. there is no COMMENT ON TABLESPACE support
That's right.
> 2. how is one supposed to move indexes(not tables) to another tablespace?
Use ALTER TABLE on the index.
regards, tom lane
---(end of b
Hi everybody,
I never meant my emails to be spam. That's why i am just asking whether my
questions here are out of subject. Typically my questions are about
postgresql source code, like the question below. Please advise me whether
i should forward my questions to somewhere else.
Thanks a lot,
--h
Jan Wieck wrote:
> On 8/8/2004 11:58 AM, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> The only open issue I see for beta1 is perhaps disabling vacuum delay.
> >
> > Given that Jan is clearly in the minority on that, I suggest we just
> > turn it off for beta1. We can always
On 8/9/2004 1:19 PM, Gaetano Mendola wrote:
Jan Wieck wrote:
On 8/9/2004 7:19 AM, Gaetano Mendola wrote:
Hi all,
I have seen the big debat about to have the delay
off or on by default.
Why not enable it by default and introduce a new
parameter to vacuum command itself ? Something like:
VACUUM
Andreas Pflug wrote:
Tom Lane wrote:
Do we have a TODO for allowing users to
force switching to a new WAL file segment?
Together with PITR, this might make sense?
Another idea:
Has anyone tried to put the WAL segment directory on a cluster
filesystem and use that for cold (perhaps even hot) failo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alvaro Herrera wrote:
| On Mon, Aug 09, 2004 at 07:19:44PM +0200, Gaetano Mendola wrote:
|
|
|>So the other parameter will inserted in the new sintax too, I think is
|>fundamental
|>the ability of override this values during the vacuum call:
|>
|>VACUUM
Marc,
> Is there a reason why Bruce isn't doing it like he has for all previous
> releases? As he previously held such a role, shouldn't it be he calling
> for someone to take over that role from him?
Clearly I was confused about the import of a discussion we had on Core, some 3
months ago or
On Mon, 9 Aug 2004, Josh Berkus wrote:
Folks,
Per our discussion earlier this year, I really think that we could shorten the
beta process and make it more effective if someone can step forward to be the
"8.0 Beta Leader." This person would have to:
1) track platform tests, namely which platforms
On Mon, 2004-08-09 at 13:57, Peter Eisentraut wrote:
> Josh Berkus wrote:
> > Per our discussion earlier this year, I really think that we could
> > shorten the beta process and make it more effective if someone can
> > step forward to be the "8.0 Beta Leader." This person would have
> > to:
> >
On Mon, Aug 09, 2004 at 07:19:44PM +0200, Gaetano Mendola wrote:
> So the other parameter will inserted in the new sintax too, I think is
> fundamental
> the ability of override this values during the vacuum call:
>
> VACUUM WITH DELAY 100 [ ];
What's wrong with
SET vacuum_delat 100;
I did a little test on the various options of fsync.
I'm not sure my tests are scientific enough for general publication or
evaluation, all I am doing is performaing a loop that inserts a value into
a table 1 million times.
create table testndx (value integer, name varchar);
create index testndx_
I did a little test on the various options of fsync.
I'm not sure my tests are scientific enough for general publication or
evaluation, all I am doing is performaing a loop that inserts a value into
a table 1 million times.
create table testndx (value integer, name varchar);
create index testndx_v
Josh Berkus wrote:
> Per our discussion earlier this year, I really think that we could
> shorten the beta process and make it more effective if someone can
> step forward to be the "8.0 Beta Leader." This person would have
> to:
> 1) track platform tests, namely which platforms have been tested,
On 8/9/2004 12:53 PM, Josh Berkus wrote:
People,
> DELETE FROM target_tbl USING other_tbls WHERE ...
Feels much more understandable. The second FROM looks like a hickup.
Yes, although imagine:
DELETE FROM staff USING users JOIN logons USING (user_id)
WHERE last_logon < ( now() - '6 months');
On 08/09/04:32/1, Peter Eisentraut wrote:
> BitKeeper ist not open source, so it's out of the question for most
> people. Subversion is shockingly unstable. I'm very open for
> something that replaces CVS, but I'd rather not use any than one of
> these two.
>From my casual usage of svn, I hav
Jan Wieck wrote:
On 8/9/2004 7:19 AM, Gaetano Mendola wrote:
Hi all,
I have seen the big debat about to have the delay
off or on by default.
Why not enable it by default and introduce a new
parameter to vacuum command itself ? Something like:
VACUUM WITH DELAY 100;
It's not just one parameter
> Seems reasonable to me. A SRF function really ought to explicitly set
> isDone on every call anyway.
Aye, it seems reasonable, but a bit inconsistent with the effect of
ExecMakeFunctionResult, which does the same thing but bases the continuity of
the result gathering on the isDone pointer, whic
Hi!
I'm currently working on the psql tab-complete code, fixing quite a lot
of bugs/annoyances in the process.
One of the things I'm trying to do is syncing the available commands in
psql with the docs - during this work I found two irritating things
regarding tablespaces:
1. there is no COMMEN
OKADA Satoshi <[EMAIL PROTECTED]> writes:
> I'm testing PITR using pgbench and postgresql ver.8.0bata.
Is this actually the official beta1 version, or is it a snapshot from
last week sometime? In the first commit that had pg_start_backup(),
there wasn't any logic to ensure that the recovery repl
Josh Berkus <[EMAIL PROTECTED]> writes:
> Oh, and MySQL's "multi-table deletes": PLEASE tell me that's not
> SQL-standard.
It's not.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go t
Folks,
Per our discussion earlier this year, I really think that we could shorten the
beta process and make it more effective if someone can step forward to be the
"8.0 Beta Leader." This person would have to:
1) track platform tests, namely which platforms have been tested, what they
reporte
On 8/8/2004 11:58 AM, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
The only open issue I see for beta1 is perhaps disabling vacuum delay.
Given that Jan is clearly in the minority on that, I suggest we just
turn it off for beta1. We can always turn it on later if he manages
to convin
Jan Wieck <[EMAIL PROTECTED]> writes:
> What about
> DELETE FROM staff JOIN users ...
> then?
I don't much care for that, mainly because in my mind "x JOIN y" should
always be semantically equivalent to "y JOIN x". I think we want a real
clear syntactical separation between the deletion target ta
KL,
> Is it safe to update the atttypid of a timestamp column to be a
> timestamptz column? I wish to do this on a production database, so I
> need to be sure!
I wouldn't try this without running it against a test database copy first.
I've already discovered that a backend change to a column d
People,
> > DELETE FROM target_tbl USING other_tbls WHERE ...
>
> Feels much more understandable. The second FROM looks like a hickup.
Yes, although imagine:
DELETE FROM staff USING users JOIN logons USING (user_id)
WHERE last_logon < ( now() - '6 months');
Not as bad as FROM, but still a
On Monday 09 Aug 2004 9:18 pm, Robert Treat wrote:
> but I was pretty sure I had lpthread library on my machine (and verified
> this with some help from irc). however Makefile.global told me
>
> PTHREAD_CFLAGS = -pthread -D_REENTRANT -D_THREAD_SAFE
> -D_POSIX_PTHREAD_SEMANTICS
> PTHREAD_
Worked through some troubles on irc last night, thought I would post it in
case anyone else sees something similar.
system is Slackware 8.1, Linux phppgadmin 2.4.18 #2 Fri May 31 01:21:23 PDT
2002 i586 unknown
./configure was run with '--prefix=/usr/local/pgsql-8.0.0' '--enable-debug'
'--enab
On 8/9/2004 7:19 AM, Gaetano Mendola wrote:
Hi all,
I have seen the big debat about to have the delay
off or on by default.
Why not enable it by default and introduce a new
parameter to vacuum command itself ? Something like:
VACUUM WITH DELAY 100;
It's not just one parameter to tune here. It
Alvaro Herrera Munoz <[EMAIL PROTECTED]> writes:
> I think both VACUUM and ANALYZE could be best served by appropiate use
> of short-lived ResourceOwners. It needs some thought though.
At least for VACUUM FULL, this is pretty much a nonstarter: it needs a
real live genuine COMMIT in the middle.
Harald Fuchs <[EMAIL PROTECTED]> writes:
> Actually, MySQL supports two different syntaxes for multi-table DELETEs:
> 1. DELETE t1,t2 FROM t1,t2,t3 WHERE t1.id=t2.id AND t2.id=t3.id;
>(introduced in MySQL 4.0.0)
> 2. DELETE FROM t1,t2 USING t1,t2,t3 WHERE t1.id=t2.id AND t2.id=t3.id;
>(in
On 8/9/2004 12:29 AM, Tom Lane wrote:
Robert Treat <[EMAIL PROTECTED]> writes:
Well, as yall have pointed out, the feature is not sql spec (for some
reason I thought it had been put in) so since the update syntax seems
quite similar to oracles, perhaps they can provide a pointer on delete
syntax as
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I read this in the release notes:
> ---
> # Database-wide ANALYZE does not hold locks across tables (Tom)
> This reduces the potential for deadlocks against other backends that
> want exclusive locks on tables. To get the benefit of this chang
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Is it safe to update the atttypid of a timestamp column to be a
> timestamptz column?
For sufficiently small values of "safe", sure.
The problem is that unless you live in GMT zone, the interpretation
of values is different: the zero referenc
James William Pye <[EMAIL PROTECTED]> writes:
> While I was finishing up SRF support in PL/Py, I noticed that when VPC is the
> selected mode for a table function, ExecMakeTableFunctionResult will set
> rsinfo.isDone to ExprSingleResult each time it loops to fetch another value
> (when a direct_fun
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Marc G. Fournier wrote:
>>> Yeah, sure wish we could generate those man pages automatically :-(
>>
>> Is there a reason why we can't?
> Usually, you need to look them over and fix them up a bit. You also
> need a patched version of the processing t
On Mon, Aug 09, 2004 at 04:44:58PM +0800, Christopher Kings-Lynne wrote:
> I read this in the release notes:
>
> ---
> # Database-wide ANALYZE does not hold locks across tables (Tom)
>
> This reduces the potential for deadlocks against other backends that
> want exclusive locks on tables. To get
On Mon, 2004-08-09 at 05:19, Gaetano Mendola wrote:
> Hi all,
> I have seen the big debat about to have the delay
> off or on by default.
>
> Why not enable it by default and introduce a new
> parameter to vacuum command itself ? Something like:
>
>
> VACUUM WITH DELAY 100;
>
>
> this wil
Hi,
On Monday 09 August 2004 09:30, you wrote:
> Tom Lane wrote:
> > I haven't seen any particular reason why we should adopt another SCM.
> > Perhaps BitKeeper or SubVersion would be better for our purposes than
> > CVS, but are they enough better to justify the switchover costs?
>
> BitKeeper is
Hi all,
I have seen the big debat about to have the delay
off or on by default.
Why not enable it by default and introduce a new
parameter to vacuum command itself ? Something like:
VACUUM WITH DELAY 100;
this will permit to change easilly the delay in the maintainance
scripts.
Regards
Gaetan
In article <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> writes:
> Robert Treat <[EMAIL PROTECTED]> writes:
>> Well, as yall have pointed out, the feature is not sql spec (for some
>> reason I thought it had been put in) so since the update syntax seems
>> quite similar to oracles, perhaps the
Peter Eisentraut wrote:
Tom Lane wrote:
I haven't seen any particular reason why we should adopt another SCM.
Perhaps BitKeeper or SubVersion would be better for our purposes than
CVS, but are they enough better to justify the switchover costs?
BitKeeper ist not open source, so it's out of the que
I'm testing PITR using pgbench and postgresql ver.8.0bata.
I think that result of recovery is wrong. My test procedure
is as follows:
I edited postgresql.conf for PITR and started the postmaster.
And I executed "pgbench -t 2".
% pgbench -t 2
I did backup procedur
I read this in the release notes:
---
# Database-wide ANALYZE does not hold locks across tables (Tom)
This reduces the potential for deadlocks against other backends that
want exclusive locks on tables. To get the benefit of this change, do
not execute database-wide ANALYZE inside a transaction b
Is it safe to update the atttypid of a timestamp column to be a
timestamptz column? I wish to do this on a production database, so I
need to be sure!
Oh, and what about indexes on them? Do I just drop them beforehand and
recreate?
Chris
---(end of broadcast)---
Hi guys,
Is it safe to update the atttypid of a timestamp column to be a
timestamptz column? I wish to do this on a production database, so I
need to be sure!
Thanks,
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the
Tom Lane wrote:
> (a) And there would be untrusted code running as postgres exactly
> why?
Because someone has cracked the PostgreSQL server.
> (b) Seems to me the real security bug here is the mere existence of
> that ioctl call.
Probably. I'm just pointing out the findings about the environme
Tom Lane wrote:
> I haven't seen any particular reason why we should adopt another SCM.
> Perhaps BitKeeper or SubVersion would be better for our purposes than
> CVS, but are they enough better to justify the switchover costs?
BitKeeper ist not open source, so it's out of the question for most
pe
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Scott Marlowe
> Sent: 09 August 2004 06:31
> To: PostgreSQL-development
> Subject: [HACKERS] Windows binary in the beta directory?
>
> Since this is the first release supporting Windows natively,
>
Greets,
While I was finishing up SRF support in PL/Py, I noticed that when VPC is the
selected mode for a table function, ExecMakeTableFunctionResult will set
rsinfo.isDone to ExprSingleResult each time it loops to fetch another value
(when a direct_function_call). This makes the VPC-SRF author se
Marc G. Fournier wrote:
> > Yeah, sure wish we could generate those man pages automatically :-(
>
> Is there a reason why we can't?
Usually, you need to look them over and fix them up a bit. You also
need a patched version of the processing tools.
--
Peter Eisentraut
http://developer.postgresq
94 matches
Mail list logo
