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
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
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 anythin
>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 don
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 CPU
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 ar
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
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
resul
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 int
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 a
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
> >
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
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
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 th
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 be
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, fo
"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 aro
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
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 gre
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 ca
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 lo
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
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 botto
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
> > > > Oracl
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
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 behi
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 sh
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
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 broadcast)
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
Agli
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?):
>
>
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
http://developer.postgresql.org/
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 it
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.
>
>
>
"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 i
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 :( B
"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
Bruce Momjian 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 _fix_ was to disable
>
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 --
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 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 to make sure MinGW
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:
cre
48 matches
Mail list logo
