On Mon, Oct 04, 2004 at 03:10:24PM -0400, Alvaro Herrera wrote:
So you aren't aware of the dollar-quoting feature? You may want to take
a look at that ...
Can someone point me to a url? I haven't been able to find anything
about this...
--
Jim C. Nasby, Database Consultant
On Wed, Oct 06, 2004 at 01:34:00AM -0500, Jim C. Nasby wrote:
On Mon, Oct 04, 2004 at 03:10:24PM -0400, Alvaro Herrera wrote:
So you aren't aware of the dollar-quoting feature? You may want to take
a look at that ...
Can someone point me to a url? I haven't been able to find anything
hardlinks and junctions don't work across physical disks, only symlinks.
Where did you read this? I just looked and can see no such restriction.
There is no such restriction for junctions, I just tried it to be safe.
Andreas
---(end of
On Fri, 2004-10-01 at 06:48, Bruce Momjian wrote:
Yes, that is what I am thinking. I have worked around other bugs in the
C code before by doing things with the shell script though this problem
seems hard to clean up with a shell script. I found GNU indent to be
even harder to fix.
Have you
I have checked current CVS and the kerberos configuration stuff has
changed since 7.4.X, but it doesn't use the krb5_prefix/bin/krb5-config
idea you have.
Would you download a recent snapshot and resubmit a patch that works
against our current configure code? Thanks.
Zeugswetter Andreas SB SD schrieb:
hardlinks and junctions don't work across physical disks, only symlinks.
Where did you read this? I just looked and can see no such restriction.
There is no such restriction for junctions, I just tried it to be safe.
Yes, sorry. I had old NTFS4 information.
Reini Urban said:
Zeugswetter Andreas SB SD schrieb:
hardlinks and junctions don't work across physical disks, only
symlinks.
Where did you read this? I just looked and can see no such
restriction.
There is no such restriction for junctions, I just tried it to be
safe.
Yes, sorry. I had old
Alvaro Herrera [EMAIL PROTECTED] writes:
On Wed, Oct 06, 2004 at 01:34:00AM -0500, Jim C. Nasby wrote:
On Mon, Oct 04, 2004 at 03:10:24PM -0400, Alvaro Herrera wrote:
So you aren't aware of the dollar-quoting feature? You may want to take
a look at that ...
Can someone point me to a url? I
I'm getting the following build failure in pl/perl on Win32. I'm
guessing this has something to do with the recent rehashing of
make/include files, but I don't know what exactly. This is on a fresh
checkout.
Regards, Dave.
make[3]: Entering directory `/cvs/pgsql/src/pl/plperl'
gcc -O2
Andrew Dunstan wrote:
Reini Urban said:
Zeugswetter Andreas SB SD schrieb:
hardlinks and junctions don't work across physical disks, only
symlinks.
Where did you read this? I just looked and can see no such
restriction.
There is no such restriction for junctions, I just tried it to be
Bruce Momjian schrieb:
Andrew Dunstan wrote:
Reini Urban said:
Zeugswetter Andreas SB SD schrieb:
hardlinks and junctions don't work across physical disks, only
symlinks.
Where did you read this? I just looked and can see no such
restriction.
There is no such restriction for junctions, I just
Reini Urban wrote:
Bruce Momjian schrieb:
Andrew Dunstan wrote:
Reini Urban said:
Zeugswetter Andreas SB SD schrieb:
hardlinks and junctions don't work across physical disks, only
symlinks.
Where did you read this? I just looked and can see no such
restriction.
There is no such
OK, I have adjusted the code to use #define for the plperl compile.
This should prevent the conflict you are getting when perl defines uid_t
too.
---
Dave Page wrote:
I'm getting the following build failure in pl/perl on
On Mon, Oct 04, 2004 at 02:42:43PM -0400, Greg Stark wrote:
Mark Wong [EMAIL PROTECTED] writes:
Links to results are here:
7.5devel - http://www.osdl.org/projects/dbt2dev/results/dev4-010/128/
8.0beta3 - http://www.osdl.org/projects/dbt2dev/results/dev4-010/180/
Are those cyclic spikes
On Wed, Oct 06, 2004 at 10:01:42AM -0700, Mark Wong wrote:
On Mon, Oct 04, 2004 at 02:42:43PM -0400, Greg Stark wrote:
Mark Wong [EMAIL PROTECTED] writes:
Links to results are here:
7.5devel - http://www.osdl.org/projects/dbt2dev/results/dev4-010/128/
8.0beta3 -
Is this fixed?
---
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Maybe we could avoid removing it until the next checkpoint? Or is that
not enough. Maybe it could stay there forever :/
Part of
I can confirm this bug still exists in CVS.
---
Joe Conway wrote:
I see this behavior with CVS tip:
CREATE TABLE wibble (a integer, b integer);
INSERT INTO wibble VALUES (1,1);
ALTER TABLE wibble ADD COLUMN c BIGINT;
Christopher Kings-Lynne wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
OK, I can do this, but I don't think I'll have time for the first beta.
No problem.
Another interesting think I noticed in pg_dump is dumping of LOBs. It
seems to declare a cursor that fetches the blobs
[EMAIL PROTECTED] wrote:
Hi Every one.
At least I made PITR working however I still have 2 questions:
1) It seems there is a slight bug in this case:
select pg_backup_start('test);
... make backup
select pg_backup_end();
psql database
drp table note the time in logs
pg_ctl stop
Bruce Momjian [EMAIL PROTECTED] writes:
Is this fixed?
Yes.
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not
Quite some time ago, Heikki Linnakangas [EMAIL PROTECTED] wrote:
I haven't received any comments and there hasn't been any discussion on
the implementation, I suppose that nobody has given it a try. :(
I finally got around to taking a close look at this. There's a good bit
undone, as you well
Bruce Momjian [EMAIL PROTECTED] wrote on 06.10.2004, 21:15:34:
[EMAIL PROTECTED] wrote:
Hi Every one.
At least I made PITR working however I still have 2 questions:
1) It seems there is a slight bug in this case:
select pg_backup_start('test);
... make backup
select
This case in xlog.c is representative of a disease that pgindent has had
for awhile:
@@ -4276,7 +4300,8 @@ StartupXLOG(void)
if (needNewTimeLine)/* stopped because of stop request */
ereport(FATAL,
[EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
... you end up with a core dump (signal 6) and an error saying that you
can't stop before end of backup.
Was this corrected? I don't see any followups to it in the archives.
Not by me, though I was definitely working on crash recovery
Tom Lane wrote:
At the API level, I like the PREPARE/COMMIT/ROLLBACK statements, but I
think you have missed a bet in that it needs to be possible to issue
COMMIT PREPARED gid for the same gid several times without error.
Consider a scenario where the transaction monitor crashes during the
commit
Oliver Jowett [EMAIL PROTECTED] writes:
At the API level, I like the PREPARE/COMMIT/ROLLBACK statements, but I
think you have missed a bet in that it needs to be possible to issue
COMMIT PREPARED gid for the same gid several times without error.
Isn't this usually where the GTM would issue
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
At the API level, I like the PREPARE/COMMIT/ROLLBACK statements, but I
think you have missed a bet in that it needs to be possible to issue
COMMIT PREPARED gid for the same gid several times without error.
Isn't this usually where the GTM
On Wed, 2004-10-06 at 18:50, Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
At the API level, I like the PREPARE/COMMIT/ROLLBACK statements, but I
think you have missed a bet in that it needs to be possible to issue
COMMIT PREPARED gid for the same gid several times without error.
Oliver Jowett [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, the question is how long must the individual databases retain
state with which to answer recover requests.
As I understand it, you don't need to keep state for committed txns,
I think that's clearly wrong:
TM -- DB:
On Wed, Oct 06, 2004 at 05:46:10PM -0400, Tom Lane wrote:
You were concerned about how to mark prepared transactions in pg_clog,
given that Alvaro had already commandeered state '11' for
subtransactions. Since only a toplevel transaction can be prepared,
it might work to allow state '11'
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, the question is how long must the individual databases retain
state with which to answer recover requests.
As I understand it, you don't need to keep state for committed txns,
I think that's clearly wrong:
TM
Alvaro Herrera [EMAIL PROTECTED] writes:
I am concerned with a different issue: what issues arise regarding
snapshots? Do concurrent xacts see a prepared one as running? I'm not
sure but I think so. So they have to be able to at least get its Xid,
no?
Hmm, that's a good point. It seems
Rod Taylor wrote:
On Wed, 2004-10-06 at 18:50, Tom Lane wrote:
Well, the question is how long must the individual databases retain
state with which to answer recover requests. I don't like forever,
so I'm proposing that there should be an explicit command to say you
can forget about this gid.
On Thu, 23 Sep 2004, Josh Berkus wrote:
For anyone who doesn't know what I'm talking about, it's this form:
CREATE PROCEDURE do_some_work ( alpha INT, beta INT, gamma TEXT )
etc.
Where you can:
CALL do_some_work( alpha = 5, beta = 7 )
.. and then gamma picks up its default, if any, or
Hi,
I saw a initdb crashes when it is creating the template1 database. I
couldn't figure out what is wrong. I attached the backtrace and some
architecture/compiler info.
If someone needs more info, drop me a line.
=
Euler Taveira de Oliveira
euler[at]yahoo_com_br
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
and this does exactly as you describe by putting the comment on its own
line. I just changed it to:
...
so that the new comment will have the same indenting as the else that
was input.
If it were the else's indent plus one more
Tom Lane wrote:
This case in xlog.c is representative of a disease that pgindent has had
for awhile:
@@ -4276,7 +4300,8 @@ StartupXLOG(void)
if (needNewTimeLine)/* stopped because of stop request */
ereport(FATAL,
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I can confirm this bug still exists in CVS.
I have a fix for this, but cannot commit just yet as we seem to be
having network problems again :-(
Yes, I have already beeped Marc.
--
Bruce Momjian|
Bruce Momjian [EMAIL PROTECTED] writes:
I can confirm this bug still exists in CVS.
I have a fix for this, but cannot commit just yet as we seem to be
having network problems again :-(
regards, tom lane
---(end of
Bruce Momjian [EMAIL PROTECTED] writes:
and this does exactly as you describe by putting the comment on its own
line. I just changed it to:
...
so that the new comment will have the same indenting as the else that
was input.
If it were the else's indent plus one more tab it would be
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
If it were the else's indent plus one more tab it would be reasonably
sane; it'd match the indentation of what comes next.
OK, I can do that but consider:
[ other case ]
Just out of curiosity, what will pgindent do when re-run on the
On Wed, 6 Oct 2004, Euler Taveira de Oliveira wrote:
Hi,
I saw a initdb crashes when it is creating the template1 database. I
couldn't figure out what is wrong. I attached the backtrace and some
architecture/compiler info.
If someone needs more info, drop me a line.
Can you run initdb with
Gavin,
My real question, however, is do we want default values at all. Josh has
been fairly keen on them but I haven't seen much outright support for the
idea other than Joe and Joshua (perhaps a few others) putting the argument
that anything which eases the burden of migration from SQL
43 matches
Mail list logo
