On Fri, 2005-12-02 at 20:03 -0400, Marc G. Fournier wrote:
*roll eyes* Its not even April Fools yet ...
On 12/2/2005 6:19 PM, Marc G. Fournier wrote:
I haven't received any yet, that I can tell ... sure its coming through
the
lists, and not around them?
Some Tom Lane guy and a
On Fri, 2005-12-02 at 17:45 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
CREATE INDEX uses SnapshotAny, so the scan that feeds the build could
easily include rows added after the CREATE INDEX started. When the scan
was exhausted we could mark that last TID and return to it
On Fri, 2005-12-02 at 19:43 -0500, Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
(The larger point that joins of inheritance unions aren't well-planned
is true, but it's always been true...)
It also seems to have a probkem with unions in views.
Is there anything that can be
There's a number of things that can be pushed down over a union set, in
certain circumstances.
FWIW, you should also be able to push the unions up.
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
wouldn't it be more flexible to define a multiplicator or some sort of bool flag on a per object level?oracle hints are a total overkill and i agree with tom that usually people will abuse this feature.if we had a per object flag the actual planner hint can be decoupled from the actual query (i
Transaction Ids are assigned consecutively. As a result, access to the
bitmaps for CLOG and Subtrans will have a tendency to access the
just-recently allocated end of those data structures, which are updated
on successful transaction creation/completion (high level view).
Earlier we found that
Greetings,
Last April we have made some changes to src/ports/snprintf.c so that it
would support argument reordering like %2$s, %1$d and such on
platforms where original snprintf() does not support it, like Windows,
HP-UX or NetBSD.
NLS messages of some languages, like Turkish, rely heavily on
On Friday 02 December 2005 09:53, Simon Riggs wrote:
On Fri, 2005-12-02 at 02:14 -0500, Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
It was a *major* new feature that many people were waiting for when
Oracle finally implemented live CREATE INDEX and REINDEX. The ability
to run
I've quite
interesting results in 8.1, I'm not sure if the queries itself are beyond SQL
specs, but the results are quite interesting:
This is the most
simple I found for the query that still has the problem, the second left join is
not really necessary and can be replaced
Correct
Tom Lane [EMAIL PROTECTED] writes:
What's worse, once you have excluded writes you have to rescan the entire
table to be sure you haven't missed anything. So in the scenarios where this
whole thing is actually interesting, ie enormous tables, you're still
talking about a fairly long interval
Alvaro Herrera [EMAIL PROTECTED] writes:
The problem is that you need to upgrade the lock at the end of the
operation. This is very deadlock prone, and likely to abort the whole
operation just when it's going to finish. Is this a showstopper? Tom
seems to think it is. I'm not sure anyone
On Wed, 2005-11-30 at 10:56 -0500, Tom Lane wrote:
It's been about a month since 8.1.0 was released, and we've found about
the usual number of bugs for a new release, so it seems like it's time
for 8.1.1.
I think one fix that should be made in time for 8.1.1 is adding a note
to the version
Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
What's worse, once you have excluded writes you have to rescan the entire
table to be sure you haven't missed anything. So in the scenarios where this
whole thing is actually interesting, ie enormous tables, you're still
talking
Neil Conway wrote:
On Wed, 2005-11-30 at 10:56 -0500, Tom Lane wrote:
It's been about a month since 8.1.0 was released, and we've found about
the usual number of bugs for a new release, so it seems like it's time
for 8.1.1.
I think one fix that should be made in time for 8.1.1 is adding
David Fetter wrote:
On Wed, Nov 30, 2005 at 11:56:33PM -0400, Marc G. Fournier wrote:
So, if Sun, SRA, Pervasive, Command Prompt, etc were to submit a patch for
v7.2, we'd refuse it?
That depends on what you mean by refuse. Such a patch wouldn't
resurrect the original Postgres with
please unsubscribe me.
-esha
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
What's worse, once you have excluded writes you have to rescan the entire
table to be sure you haven't missed anything.
I was thinking you would set a flag to disable use of the FSM for
inserts/updates while the reindex
Greg Stark [EMAIL PROTECTED] writes:
Other than that case is there any other case the reindex could deadlock with?
Only SELECT, INSERT, UPDATE, and DELETE.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions
Simon Riggs [EMAIL PROTECTED] writes:
These changes have almost no negative impact on run time performance and
can be implemented with minimum change. We can discuss whether the false
sharing phenomena actually occurs, but the bottom line ISTM is that if
we can avoid it ever occurring, for
Mario Weilguni [EMAIL PROTECTED] writes:
It seems like the planner is pulling the last where condition into the
second left join, evaluating it in wrong order.
Can you try this on 8.1 branch tip? It sounds suspiciously similar to
an already-fixed issue (see reports from Sebastian Böck around
Kevin Brown [EMAIL PROTECTED] writes:
In the above for large relations, the bulk of the REINDEX should
happen without any locks being held by the REINDEX operation.
As I just pointed out to Greg, the arm-waving notion that you can turn
off the FSM requires a great deal of low-level locking that
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
In the above for large relations, the bulk of the REINDEX should
happen without any locks being held by the REINDEX operation.
As I just pointed out to Greg, the arm-waving notion that you can turn
off the FSM requires a great deal of
Can you try this on 8.1 branch tip? It sounds suspiciously similar to
an already-fixed issue (see reports from Sebastian Böck around
mid-November). You haven't provided a complete test case so I really
can't investigate for myself ...
regards, tom lane
Of course I
Mario Weilguni [EMAIL PROTECTED] writes:
Of course I can give it a try, do I need to re-initdb when I use cvs to
checkout 8.1 tip?
No, not if you're on 8.1 final (or anything post-beta4, IIRC). Just be
sure to use the same configure arguments as before (pg_config can help
remind you if you
Kevin Brown [EMAIL PROTECTED] writes:
Tom Lane wrote:
Even ignoring that, you *still* have a lock upgrade problem
in this sketch.
Hmm, well, I can see a deadlock potential for those operations that
have to acquire multiple locks simultaneously, and I suppose that the
table + FSM lock would
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Other than that case is there any other case the reindex could deadlock
with?
Only SELECT, INSERT, UPDATE, and DELETE.
How does that happen? What exclusive locks do these take that reindex would
conflict with? I
On Sat, 2005-12-03 at 11:49 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
These changes have almost no negative impact on run time performance and
can be implemented with minimum change. We can discuss whether the false
sharing phenomena actually occurs, but the bottom line
On Sat, 2005-12-03 at 08:47 -0500, Robert Treat wrote:
On Friday 02 December 2005 09:53, Simon Riggs wrote:
On Fri, 2005-12-02 at 02:14 -0500, Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
It was a *major* new feature that many people were waiting for when
Oracle finally
Simon Riggs wrote:
Understood. At 7.3, REINDEXing is essential, since rows never got
deleted and space was not reused. That is not the case now, hence a
REINDEX is less often required.
But it's still required or at least desirable under some circumstances.
If it could be improved, it would be
Hi!
I would like to add an entry to PostgreSQL 8.2 TODO:
- Extend SERIAL to a full-featured auto-incrementer type.
To achieve this, the following three requirements should be fulfilled:
1. The statement parser should be able to handle this:
create table x (
id serial(N),
...
);
and
Am Samstag, den 03.12.2005, 22:23 +0100 schrieb Zoltan Boszormenyi:
Hi!
I would like to add an entry to PostgreSQL 8.2 TODO:
- Extend SERIAL to a full-featured auto-incrementer type.
To achieve this, the following three requirements should be fulfilled:
1. The statement parser should be
On 12/3/05, Tom Lane wrote:
Jochem van Dieten writes:
How about the following sceanrio for building a new index:
- create an empty index
- flag it as incomplete
- commit it so it becomes visible to new transactions
- new transactions will update the index when inserting / updating
- the
Zoltan Boszormenyi wrote:
Hi!
I would like to add an entry to PostgreSQL 8.2 TODO:
- Extend SERIAL to a full-featured auto-incrementer type.
I can't see this item on the TODO list at all. Where exactly did you
find it?
cheers
andrew
---(end of
Zoltan,
I would like to add an entry to PostgreSQL 8.2 TODO:
- Extend SERIAL to a full-featured auto-incrementer type.
I believe that our SERIAL/SEQUENCE stuff is already in compliance with the
SQL standard for sequences (in SQL03). Why would we change it?
--
--Josh
Josh Berkus
Aglio
Hmm...this didn't seem to make it to the newsgroup. Apologies if its a
repeat.
Charlie
-
Hi everyone,
I've been able to successfully build server extension using Visual
Studio 2005 for Windows Postgresql 8.1. However, it took a few tweaks
which I thought I should document (maybe
Charlie Savage [EMAIL PROTECTED] wrote
I've been able to successfully build server extension using Visual
Studio 2005 for Windows Postgresql 8.1. However, it took a few tweaks
which I thought I should document (maybe these issues could be fixed in
future postgresql versions?):
Is this
Josh Berkus wrote:
I believe that our SERIAL/SEQUENCE stuff is already in compliance
with the SQL standard for sequences (in SQL03). Why would we change
it?
Because your belief is wrong, but Zoltan's proposal is not getting is
closer.
--
Peter Eisentraut
Not really. This is for building VC++ extensions that work with
Postgresql for Windows, which is built using MinGW. Thus it allows you
to build extensions with VC++ that work with Postgresql out-of-the-box
on the Windows platform.
In contrast, the link below is for rebuilding Postgresql
On Sat, 2005-12-03 at 17:16 -0300, Alvaro Herrera wrote:
Simon Riggs wrote:
Understood. At 7.3, REINDEXing is essential, since rows never got
deleted and space was not reused. That is not the case now, hence a
REINDEX is less often required.
But it's still required or at least
Is there any reports/fix of this problem?
Regards,
Qingqing
On Fri, 2 Dec 2005, Josep Maria Pinyol Fontseca wrote:
Yes, with psql, pgAdminIII and our application with ODBC I experiment
the same situation... the sentences that I execute are like select *
... or similar like this.
Qingqing
Tom Lane [EMAIL PROTECTED] wrote
The real situation is that you must hold at least AccessShareLock on the
table throughout the entire operation, else you have no defense against
(say) someone dropping the index or the entire table out from under you.
And when you add onto this lock in order
Nicolai Tufar wrote:
Greetings,
I thought it will be as simple as changing Makefile, the issue seem to be
much more complicated. Unfortunately I have no PostgreSQL building
environment handy and will not be able to look at it until the end of next
week because I am moving my house :( But
Qingqing Zhou [EMAIL PROTECTED] writes:
What if we change to cost-based removal, i.e., remove the one whose cost is
smaller. In this case, an two-days-to-be-done reindex should never get
killed.
Instead, it would kill all useful work in your system :-(. An old
transaction would be the one
Bruce Momjian pgman@candle.pha.pa.us writes:
(See the quoted text under the posted text as well.) Basically,
libintl.h on Win32 replaces *printf calls with its own versions, and
does it using macros, _just_ like we do. This of course causes
conflicts and the system fails to compile. The
Added to TODO:
* Add SPI_gettypmod() to return the typemod for a TupleDesc
---
Tom Lane wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
rettupdesc = lookup_rowtype_tupdesc(rettype,0);
This is wrong --- if you
Added to TODO:
o Add long file support for binary pg_dump output
While Win32 supports 64-bit files, the MinGW API does not,
meaning we have to build an fseeko replacement on top of the
Win32 API, and we have to make sure MinGW handles it.
Bruce Momjian pgman@candle.pha.pa.us writes:
Added to TODO:
o Add long file support for binary pg_dump output
While Win32 supports 64-bit files, the MinGW API does not,
meaning we have to build an fseeko replacement on top of the
Win32 API, and we have
On 12/3/2005 4:23 PM, Zoltan Boszormenyi wrote:
Hi!
I would like to add an entry to PostgreSQL 8.2 TODO:
- Extend SERIAL to a full-featured auto-incrementer type.
To achieve this, the following three requirements should be fulfilled:
1. The statement parser should be able to handle this:
48 matches
Mail list logo
