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 Se
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
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-ru
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:
> 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 broadcast)
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| ht
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:
> > 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 inden
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
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,
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"
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 see
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:
T
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'
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 --
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 wi
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
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 woul
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
<[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
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,
(errmsg("request
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
> >
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 we
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 ma
[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_
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 fetch
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 BIGI
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 :/
>
>
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 - http:
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 cy
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
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
> >
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 trie
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 junctio
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 -fno-strict
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
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.
>
>
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.
NTFS5
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.
--
Neil Conway wrote:
> 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
>
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
> > 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 broadcast)---
42 matches
Mail list logo
