On Sat, Mar 06, 2004 at 21:50:52 -0500,
Neil Conway <[EMAIL PROTECTED]> wrote:
> It seems to me the following should Just Work:
>
> nconway=# create table t1 (a timestamp);
> CREATE TABLE
> nconway=# insert into t1 values (now());
> INSERT 17164 1
> nconway=# insert into t1 values (now());
> INS
On Sun, 7 Mar 2004, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > Looks good here, even the docs :)
>
> Looks good from here too. I checked the full and partial .gz files,
> but not the bz2's.
all the bz2 files are are 'gunzip ; bzip2 ' ...
Marc G. Fournier
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Looks good here, even the docs :)
Looks good from here too. I checked the full and partial .gz files,
but not the bz2's.
regards, tom lane
---(end of broadcast)---
TIP 8: exp
after roughly 6
hours of constant updates and inserts...
I have absolutely no
clue as to how many transactions or how many updates or
inserts.
see
below.
Regards,
John
(applejack)
Mar 8 06:25:10 fred postgres[614]: [2-1]
ERROR: could not write block 2333 of relation 17142/2167288
Looks good here, even the docs :)
%tar tvzpf postgresql-7.4.2.tar.gz | egrep "man.tar.gz|postgres.tar.gz"
-rw-r--r-- pgsql/wheel 999890 Mar 7 21:48 2004 postgresql-7.4.2/doc/postgres.tar.gz
-rw-r--r-- pgsql/wheel 141828 Mar 7 21:48 2004 postgresql-7.4.2/doc/man.tar.gz
Marc G. Fournier
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Tom any chance you want to knock this ont out quickly so that it's
> included in 7.4.2? Otherwise I'll get to it as soon as I can.
No ... last-minute patches are a bad idea ... it'll have to be fixed
later.
(Marc, we're ready to wrap AFAIK.)
>
> I know Bruce did the RELEASE NOTES and all that week bit early, so I
> just want to make sure there is nothing outstanding before I package her
> up ...
>
> I'll do it around midnight GMT tonight baring any raised hands ...
I was hoping to have the pg_autovacuum fixes commited, but Tom found s
On 3 March 2004, at 19:52, Bruce Momjian wrote:
The advantage of symlinks is that an administrator could see how things
are laid out from the command line.
One thing to keep in mind is that system administrators don't see
symlinks as being informational -- they see them as the actual UI
for the red
Jochem van Dieten wrote:
Jan Wieck said:
The communication channels are "event" tables. The node daemons
use listen and notify to send messages from on to another.
Messages are only exchanged over this when the replication cluster
configuration is changed or every 10 seconds to tell "new
replicat
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This is something we need to consider, but we'll need more evidence
>> before making a choice. One thing that we have very little data about
>> is how much difference it makes in the quality of planner choices.
> Right, but is there a p
Tom Lane wrote:
This is something we need to consider, but we'll need more evidence
before making a choice. One thing that we have very little data about
is how much difference it makes in the quality of planner choices.
Right, but is there a practical way to actually get this data?
If the distri
Neil Conway <[EMAIL PROTECTED]> writes:
> Any comments on whether increasing the default stats target is a good
> idea for 7.5? (Details on the test I performed are included below)
This is something we need to consider, but we'll need more evidence
before making a choice. One thing that we have
From time to time, people on IRC ask for help with performance
problems, and the cause of the difficulty is ultimately traced to a
poor query plan that is chosen because default_statistics_target is
too low. While there will always need to be *some* tuning of the
statistics target by advanced u
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Here are the 7.4.2 release notes I made. I have a few question:
> What detail do we need on the pg_statistics alignment fix? Do we need
> to show an UPDATE query to fix database? What are the ramifications of
> leaving it alone?
Potential crashes :-(
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> I'll do it around midnight GMT tonight baring any raised hands ...
I am working on improving the release notes, but will have that commit
in within the next hour or two ...
regards, tom lane
---(end
Jan Wieck said:
>
> The communication channels are "event" tables. The node daemons
> use listen and notify to send messages from on to another.
> Messages are only exchanged over this when the replication cluster
> configuration is changed or every 10 seconds to tell "new
> replication data has
From: "Michael Meskes" <[EMAIL PROTECTED]>
> Why? What doesn't work? AFAIRC the AT statement does indeed allow a
> variable as connection_target.
Yeah, I was wrong there. I updated the thread test program in ecpg/test to
make use of this functionality - see patch in pgsql-patches yesterday.
L.
I know Bruce did the RELEASE NOTES and all that week bit early, so I just
want to make sure there is nothing outstanding before I package her up ...
I'll do it around midnight GMT tonight baring any raised hands ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org
Alex J. Avriette wrote:
On Fri, Mar 05, 2004 at 12:47:23AM +0100, Jochem van Dieten wrote:
>I personally don't think that a GUI tool should be the province of the
>Slony project. Seriously. I think that Slony should focus on a
I very much agree with this, but this is Jan's baby, so I didn't s
On Wed, Mar 03, 2004 at 07:40:40PM +0530, Shridhar Daithankar wrote:
> Is this fine?
> * Allow a 'connection *' pointer to be specified instead of a string to
> denote a connection.
> ...
I personally have no problem with this as long as it does not break
compatibility to the code we allow now.
On Wed, Mar 03, 2004 at 08:47:50AM -0500, Bruce Momjian wrote:
> > But yeah, specifying the connection by variable (be it string or
> > connection ptr) would be a definite step forward. Currently you cannot
> > write a generic function like:
> >
> > int getit(char *using_connection)
> > {
> >
21 matches
Mail list logo
