Hi all,
Was just discussing the issues related to the above off list with Magnus:
http://archives.postgresql.org/pgsql-hackers-win32/2004-03/msg00041.php
Whilst we can think of a number of work-arounds (the simplest being a
suggestion by Magnus: set a flag, like APCcalled, to false before the
On Mon, Mar 08, 2004 at 02:07:35AM +0200, Marko Karppinen wrote:
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 redirection in question. So their expectation is that they'll
be able to move the actual
Andrew Sullivan wrote:
eorganise the disks, assuming that the database
just has its own home. For such a sysadmin, a pile of symlinks would
be fair game for reorganisation.
Please take into consideration that symlinks might be every day work for
*nix admins, but for win admins it's very
Tom Lane wrote:
Dennis Haney [EMAIL PROTECTED] writes:
Joining {b,c} to {a} does not meet any of those four allowed cases.
Exactly my point... So why ever bother creating the {b,c} node which is
legal by the above definition?
We don't, because
Hi gang,
Is there a datatype that means one byte? I'm importing a database from
SQL Server, and some of the rows there are of this type. When I convert
them to int2, I have discrepancies with the program that uses the
database (OLE DB uses binary mode transfers, so the size of the variable
is
Bruno Wolff III [EMAIL PROTECTED] writes:
Neil Conway [EMAIL PROTECTED] wrote:
It seems to me the following should Just Work:
nconway=# select avg(a) from t1;
ERROR: function avg(timestamp without time zone) does not exist
While there is a way to calculate an average timestamp, I don't
Hello,
this is my first post, so Hello again :)
I have a problem. I am trying to create another implementation of FTI in
PG. What will be different? I am going to create my new index on text
type field:
CREATE TABLE test (id int, mytext text);
CREATE INDEX myindex on test USING myindex
Dennis Haney [EMAIL PROTECTED] writes:
Exactly my point... So why ever bother creating the {b,c} node which is
legal by the above definition?
We don't, because there is no such join clause.
No, but we create the equality via the implied equality mechanism...
select * from a, b where
Shachar Shemesh [EMAIL PROTECTED] writes:
Is there a datatype that means one byte?
You might be able to use the char type (note the quotes). I am not
sure how well it will cope with storing zeroes (nulls) though.
regards, tom lane
---(end of
Tom Lane wrote:
[SNIP: a repetion of my first post ;) ]
I think it should be
/*
* If we already joined IN's RHS to anything else in
* either input path, then this join is not constrained (the
* necessary work was done at a lower level).
Tom Lane wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
Is there a datatype that means one byte?
You might be able to use the char type (note the quotes). I am not
sure how well it will cope with storing zeroes (nulls) though.
regards, tom lane
Hmm, this will also screw up
Hello,
I see that there is an item Queries across databases or servers (two-phase
commit) on the todo list's urgent header. I have tried asking this question on the other
lists and have not yet gotten a suitable answer to this question...When is this functionality
expected to be
Hi all,
I am using Binary Cursor to retrive data(polygnos) from my DB. However, when I
dump the data into a file I get a bunch of meanless data, in other works, I
see one big string of data that makes no sense to me.
Question:
1) how can I convert that data back to a readble interger/double
On Mon, 2004-03-08 at 11:57, Joe Maldonado wrote:
Hello,
I see that there is an item Queries across databases or servers (two-phase
commit) on the todo list's urgent header. I have tried asking this question on the
other lists and have not yet gotten a suitable answer to this
Neil,
In the simple test I performed, raising the default_statistics_target
from 10 to 25 resulted in a 40% increase in the time to ANALYZE a
large table. (I picked 25 more or less at random -- would 15 or 20 be
better?)
I find that very interesting, since I haven't found much higher
On Mon, 08 Mar 2004 12:18:22 -0500, Rod Taylor [EMAIL PROTECTED] wrote:
On Mon, 2004-03-08 at 11:57, Joe Maldonado wrote:
Hello,
I see that there is an item Queries across databases or servers (two-phase
commit) on the todo list's urgent header. I have tried asking this question on the
Rod Taylor wrote:
On Mon, 2004-03-08 at 11:57, Joe Maldonado wrote:
I see that there is an item Queries across databases or servers
(two-phase commit) on the todo list's urgent header. I have tried
asking this question on the other lists and have not yet gotten a
suitable answer to this
On Mon, Mar 08, 2004 at 09:12:52PM +1100, Claudio Natoli wrote:
Hi all,
Was just discussing the issues related to the above off list with Magnus:
http://archives.postgresql.org/pgsql-hackers-win32/2004-03/msg00041.php
Whilst we can think of a number of work-arounds (the simplest being a
Josh Berkus [EMAIL PROTECTED] writes:
It is. I've found that problem queries, especially those caused by real,
uneven distribution of data, require raising statistics to 150-400 in order
to fix. This is much to high a level to assign as a default.
That's basically what's bothering me
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
It is. I've found that problem queries, especially those caused by real,
uneven distribution of data, require raising statistics to 150-400 in order
to fix. This is much to high a level to assign as a default.
That's basically
Bruce Momjian [EMAIL PROTECTED] writes:
Do all the columns have to have the same number of statistics buckets?
They do not, but the effort spent by ANALYZE is proportional to the
largest stats target among all the columns of the table.
regards, tom lane
Tom,
Further, in 7.5 we'll be introducing correlated stats for multi-column
indexes
(unless something's gone off with that?)
This was discussed on Hackers in October, a complete implementation was shown,
I thought it was committed at that time. If not, what happened to it?
Dammit, it's
It would be wonderful to be able to create comments
on users and groups. In particular, I need a place
to store the user's name. Yes, I could make a user
table, but that seems overkill as all of the other
aspects of a user are already in the metadata.
Best,
Clark
--
Clark C. Evans
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Do all the columns have to have the same number of statistics buckets?
They do not, but the effort spent by ANALYZE is proportional to the
largest stats target among all the columns of the table.
Could we use previous stats to
Jan Wieck wrote:
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
Clark C. Evans [EMAIL PROTECTED] writes:
It would be wonderful to be able to create comments
on users and groups. In particular, I need a place
to store the user's name. Yes, I could make a user
table, but that seems overkill as all of the other
aspects of a user are already in the
Tom Lane wrote:
Clark C. Evans [EMAIL PROTECTED] writes:
It would be wonderful to be able to create comments
on users and groups. In particular, I need a place
to store the user's name. Yes, I could make a user
table, but that seems overkill as all of the other
aspects of a user are
Josh Berkus [EMAIL PROTECTED] writes:
Further, in 7.5 we'll be introducing correlated stats for multi-column
indexes (unless something's gone off with that?)
This was discussed on Hackers in October, a complete implementation was shown,
I thought it was committed at that time. If not,
Tom,
Are you sure you're not thinking of stats for functional indexes?
Positive.I even remember seeing that the patch was accepted.
The patch specifically had to do with a multi-column correlation algorithm for
improving the selectivity of multi-column indexes.
Problem is, with 1400
Bruce Momjian wrote:
Another problem is that pg_description is per-database, while
pg_user/group are global for all databases.
databases are also per cluster, but we have comments on those.
Could we keep the user/group comments in those tables instead of in
pg_description?
cheers
andrew
It's rumoured that Andrew Dunstan once said:
Bruce Momjian wrote:
Another problem is that pg_description is per-database, while
pg_user/group are global for all databases.
databases are also per cluster, but we have comments on those.
Could we keep the user/group comments in those tables
Andrew Dunstan wrote:
Bruce Momjian wrote:
Another problem is that pg_description is per-database, while
pg_user/group are global for all databases.
databases are also per cluster, but we have comments on those.
Could we keep the user/group comments in those tables instead of in
This doesn't look good. If we throw a WARNING, why do we not insert
anything into pg_description. Seems we should throw an error, or do the
insert with a warning.
---
Mike Mascari wrote:
Andrew Dunstan wrote:
Bruce
Bruce Momjian wrote:
This doesn't look good. If we throw a WARNING, why do we not insert
anything into pg_description. Seems we should throw an error, or do the
insert with a warning.
It essentially makes the behavior deprecated and allows dumps to be
restored properly (without the
Rod Taylor [EMAIL PROTECTED] writes:
Comments longer than ~7k would need a toast table. At the moment, toast
tables don't work on a global basis.
Sure they do ... in fact, all the shared catalogs have one.
I think the idea of putting comments directly into pg_shadow and friends
is too icky to
Rod Taylor wrote:
On Mon, 2004-03-08 at 14:46, Andrew Dunstan wrote:
Bruce Momjian wrote:
Another problem is that pg_description is per-database, while
pg_user/group are global for all databases.
databases are also per cluster, but we have comments on those.
Could we keep the
Magnus Hagander [EMAIL PROTECTED] writes:
To me this sounds like we have to make a general solution, and not win32
specific, to get the socket calls out of the signal handler.
Hold on one second here. I thought this thread was discussing some
local problem in the Win32 workaround for lack of
Rod Taylor wrote:
-- Start of PGP signed section.
On Mon, 2004-03-08 at 15:46, Bruce Momjian wrote:
This doesn't look good. If we throw a WARNING, why do we not insert
anything into pg_description. Seems we should throw an error, or do the
insert with a warning.
It used to be an error,
The postmaster's use of nominally unsafe stuff in signal
handlers is not
and never has been a problem, because there is only one place in the
main loop where signals are unblocked, thus no possibility for
something
to interrupt something else. I don't like the idea of
redesigning that
I know folks are waiting for things from me (patches applied, changes
made). I took the weekend off to relax and am know pedaling as fast as I
can.
FYI, my upcoming trips look like:
May - Zurich
June - Germany (Linuxtag)
July - Oregon (O'Reilly)
September - China,
PITR Functional Design v2 for 7.5
[EMAIL PROTECTED]
Currently, PostgreSQL provides Crash Recovery but not yet full Point In
Time
Recovery (PITR). The following document provides a design which enhances
the existing robustness features to include full PITR. Since one of the
primary objectives for
Bruce Momjian
Simon Riggs wrote:
User-selectable behaviour? OK. That's how we deal with fsync; I can
relate to that. That hadn't been part of my thinking because of the
importance I'd attached to the log files themselves, but I can go
with
that, if that's what was meant.
So, if we had
Joe Conway [mailto:[EMAIL PROTECTED]
Simon Riggs wrote:
Tom Lane [mailto:[EMAIL PROTECTED] That should be user-scriptable
policy, in my worldview.
O... and other dbms will freeze when this situation is hit, rather
than continue and drop archive logs.]
Been there, done that, don't see
Tom Lane
Simon Riggs [EMAIL PROTECTED] writes:
The behaviour I wish to add is:
Keep wal_debug as a value between 0 and 16.
If =0 then no debug output (default).
Use following bitmasks against the value
Mask 1 = XLOG Checkpoints get logged
Mask 2 = Archive API calls get logged
Mask 4
Simon Riggs wrote:
Bruce Momjian
Simon Riggs wrote:
User-selectable behaviour? OK. That's how we deal with fsync; I can
relate to that. That hadn't been part of my thinking because of the
importance I'd attached to the log files themselves, but I can go
with
that, if that's what
If that is indeed the case, I withdraw all my comments and misdirected
ideas, and say we go for a win32 specific workaround :-)
We just need to be very careful on what this work-around is though...
For instance, whilst the idea of an APCcalled flag will work just fine,
mechanically, I'm
Tom Lane wrote:
I don't like the idea of redesigning that
code just because someone misunderstands it.
Fair enough, on both counts. However, the original question which was asked
out of ignorance (that I'll freely admit) doesn't seem to have been directly
addressed:
Claudio Natoli wrote:
The
Patch applied. Thanks.
---
Ray Aspeitia wrote:
Hello,
I wanted to submit some changes to the bundled postgres startup
script for Mac OS X. I added calls to utilize the bundled apache
rotatelogs script in the DB
Yes, I think it looks good.
---
Tatsuo Ishii wrote:
LOCK TABLE table NO WAIT is OK for 7.5? If ok, I will make patches
against current with some docs changes.
--
Tatsuo Ishii
Tatsuo Ishii wrote:
I agree with Tom
Tatsuo Ishii [EMAIL PROTECTED] writes:
LOCK TABLE table NO WAIT is OK for 7.5? If ok, I will make patches
against current with some docs changes.
Dept of minor gripes: can we do this without turning NO into a
keyword? Even as a nonreserved word, I think that would be annoying.
no is a common
If NOWAIT is the choice, I could live with it. If there's no
objection, I will go with NOWAIT, not NO WAIT.
--
Tatsuo Ishii
Tatsuo Ishii [EMAIL PROTECTED] writes:
LOCK TABLE table NO WAIT is OK for 7.5? If ok, I will make patches
against current with some docs changes.
Dept of minor
If NOWAIT is the choice, I could live with it. If there's no
objection, I will go with NOWAIT, not NO WAIT.
How about WITHOUT WAIT, which is like many of our other commands?
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
If NOWAIT is the choice, I could live with it. If there's no
objection, I will go with NOWAIT, not NO WAIT.
How about WITHOUT WAIT, which is like many of our other commands?
The first question in my mind is exactly how does Oracle spell this?
It seems NOWAIT is the winner...
--
Tatsuo Ishii
Oracle uses NOWAIT so we should go for that one.
Regards,
Hans
Tatsuo Ishii wrote:
If NOWAIT is the choice, I could live with it. If there's no
objection, I will go with NOWAIT, not NO WAIT.
--
Tatsuo
On Sunday 07 March 2004 20:28, Michael Meskes wrote:
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
On Sunday 07 March 2004 09:16, Tom Lane wrote:
Personally I consider -c format the only one of the three that is
readable for reviewing purposes, so even if I weren't intending
immediate application, I'd ask for -c before looking at the patch.
There are some folks who consider -u format
56 matches
Mail list logo
