Simon Riggs wrote:
Happy New Year, everybody.
This proposal follows on from previous thinking about partitioning,
where I've taken up Andrew Sullivan's suggestion to re-examine the
current partitioning concept of using tables as partitions. So I've come
up with an alternative concept to allow
Andrew Dunstan wrote:
Just a note: I don't find the mail archive approach to these lists
optimal. A list on a wiki page with links from individual discussions,
rather like the one Stefan did earlier at
http://developer.postgresql.org/index.php/Todo:PatchStatus , makes
things a lot clearer,
Tom Lane wrote:
There's also the plan B of scanning pg_class to decide which relfilenode
values are legit. IIRC Bruce did up a patch for this about a year ago,
which I vetoed because I was afraid of the consequences if it removed
data that someone really needed. Someone just mentioned doing
Florian G. Pflug wrote:
August Zajonc wrote:
I'm confused about this.
As long as we assert the rule that the file name can't change on the
move, then after commit the file can be in only one of two places.
The name of the file is known (ie, pg_class). The directories are
known. What needs
Tom Lane wrote:
What I was thinking about was a flag file separate from the data file
itself, a bit like what we use for archiver signaling. If is the
new data file, then touch .new to mark the file as needing to be
deleted on restart. Remove these files just *before* commit. This
Florian G. Pflug wrote:
You could still leak them (ie, you move to final location and bail
before commit) but it seems to narrow the window down significantly.
That leak could be prevented I think if the COMMIT record indicated
which files are to be moved, and the actual move happens after the
Golden Liu wrote:
3. Before evaluating a SQL command, check column-level privilege.
This is done AFTER checking table-level privilege. As I mentioned
before, if table-level privilege is granted, it's not necessary to
check column-level privilege.
Golden, this sounds good. I'm just a user.
It
Robert Haas wrote:
My strongly opinion is that, REVOKE column-level priviledge should
revoke access to that column, in effect it should reduce the table-level
grant to column-level grants.
I think this causes problems when columns are added to the table. If
table X has columns A, B, C,
Tom Lane wrote:
Robert Haas [EMAIL PROTECTED] writes:
...
IF this will be implemented as suggested here, it will become
extremely counter-intuitive.
...
You could solve this by having explicit positive and negative ACLs, i.e.
your permissions for a particular column are:
Josh Berkus wrote:
Between major
improvements to performance, major changes to the file format, and changes to
implicit conversions breaking backwards compatibility, our new ability to
more-or-less stick to deadlines ...
... should this be 9.0 instead of 8.3?
Seems like it'd be both an
Bruce Momjian wrote:
OK, but we don't want something that is ready to be committed, we need
it complete.
So how many more releases before you think Postgres is complete?
I am getting tired of your semantic games, here, Greg. I have no idea
what you are trying to accomplish, but I have
Simon Riggs wrote:
On Tue, 2007-03-27 at 20:48 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
It seems possible to reduce overall WAL volume by roughly 25% on common
workloads by optimising the way UPDATE statements generate WAL.
This seems a huge amount of work to optimize
Tom Lane wrote:
Dennis Bjorklund [EMAIL PROTECTED] writes:
Tom Lane skrev:
Whether it is actually ever going to disappear is not agreed upon.
What is the reason to keep it?
The words-of-one-syllable answer is that D'Arcy Cain is still willing
to put work into supporting the money type,
Andrew Dunstan wrote:
August Zajonc wrote:
The only other nice thing would be user defined precision, but
can live without that as most currencies work under nnn.mm.
That's useless for our system at least. The minimum scale we use for
money values is 5. I guess we can just continue to use
Shane Ambler wrote:
August Zajonc wrote:
For balance sheet accounts, their value at a given point in time in a
home currency is of course dependent on exchange rates which creates the
currency gain or loss on the PL side, the account that captures
exchange rate movements
Joshua D. Drake wrote:
From an deployable application perspective, this could be a big deal. We
are already starting to see very large traction in the Win32 desktop app
arena.
There seem to be a few overlapping proposals in terms of reducing
various guarantees in the name of performance.
As
Florian G. Pflug wrote:
Alvaro Herrera wrote:
Florian G. Pflug wrote:
However, I just realized that doing this is much harder than I initially
thought, because catalog access always happens with SnapshotNow, and
e.g. drop table deletes datafiles at commit time, and not during
vacuum.
Not
Tom Lane wrote:
August Zajonc [EMAIL PROTECTED] writes:
The key is how lightweight the setup could be, which matters because
clients are not always willing to pay for a PITR setup. The low overhead
would mean you'd feel fine about setting guc to 1hr or so.
This would have exactly the same
RPK wrote:
Andrew,
Demanding unlimited undo at some time that is arbitrarilly distant in the
future strikes me as wholly unreasonable.
I did not mean asking for undo from a life-time log. Since FlashBack
Technology is already there, I just mean that world's most advanced database
Gregory Stark wrote:
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes:
First we must run the query in serializable mode and replace
the snapshot with a synthetic one, which defines visibility
at the start of the desired transaction
We could use something that controls global xmin.
It
On Mon, 19 Feb 2007 20:30:59 +0100, Florian G. Pflug [EMAIL PROTECTED]
said:
August Zajonc wrote:
Gregory Stark wrote:
Couldn't you define things simply to be that you get a consistent view
including all transactions started before x transaction? This is time
travel lite, but low
On 12/29/06, Stephen Frost wrote:
In the case above, exim4 *can* provide an exception because it's the
*GPL* of *exim4* which is being violated by the advertising clause in
the *OpenSSL* license. Which exim4 upstream has *done*, and which can
be seen in their license (linked to previously in
Simon Riggs wrote:
If my assumption is badly wrong on that then perhaps HOT would not be
useful after all. If we find that the majority of UPDATEs meet the HOT
pre-conditions, then I would continue to advocate it.
This is exactly my situation. All updated hit non-indexed fields, with a
lot of
Martijn van Oosterhout wrote:
On Tue, Mar 21, 2006 at 03:59:31PM -0500, Andrew Dunstan wrote:
I think such types would be better implemented as some sort of
structured type, possibly with constructors and methods and all the
other stuff that SQL talks about. We don't have all of that yet --
Devrim GUNDUZ wrote:
Hi,
As you know, many databases that run on Linux / Unix systems have a GUI
installer which make installation easier and more attractive for some
people.
Our Windows Installer is very attractive, for example.
Now, I and Burcu Guzel, who is a Senior Programmer,
As a user and a list lurker I very much like Bruce's proposed ALTER
TABLE syntax. COPY LOCK (and the variants I can imagine being required
for all the other types of cases) don't seem as appealing.
And ALTER TABLE seems to make it clear it is an object level change,
feels like it fits the
Perhaps this question would be better directed to -general?
The documentation for PostgreSQL is suprisingly good as well but I assume
you've read that and are still confused :)
AZ
Peter Moscatt [EMAIL PROTECTED] wrote in message
jaof7.127918$[EMAIL PROTECTED]">news:jaof7.127918$[EMAIL
Curious if anyone has done any work on client side connection pooling
recently? I'm thinking pooling multiplexed against transaction commits?
AZ
---(end of broadcast)---
TIP 6: Have you searched our list archives?
, otherwise they look like they have a nice
thing going.
AZ
-Original Message-
From: Mark Pritchard [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 07, 2001 6:50 PM
To: August Zajonc; [EMAIL PROTECTED]
Subject: RE: [HACKERS] Client Side Connection Pooling
Curious if anyone has
Straight out of Allied peace talks, we've got this article up at mysql.com
http://www.mysql.com/news/article-76.html
One wonders what happened to the postal or email systems that this couldn't
have been delivered privately.
In all honesty, it appears mysql.org was overdue, the level of rhetoric
pgsql-hackers is for folks who are developing pgsql...
Consider posting to -general which is for people using pgsql..
jacky_shu [EMAIL PROTECTED] wrote in message
9e0q9v$q0p$[EMAIL PROTECTED]">news:9e0q9v$q0p$[EMAIL PROTECTED]...
Hello everyone:
I am a novice in postgreSQL.So i want to get
Heck ya...
I wonder if cache failures should be what drives the vacuum daemon to
vacuum a table? Sort of like, Hey, someone is asking for free pages
for that table. Let's go find some! That may work really well.
Another advantage of centralization is that we can record update/delete
An excellent idea.
I suspect you'll get a biased resonse from the -hackers folks. This really
is an excellent idea.
Those options cover I think the main scenarios, with the first two options
being the most important. Ideally you'd basically sample server specs
(speed, # of procs, mem etc) and
I'd be happy to see during initial setup a few questions go by that would
size the underlying OS properly as well. We all do the same things with a
new system, increase filesystem limits etc... Some of these options (on a
dedicated postgresql) are gimme's. Why not do them once upfront, prompt the
34 matches
Mail list logo
