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
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
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.
-
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 --
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
>
"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
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
"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
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.
>
>
>
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
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
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/
"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?):
>
>
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
"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
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
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
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
please unsubscribe me.
-esha
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
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
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
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
> >
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
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
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
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
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
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
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
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
>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
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
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 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
48 matches
Mail list logo
