>
>
>
> I see this in pgbench.c:
>
> /* return false iff client should be disconnected */
> static bool
> doCustom(CState *st, instr_time *conn_time)
>
> I think you need to increase the verbosity of the error messages when
> you're working on this code, because when I compile I get a slew of th
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
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 po
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 implementat
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 inclu
Robert Haas writes:
> On Oct 25, 2009, at 10:34 PM, Tom Lane 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 implies that we should prefer
On Oct 25, 2009, at 10:34 PM, Tom Lane 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 SELECT command using
On Sun, Oct 25, 2009 at 10:48:02PM -0400, Tom Lane wrote:
> David Fetter 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 fo
Heikki Linnakangas 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) table_name".
Since "options" are quoted
David Fetter 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 here?
None
Hi,
On Mon, Oct 26, 2009 at 12:34 AM, Andreas Schmidt 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 -1073741811
>
> The r
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 re
Andres Freund 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
SET tgdeferrable
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: Monday,
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 ot
On Sun, Oct 25, 2009 at 6:21 PM, Tom Lane wrote:
> Robert Haas 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).
> * 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 value
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 t
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
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 wrote:
>
> Background info: Fedora/Red Hat folks (not Tom...) changed license in
> PostgreSQL spec file from BSD to MIT with
Robert Haas 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 file, a program that
>
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 advert
On Sun, Oct 25, 2009 at 6:06 PM, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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 = '10MB'
> The problem is
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
too
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
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 turns
On Mon, Oct 19, 2009 at 6:33 PM, Tom Lane 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) making those def
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 justific
Peter Eisentraut 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 that much wor
=?ks_c_5601-1987?B?s+vIq8L5?= 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 separate operation after
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 relatio
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
On Sun, Oct 25, 2009 at 10:08 AM, Peter Eisentraut 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 (pgsql-hackers@p
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 implementa
35 matches
Mail list logo
