On Sun, Oct 13, 2002 at 10:59:40PM -0700, Joe Conway wrote:
> Well, if we were specifying the timeout in microseconds instead of seconds,
> it would make sense to have better resolution. But when you can only
> specify the timeout in seconds, the internal time comparison doesn't need
> to be an
On Fri, Oct 11, 2002 at 12:07:00PM -0400, Neil Conway wrote:
> [ pgsql-patches removed from Cc: list ]
>
> Anuradha Ratnaweera <[EMAIL PROTECTED]> writes:
> > I am trying to add some replication features to postgres (yes, I
> > have already looked at ongoing work), in a peer to peer manner.
>
>
Bruce Momjian wrote:
> It could be argued that our seconds are not as exact as they could be
> with subsecond timing. Not sure it is worth it, but I can see the
> point.
Well, if we were specifying the timeout in microseconds instead of seconds, it
would make sense to have better resolution. Bu
On 14 Oct 2002 at 11:55, Anuradha Ratnaweera wrote:
> On Fri, Oct 11, 2002 at 07:10:26PM +0530, Shridhar Daithankar wrote:
> > On 11 Oct 2002 at 8:30, Greg Copeland wrote:
> >
> > > I'd be curious to hear in a little more detail what constitutes "not
> > > good" for postgres on a mosix cluster.
On Fri, Oct 11, 2002 at 07:10:26PM +0530, Shridhar Daithankar wrote:
> On 11 Oct 2002 at 8:30, Greg Copeland wrote:
>
> > I'd be curious to hear in a little more detail what constitutes "not
> > good" for postgres on a mosix cluster.
>
> Well, I guess in kind of replication we are talking here,
On Fri, Oct 11, 2002 at 08:30:55AM -0500, Greg Copeland wrote:
>
> I'd be curious to hear in a little more detail what constitutes "not
> good" for postgres on a mosix cluster.
It seems that almost all the postgres processes remain in the `home'
node.
Please notice that I am not underestimating
Joe Conway wrote:
> Bruce Momjian wrote:
> > So, this is what needs to be dealt with to get it working.
> >
>
> More to the point, why is sub-second precision needed in this function?
> Connection timeout is given to us in whole seconds (1.205 code, i.e. prior to
> the patch in question):
>
>
Bruce Momjian wrote:
> So, this is what needs to be dealt with to get it working.
>
More to the point, why is sub-second precision needed in this function?
Connection timeout is given to us in whole seconds (1.205 code, i.e. prior to
the patch in question):
remains.tv_sec = atoi(conn->c
Denis A Ustimenko wrote:
> On Sun, Oct 13, 2002 at 09:02:55PM -0700, Joe Conway wrote:
> > Denis A Ustimenko wrote:
> > >>Bruce, why have all precise time calculations been droped out in 1.206?
> > >>If there is no
> > >>gettimeofday in win32?
> >
> > gettimeofday was not portable to win32 (at l
OK, I would like to shoot for 7.3 final in the next few weeks. Can we
get some of these items completed so we can make that happen and move on
to 7.4? Remeber, PITR and Win32 are waiting!
Let me comment on these:
---
On Sun, Oct 13, 2002 at 09:02:55PM -0700, Joe Conway wrote:
> Denis A Ustimenko wrote:
> >>Bruce, why have all precise time calculations been droped out in 1.206?
> >>If there is no
> >>gettimeofday in win32?
>
> gettimeofday was not portable to win32 (at least not that I could find) and
> henc
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Mon, 14 Oct 2002, Tom Lane wrote:
>> I was wondering whether an ALTER TABLE command is really the right way
>> to approach this. If we had an ALTER-type command, presumably the
>> implication is that its effects would be global to all backends.
Tom Lane wrote:
> I was wondering whether an ALTER TABLE command is really the right way
> to approach this. If we had an ALTER-type command, presumably the
> implication is that its effects would be global to all backends. But
> the uses that I've seen for suspending trigger invocations would b
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Well, I thought I did it, and it did work on my limited number of test
> > cases. Seems you got it fully working.
>
> Actually, it failed for me (and evidently for Barry) on exactly the test
> case you posted along with the patch.
Tom Lane wrote:
> I was wondering whether an ALTER TABLE command is really the right way
> to approach this. If we had an ALTER-type command, presumably the
> implication is that its effects would be global to all backends. But
> the uses that I've seen for suspending trigger invocations would b
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Do we want to look at this as a bug (okay to fix for 7.3) or a new
> >> feature (wait for 7.4)?
>
> > I don't think we can say \copy missing columns is a bug; we never had
> > it in previous release. Seems like
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Do we need an initdb to fix command tags? I thought that was just a
> > change in the Query structure.
>
> A change in Query struct breaks stored rules. Looks like initdb
> material to me ...
Oh, I forgot about stored rules. Yep,
On Mon, 14 Oct 2002, Tom Lane wrote:
> I was wondering whether an ALTER TABLE command is really the right way
> to approach this. If we had an ALTER-type command, presumably the
> implication is that its effects would be global to all backends. But
> the uses that I've seen for suspending trigg
Gavin Sherry <[EMAIL PROTECTED]> writes:
> On Sat, 12 Oct 2002, Joe Conway wrote:
>> Tom Lane wrote:
>>> Hackers: we might reasonably fix this by doing a deep copy of the
>>> relcache's trigger info during initResultRelInfo(); or we could fix it
>>> by getting rid of ri_TrigDesc and re-fetching fr
Denis A Ustimenko wrote:
>>Bruce, why have all precise time calculations been droped out in 1.206? If there is
>no
>>gettimeofday in win32?
gettimeofday was not portable to win32 (at least not that I could find) and
hence broke the win32 build of the clients.
Joe
---
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Do we want to look at this as a bug (okay to fix for 7.3) or a new
>> feature (wait for 7.4)?
> I don't think we can say \copy missing columns is a bug; we never had
> it in previous release. Seems like a missing feature. The COPY
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Do we need an initdb to fix command tags? I thought that was just a
> change in the Query structure.
A change in Query struct breaks stored rules. Looks like initdb
material to me ...
regards, tom lane
---
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Well, I thought I did it, and it did work on my limited number of test
> cases. Seems you got it fully working.
Actually, it failed for me (and evidently for Barry) on exactly the test
case you posted along with the patch. You said
> test=> set autoc
Tom Lane wrote:
> Isn't this a bug?
>
> regression=# create table FOO (f1 int);
> CREATE TABLE
> regression=# \copy FOO from stdin
> ERROR: Relation "FOO" does not exist
> \copy: ERROR: Relation "FOO" does not exist
> regression=#
>
> This happens because \copy takes the given table name and s
Tom Lane wrote:
> Bruno Wolff III <[EMAIL PROTECTED]> writes:
> > On Sat, Oct 12, 2002 at 12:43:37 +0300,
> > Antti Haapala <[EMAIL PROTECTED]> wrote:
> >> What about copy? AFAIK, copy doesn't allow column names being specified,
> >> so it's not purely aesthetic...
>
> > The SQL COPY command do
> Is it worth an initdb for 7.3b3 to fix this? I think we were already
> considering forcing one for the command-tag issues, otherwise I'd
> probably vote "no". Comments?
Do we need an initdb to fix command tags? I thought that was just a
change in the Query structure.
---
Tom Lane wrote:
> Barry Lind <[EMAIL PROTECTED]> writes:
> > Below is the current behavior (based on a fresh pull from cvs this morning):
> > Current State ActionEnd State
> > ACon and NITset ACon ACon and NIT
> > set
- Forwarded message from Bruce Momjian <[EMAIL PROTECTED]> -
I don't know. Would you ask hackers list, and perhaps CC the author of
that patch.
---
Denis A Ustimenko wrote:
> Bruce, why have all precise time calcul
Gavin Sherry wrote:
> On Sat, 12 Oct 2002, Joe Conway wrote:
>
> > Tom Lane wrote:
> > > Hackers: we might reasonably fix this by doing a deep copy of the
> > > relcache's trigger info during initResultRelInfo(); or we could fix it
> > > by getting rid of ri_TrigDesc and re-fetching from the relc
I said:
> Bruce was supposed to fix this. We agreed that a SET command would
> never initiate a transaction block on its own. Looks like it's not
> there yet ---
Now it is. Give it another try ...
regards, tom lane
---(end of broadcast)
Patrick Welche <[EMAIL PROTECTED]> writes:
> I just cut and pasted someone's mac address:
> patrimoine=# update ethernet set mac='00-00-39-AB-92-FO' where id=623;
> UPDATE 1
> patrimoine=# select mac from ethernet where id=623;
> mac
> ---
> 00:00:39:ab:92:0f
> (1
Barry Lind <[EMAIL PROTECTED]> writes:
> Below is the current behavior (based on a fresh pull from cvs this morning):
> Current State ActionEnd State
> ACon and NITset ACon ACon and NIT
> set ACoff ACoff and IT
I just cut and pasted someone's mac address:
patrimoine=# update ethernet set mac='00-00-39-AB-92-FO' where id=623;
UPDATE 1
patrimoine=# select mac from ethernet where id=623;
mac
---
00:00:39:ab:92:0f
(1 row)
Note the typo "O" instead of "0". I can see how tha
On Sat, 12 Oct 2002 23:37:18 -0700
Joe Conway <[EMAIL PROTECTED]> wrote:
> Masaru Sugawara wrote:
> > I'm hoping that dblink_exec() returns something like warning if those
> > who intend to do transactions make a declaration of
> > blink_exec('dbname=some', 'begin') by mistake.
> >
> > for exampl
I was spending some time investigating how to fix the jdbc driver to
deal with the autocommit functionality in 7.3. I am trying to come up
with a way of using 'set autocommit = on/off' as a way of implementing
the jdbc symantics for autocommit. The current code just inserts a
'begin' after ev
35 matches
Mail list logo
