On lör, 2009-10-24 at 13:32 -0400, Greg Smith wrote:
Regardless, the UI I was hoping for was to make the default
postgresql.conf file end with a line like this:
directory 'conf'
I think something like is this is definitely more understandable for
users and less overkill in the
On Sun, Oct 25, 2009 at 10:08 AM, Peter Eisentraut pete...@gmx.net wrote:
As a file point, I would prefer something like
include 'whatever/*.conf'
+1 for that. That's what Apache does and it works well for the users
and the packagers.
--
Guillaume
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
Actually, I think any attempt to do that would result in a fork,
and a consequent splintering of the community. We can get away
Perhaps the answer might be a pre-emptive simplifying fork to postgres-NG,
perhaps taking a lead from MySQL and Samba.
I'm not sure that you would
Dear hackers,
I’m modifying backend source codes of pgsql.
While inspecting the heap_update function (src/backend/access/heapam.c),
I found that the relkind fields of all RelationData which is handed over to
heap_update are all the same as ‘r’.
I want to distinguish normal
=?ks_c_5601-1987?B?s+vIq8L5?= falls...@cs.yonsei.ac.kr writes:
I found that the relkind fields of all RelationData which is handed over to
heap_update are all the same as ¡®r¡¯.
Well, yeah: heap_update is applied to heaps (ordinary tables). Not indexes.
The indexes are generally updated in a
Peter Eisentraut pete...@gmx.net writes:
As a file point, I would prefer something like
include 'whatever/*.conf'
that is, listing the files as a glob pattern instead of naming a
directory.
+1, but *only* if it does not lead to us having to write our own
version of glob(). It's not worth
On Mon, 2009-10-19 at 17:48 +0100, Dean Rasheed wrote:
This is a WIP patch to replace the after-trigger queues with TID bitmaps
to prevent them from using excessive amounts of memory. Each round of
trigger executions is a modified bitmap heap scan.
This is an interesting patch. The
On Mon, Oct 19, 2009 at 6:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Per-table is not physically sensible. Per-tablespace has some rationale
to it.
I took a look at this and it seems fairly straightforward. It
basically requires (1) deciding where and how to store per-tablespace
defaults, (2)
Dear tom lane and hackers,
I am sorry, I should have explained the reason.
Actually, I'm not modifying the backend source code.
Since I am not a native speaker, I am not good at writing in English.
I'm just trying to make my own pgsql code for my research purpose.
Later, if my research
On Mon, 2009-10-19 at 17:48 +0100, Dean Rasheed wrote:
This is a WIP patch to replace the after-trigger queues with TID bitmaps
to prevent them from using excessive amounts of memory. Each round of
trigger executions is a modified bitmap heap scan.
Can you please take a look at my patch here:
On Mon, 26 Oct 2009, ??? wrote:
What I am trying to do now is to examine the real dirty portion of
buffer pages to be flushed like the following.
You can trivially use pg_buffercache for view this, and its code in
contrib/pg_buffercache will show you how to navigate the buffer cache data
Robert Haas robertmh...@gmail.com writes:
I don't really understand this. What usage habits do we need to
change?
The assumption that it's okay to document what you've done with
something like
# work_mem = '1GB'
# changed to give saner behavior 10/25/08
work_mem =
On Sun, Oct 25, 2009 at 6:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I don't really understand this. What usage habits do we need to
change?
The assumption that it's okay to document what you've done with
something like
# work_mem = '1GB'
Background info: Fedora/Red Hat folks (not Tom...) changed license in
PostgreSQL spec file from BSD to MIT with the following notice:
# PG considers their license to be simplified BSD, but it's more nearly
MIT
Our license wording fits perfectly to MIT, if I'm not wrong. However, we
always
Robert Haas robertmh...@gmail.com writes:
I just don't buy it. With the instructions in the file, a program
that rewrites the file will fail miserably on every installation out
there (or will be full of logic that tries, futilely, to parse the
comments). With the instructions out of the
It's not a perfect match to MIT, but it is close. We (-core) are
already actively working on this issue to find the most appropriate
way forward.
On 10/25/09, Devrim GÜNDÜZ dev...@gunduz.org wrote:
Background info: Fedora/Red Hat folks (not Tom...) changed license in
PostgreSQL spec file from
On Sat, Oct 24, 2009 at 06:23:24PM +0100, Roger Leigh wrote:
On Fri, Oct 16, 2009 at 01:38:15PM +0300, Peter Eisentraut wrote:
I like the new Unicode tables, but the marking of continuation lines
looks pretty horrible:
List of databases
Name │
On Sun, Oct 25, 2009 at 11:48:27PM +, Roger Leigh wrote:
There's just one tiny display glitch I can see, and that's if you have
mixed wrapping and newlines, you miss the lefthand wrap mark if the line
is the last wrapped line and it ends in a newline. It might not be
possible to pick that
* Note: TPC-B requires at least 100 bytes per row, and the filler
* fields in these table declarations were intended to comply with that.
* But because they default to NULLs, they don't actually take any
* space. We could fix that by giving them non-null default values.
On Sun, Oct 25, 2009 at 6:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I just don't buy it. With the instructions in the file, a program
that rewrites the file will fail miserably on every installation out
there (or will be full of logic that tries,
On Sun, Oct 25, 2009 at 11:34:28PM +0100, Dave Page wrote:
It's not a perfect match to MIT, but it is close. We (-core) are
already actively working on this issue to find the most appropriate
way forward.
Legally speaking, what are the issues at hand here?
Apart from the legal part, what
Dear Greg Smith,
Thank you for letting me know about the presentations in your homepage.
It's going to be much helpful in understanding the internal of postgresql
further.
- Best Regards
Hongchan Roh -
-Original Message-
From: Greg Smith [mailto:gsm...@gregsmith.com]
Sent:
Andres Freund and...@anarazel.de wrote:
I would like to hear some opinions before starting to take a stab at
implementing $subject.
+1 to support it.
I'm using deferred trigger to emulate on-commit trigger,
but official support is infinitely better.
UPDATE pg_catalog.pg_trigger
Now that we've got a hopefully-non-broken implementation of SELECT FOR
UPDATE locking as a plan node, we can finally contemplate fixing two
misbehaviors that are called out on the SELECT reference page:
It is possible for a SELECT command using both LIMIT and FOR
UPDATE/SHARE clauses to
Hi,
On Mon, Oct 26, 2009 at 12:34 AM, Andreas Schmidt a.schm...@mdtec.de wrote:
I'm testing serveral days a replication-system with PostgreSQL, but I get
allways the same error.
2009-10-25 15:44:45 CET FATAL: XX000: could not restore file
0001.history from archive: return code
David Fetter da...@fetter.org writes:
On Sun, Oct 25, 2009 at 11:34:28PM +0100, Dave Page wrote:
It's not a perfect match to MIT, but it is close. We (-core) are
already actively working on this issue to find the most appropriate
way forward.
Legally speaking, what are the issues at hand
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
I got the impression that replacing VACUUM FULL is the most popular
opinion. I like VACUUM REWRITE myself, except that it would require
making REWRITE a reserved keyword.
My next proposal for the syntex is VACUUM (options)
On Sun, Oct 25, 2009 at 10:48:02PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Sun, Oct 25, 2009 at 11:34:28PM +0100, Dave Page wrote:
It's not a perfect match to MIT, but it is close. We (-core) are
already actively working on this issue to find the most appropriate
On Oct 25, 2009, at 10:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Now that we've got a hopefully-non-broken implementation of SELECT FOR
UPDATE locking as a plan node, we can finally contemplate fixing two
misbehaviors that are called out on the SELECT reference page:
It is possible for a
Robert Haas robertmh...@gmail.com writes:
On Oct 25, 2009, at 10:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... The solution for the second
one is to also put LockRows underneath the Sort node, and to regard its
output as unsorted so that a Sort node will certainly be generated.
(This in turn
On Sun, 25 Oct 2009, Robert Haas wrote:
I especially don't believe that it will ever support SET PERSISTENT,
which I believe to be a feature a lot of people want.
It actually makes it completely trivial to implement. SET PERSISTENT can
now write all the changes out to a new file in the
On Sun, 25 Oct 2009, Tom Lane wrote:
Some poking around suggests that glob(3) is reasonably portable
across Unixen, but is it provided on Windows?
You can probably use FindFirstFile for that:
http://msdn.microsoft.com/en-us/library/aa364418%28VS.85%29.aspx
Standard UNIX-ish glob
On 10/25/09 5:33 PM, Robert Haas wrote:
Greg believes that it
isn't politically feasible to change the default postgresql.conf, now
or perhaps ever. I notice that he didn't say that he thinks it's a
bad idea. So he has come up with an alternate plan which he believes
is the best one
Greetings,
I'd like to propose a potential patch, and wanted to get preliminary
feedback on it before I started looking into the design.
Summary:Add a string key space to the advisory lock functionality.
Rationale:
Right now, the key spaces (the range of unique values that can be used
34 matches
Mail list logo
