Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2005-01-17 at 01:19 -0500, Tom Lane wrote:
>> Just to be clear: what I understand the logic to be is "OR" across
>> multiple switches of the same type, but "AND" across switches of
>> two types.
> If I understand you correctly, you're suggesting th
On Mon, 2005-01-17 at 01:19 -0500, Tom Lane wrote:
> Just to be clear: what I understand the logic to be is "OR" across
> multiple switches of the same type, but "AND" across switches of
> two types.
If I understand you correctly, you're suggesting that we should only
report an error if none of th
Neil Conway <[EMAIL PROTECTED]> writes:
> So the behavior would be that suggested earlier by David Skoll:
>> pg_dump -t t1 -- Dump table t1 in any schema
>> pg_dump -n s1 -- Dump all of schema s1
>> pg_dump -t t1 -n s1-- Dump t1
Neil Conway <[EMAIL PROTECTED]> writes:
> FYI, IBM has applied for a patent on ARC (AFAICS the patent application
> is still pending, although the USPTO site is a little hard to grok):
> http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm
On Mon, 2005-01-17 at 00:54 -0500, Tom Lane wrote:
> -t s1.t1
> [...] without any quoting rules it would then become impossible to
> deal with names containing dots.
Ah, yeah -- sorry, I was focusing on case conversion rather than quoting
in general.
> Are we willing to blow off that case?
On Tue, 2005-01-11 at 08:04 -0800, Darcy Buskermolen wrote:
> IBM has just announced they are waving all rights and providing access to 500
> patents. In the list of 500 there are several that relate RDBMS and query
> optimizations, it may be worth a look.
FYI, IBM has applied for a patent on A
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2005-01-17 at 00:24 -0500, Tom Lane wrote:
>> A little further down-thread there was some discussion of also allowing
>> wild cards in the individual switches,
> Is this actually useful behavior?
Possibly not. It's been requested often enough, bu
On Mon, 2005-01-17 at 00:24 -0500, Tom Lane wrote:
> A little further down-thread there was some discussion of also allowing
> wild cards in the individual switches, eg
>
> -t 's1.*'
>
> (This would differ from '-n s1' in that a -t switch would restrict the
> dump to tables only, whereas -n
Neil Conway <[EMAIL PROTECTED]> writes:
> Something like the design elaborated here:
> http://archives.postgresql.org/pgsql-patches/2004-07/msg00374.php
> looks good to me, and would be preferrable to Andreas' patch IMHO.
> Unless I'm missing something, I don't see a patch from David Skoll in
> t
On Mon, 17 Jan 2005, Bruce Momjian wrote:
Is it time to branch for 8.1? We are packaging 8.0.0 on Monday.
this late, may as well do the branch as part of the tag itself ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!:
Bruce Momjian writes:
> Is it time to branch for 8.1? We are packaging 8.0.0 on Monday.
At this point I suppose we should make the branch immediately after
tagging 8.0.0. We delayed it long enough that there's no point in
an earlier branch.
regards, tom lane
--
Is it time to branch for 8.1? We are packaging 8.0.0 on Monday.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtow
Neil Conway wrote:
> On Sun, 2005-01-16 at 23:42 -0500, Bruce Momjian wrote:
> > I don't remember this patch.
>
> http://archives.postgresql.org/pgsql-patches/2004-07/msg00331.php
>
> > How is it related to the other pg_dump
> > patches in the 8.1 pathces queue?
>
> I missed the July '04 discuss
On Sun, 2005-01-16 at 23:42 -0500, Bruce Momjian wrote:
> I don't remember this patch.
http://archives.postgresql.org/pgsql-patches/2004-07/msg00331.php
> How is it related to the other pg_dump
> patches in the 8.1 pathces queue?
I missed the July '04 discussion about the other patches for impro
Neil Conway wrote:
> On Fri, 2005-01-14 at 16:24 +0100, Andreas Joseph Krogh wrote:
> > http://dev.officenet.no/~andreak/pg_dump.c.diff
>
> Looks good, except for some minor code cleanups and doc updates. Barring
> any objections, I'll clean it up and apply it once we branch 8.0. I
> suppose for c
On Fri, 2005-01-14 at 16:24 +0100, Andreas Joseph Krogh wrote:
> http://dev.officenet.no/~andreak/pg_dump.c.diff
Looks good, except for some minor code cleanups and doc updates. Barring
any objections, I'll clean it up and apply it once we branch 8.0. I
suppose for consistency we ought to allow mu
Devrim GUNDUZ wrote:
> These are the latest updates:
Installed.
> BTW... Peter, we see some errors on postgres-tr.po file, on nlsstatus
> page
> (http://developer.postgresql.org/~petere/nlsstatus/po-current/postgre
>s-tr.po.err) po/postgres-tr.po:9383: number of format specifiers in
> msgid and m
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Actually, I guess I wasn't understanding the problem to begin with.
> You'd never go from new tuple to known good while the transaction that
> created the tuple was in-flight, right?
By definition, not.
> If that's the case, I'm not sure
> where there'
On Sun, Jan 16, 2005 at 07:28:07PM -0600, Jim C. Nasby wrote:
> On Sun, Jan 16, 2005 at 08:01:36PM -0500, Tom Lane wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > Wouldn't the original proposal that had a state machine handle this?
> > > IIRC the original idea was:
> >
> > > new tuple
On Sun, Jan 16, 2005 at 08:01:36PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Wouldn't the original proposal that had a state machine handle this?
> > IIRC the original idea was:
>
> > new tuple -> known good -> possibly dead -> known dead
>
> Only if you disallow the
On Sun, 16 Jan 2005 20:01:36 -0500, Tom Lane wrote:
> "Jim C. Nasby" writes:
>> Wouldn't the original proposal that had a state machine handle this?
>> IIRC the original idea was:
>>
>> new tuple -> known good -> possibly dead -> known dead
>
> Only if you disallow the transition from possibly de
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Wouldn't the original proposal that had a state machine handle this?
> IIRC the original idea was:
> new tuple -> known good -> possibly dead -> known dead
Only if you disallow the transition from possibly dead back to known
good, which strikes me as a
On Sun, Jan 16, 2005 at 03:22:11PM -0500, Tom Lane wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
> > Manfred Koizar <[EMAIL PROTECTED]> writes:
> >> Last time we discussed this, didn't we come to the conclusion, that
> >> resetting status bits is not a good idea because of possible race
> >> condit
On Sun, 16 Jan 2005 20:49:45 +0100, Manfred Koizar wrote:
> On Thu, 13 Jan 2005 00:39:56 -0500, Tom Lane wrote:
>> A would-be deleter of a tuple would have to go and clear the "known
>> good" bits on all the tuple's index entries before it could commit.
>> This would bring the tuple back into the "
Tom Lane <[EMAIL PROTECTED]> writes:
> Manfred Koizar <[EMAIL PROTECTED]> writes:
>> Last time we discussed this, didn't we come to the conclusion, that
>> resetting status bits is not a good idea because of possible race
>> conditions?
> There's no race condition,
Actually, wait a minute --- you
Manfred Koizar <[EMAIL PROTECTED]> writes:
> On Thu, 13 Jan 2005 00:39:56 -0500, Tom Lane <[EMAIL PROTECTED]>
> wrote:
>> A would-be deleter of a tuple would have to go and clear the "known
>> good" bits on all the tuple's index entries before it could commit.
>> This would bring the tuple back int
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> On Sat, 15 Jan 2005, Tom Lane wrote:
>> Right. The 2PC connection is another reason to do it that way --- 2PC
>> would require some way to save locks anyhow, and it'd be nice if there
>> were only one mechanism to deal with not two.
> AFAICS, heap_
On Sat, 15 Jan 2005, Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Hackers,
In access/heap/heapam.c, in heap_mark4update(), there's a comment that
states
/*
* XLOG stuff: no logging is required as long as we have no
* savepoints. For savepoints private log co
On Thu, 13 Jan 2005 00:39:56 -0500, Tom Lane <[EMAIL PROTECTED]>
wrote:
>A would-be deleter of a tuple would have to go and clear the "known
>good" bits on all the tuple's index entries before it could commit.
>This would bring the tuple back into the "uncertain status" condition
>where backends wo
Hi,
Never mind about the "permission denied errors" I tracked it down to a bug
in the LIBC port's handling of doing an unlink...
So it would appear the port mostly works barring the problems with the
LIBC implementation.
Lorne
--
---
[EMA
Mark Wong wrote:
Ah, so you beat me to it Neil. ;) Out of curiosity, how much worse
was it before you started fixing things?
As I recall, not too different than things are today -- sparse flagged a
bunch of stylistic issues that I fixed, like:
void some_func() { ... } => void some_func(void) { .
31 matches
Mail list logo
