On Sun, Jan 30, 2011 at 5:26 PM, Robert Haas wrote:
> The parallel pg_dump portion of this patch (i.e. the still-uncommitted
> part) no longer applies. Please rebase.
Here is a rebased version with some minor changes as well. I haven't
tested it on Windows now but will do so as soon as the Unix
Hi everyone, I just want to know something about postgresql parser, because
I want to add a new feature for pgAdmin graphical query builder (GQB) that
allow an user to create a query graphical model from a sql statment, and I
just want to reuse postgres parser code (reuse this) to do the task of
cr
On 2/1/2011 5:47 PM, Bruce Momjian wrote:
Do we want a TODO about optimizing COUNT(*) to avoid aggregate
processing overhead?
Definitely not. In my opinion, and I've seen more than a few database
designs, having count(*) is almost always an error.
If I am counting a large table like the one
Andrew Dunstan writes:
> On 02/01/2011 05:47 PM, Bruce Momjian wrote:
>> Tom Lane wrote:
>>> At this point what we've got is 25% of the runtime in nodeAgg.c overhead,
>>> and it's difficult to see how to get any real improvement without tackling
>>> that.
>> Do we want a TODO about optimizing COU
On 02/01/2011 05:47 PM, Bruce Momjian wrote:
Tom Lane wrote:
At this point what we've got is 25% of the runtime in nodeAgg.c overhead,
and it's difficult to see how to get any real improvement without tackling
that. Rather than apply the patch shown above, I'm tempted to think about
hard-wiri
Tom Lane wrote:
> At this point what we've got is 25% of the runtime in nodeAgg.c overhead,
> and it's difficult to see how to get any real improvement without tackling
> that. Rather than apply the patch shown above, I'm tempted to think about
> hard-wiring COUNT(*) as a special case in nodeAgg.c
* Christopher Hotchkiss wrote:
On Tue, Feb 1, 2011 at 2:49 PM, Christian Ullrich wrote:
* Christopher Hotchkiss wrote:
I would like to propose (and volunteer to do if its considered to be a
decent idea) to extend the mapping of users to roles in the
pg_ident.conf to incorporate groups. This
Hi Kevin,
this example was for teaching AI students (with limited PostgreSQL
knowledge) in a very basic lecture -- I did not want to tweak the SQL
semantics too much; just demonstrate why SQL is rightfully called a 4GL
language. ;-)
Cheers, Nick
On 02/01/2011 10:08 PM, Kevin Grittner wrote:
Hi Peter,
Another possibility is
foo->bar(baz)
This is in the SQL standard under, but
it requires the left side to be of a reference type, which is something
that we don't have.
I think this is the point where I stopped my efforts in the past -- I
guessed that a reference, in Postgre
Hi Pavel,
I guess this represents most exactly what this professor is thinking
about -- being able to create methods and types with methods which can
be nested -- but syntactical details are of secondary importance.
All the best, Nick
On 02/01/2011 05:43 AM, Pavel Stehule wrote:
Hello
it i
Nick Rudnick wrote:
> here an inelegant example
Based on that example, you should be sure to look at the INHERITS
clause of CREATE TABLE:
http://www.postgresql.org/docs/current/interactive/sql-createtable.html
PostgreSQL has the "is a" structure built in. That may not get you
all the way
On ons, 2011-01-19 at 10:16 +0900, Hitoshi Harada wrote:
> Thanks. I tested the new version and looks ok. I'll mark it "Ready for
> Commiter".
Committed.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
On 02/01/2011 03:36 AM, Robert Haas wrote:
On Mon, Jan 31, 2011 at 5:40 PM, Nick Rudnick wrote:
* In this regard it is of interest in how far there are principal efficiency
problems with the support of (deeply nested) object like structure by the
backend, or if the backend may be expected to do
On Tue, Feb 1, 2011 at 2:49 PM, Christian Ullrich wrote:
> * Christopher Hotchkiss wrote:
>
>> I would like to propose (and volunteer to do if its considered to be a
>> decent idea) to extend the mapping of users to roles in the
>> pg_ident.conf to incorporate groups. This would allow any user who
On Tue, 2011-02-01 at 11:43 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > Here's the basic patch, will work on the refactoring if no objections.
>
> ResolveRecoveryConflictWithDatabase works when you're not in recovery?
> That seems pretty fragile at best. In any case, this is a 9.2 feature
>
* Christopher Hotchkiss wrote:
I would like to propose (and volunteer to do if its considered to be a
decent idea) to extend the mapping of users to roles in the
pg_ident.conf to incorporate groups. This would allow any user who
belonged to a particular group in certain authentication systems to
On Feb 1, 2011, at 12:39 PM, Tom Lane wrote:
> Christopher Hotchkiss writes:
>> I would like to propose (and volunteer to do if its considered to be a
>> decent idea) to extend the mapping of users to roles in the pg_ident.conf to
>> incorporate groups.
>
> Um ... there isn't any real distincti
Tom Lane wrote:
> Bruce Momjian writes:
> > My trivial idea was: let's assume we checkpoint every 10 minutes, and
> > it takes 5 minutes for us to write the data to the kernel. If no one
> > else is writing to those files, we can safely wait maybe 5 more minutes
> > before issuing the fsync. I
Bruce Momjian writes:
> My trivial idea was: let's assume we checkpoint every 10 minutes, and
> it takes 5 minutes for us to write the data to the kernel. If no one
> else is writing to those files, we can safely wait maybe 5 more minutes
> before issuing the fsync. If, however, hundreds of wr
On Tue, Feb 1, 2011 at 1:09 PM, Peter Eisentraut wrote:
> On tis, 2011-01-18 at 19:24 -0500, Steve Singer wrote:
>> However if I connect with a line in pg_hba that matches on an IP
>> network then my client_hostname is always null unless log_hostname is
>> set to true. This is consistent with the
Kevin Grittner wrote:
> Robert Haas wrote:
>
> > I also think Bruce's idea of calling fsync() on each relation just
> > *before* we start writing the pages from that relation might have
> > some merit.
>
> What bothers me about that is that you may have a lot of the same
> dirty pages in the O
On Tue, Feb 1, 2011 at 12:58 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> I also think Bruce's idea of calling fsync() on each relation just
>> *before* we start writing the pages from that relation might have
>> some merit.
>
> What bothers me about that is that you may have a lot of the
Greg Smith wrote:
> Greg Smith wrote:
> > I think the right way to compute "relations to sync" is to finish the
> > sorted writes patch I sent over a not quite right yet update to already
>
> Attached update now makes much more sense than the misguided patch I
> submitted two weesk ago. This ta
Jeff Davis wrote:
> On Tue, 2011-02-01 at 11:01 -0600, Kevin Grittner wrote:
>> My compiler doesn't.
>
> Strange. Maybe it requires -O2?
That's not it; I see -O2 in my compiles.
At any rate, I think the default clause is the best place to quash
the warning because that leaves us with a warnin
Robert Haas wrote:
> Back to your idea: One problem with trying to bound the unflushed data
> is that it's not clear what the bound should be. I've had this mental
> model where we want the OS to write out pages to disk, but that's not
> always true, per Greg Smith's recent posts about Linux kerne
Hi,
PFA version 3 of the ALTER EXTENSION PATCH, cleaned and merged against
recent HEAD and extension's branch from which I just produced the v30
patch.
It includes a way to upgrade "from null", that is from pre-9.1, and the
specific upgrade files to achieve that for all contribs. That goes like
Magnus Hagander wrote:
> On Tue, Feb 1, 2011 at 02:25, Bruce Momjian wrote:
> > Magnus Hagander wrote:
> >> I just tried doing pg_upgrade on a database when logged in as user
> >> "mha" rather than "postgres" on my system. And it failed. Even though
> >> the db was initialized with superuser "mha"
On tis, 2011-01-18 at 19:24 -0500, Steve Singer wrote:
> However if I connect with a line in pg_hba that matches on an IP
> network then my client_hostname is always null unless log_hostname is
> set to true. This is consistent with the behavior you describe but I
> think the average user will fin
Robert Haas wrote:
> I also think Bruce's idea of calling fsync() on each relation just
> *before* we start writing the pages from that relation might have
> some merit.
What bothers me about that is that you may have a lot of the same
dirty pages in the OS cache as the PostgreSQL cache, and y
On Tue, 2011-02-01 at 11:01 -0600, Kevin Grittner wrote:
> My compiler doesn't.
Strange. Maybe it requires -O2?
> Would it make sense to elog here, rather than
> Assert? I'm not clear on the rules for that.
elog looks fine there to me, assuming we have the default case. I'm not
100% clear on th
On Tue, Feb 1, 2011 at 12:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> So I'm back to proposing that we just apply FPI-free WAL records
>> unconditionally, without regard to the LSN. This could potentially
>> corrupt the page, of course.
>
> Yes. So you're still assuming that there will be a
On Mon, Jan 31, 2011 at 4:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> Back to the idea at hand - I proposed something a bit along these
>> lines upthread, but my idea was to proactively perform the fsyncs on
>> the relations that had gone the longest without a write, rather than
>> the ones w
Robert Haas writes:
> So I'm back to proposing that we just apply FPI-free WAL records
> unconditionally, without regard to the LSN. This could potentially
> corrupt the page, of course.
Yes. So you're still assuming that there will be a later FPI-containing
WAL record to fix up the mess you cr
Christopher Hotchkiss writes:
> I would like to propose (and volunteer to do if its considered to be a
> decent idea) to extend the mapping of users to roles in the pg_ident.conf to
> incorporate groups.
Um ... there isn't any real distinction between users and groups
anymore, they're all roles.
Dimitri Fontaine writes:
> Itagaki Takahiro writes:
>> Hi, the attached is a further cleanup of the latest commit
>> (1db20cdd36cb1c2cc5ef2210a23b3c09f5058690).
> Thanks! Given that the patch contains some merging from master's
> branch, I'm not sure if I should apply it to my repository then h
On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin wrote:
> I've looked at the patch and added a test for arrays exceeding or equal
> maximum dimensions to check, whether the recursive function won't bring
> surprises there. I've also added check_stack_depth calls to both split_array
> and plperl_h
Jeff Davis wrote:
> One thing that confused me a little about the code is the default
> case at the end. The enum is exhaustive, so the default doesn't
> really make sense. The compiler warning you are silencing is the
> uninitialized variable xid (right?)
Right.
> Since you have the "Assert
On Mon, Jan 31, 2011 at 12:22, Andrew Dunstan wrote:
> This looks pretty good. But why are we bothering to keep $prolog at all any
> more, if all we're going to pass it is &PL_sv_no all the time? Maybe we'll
> have a use for it in the future, but right now we don't appear to unless I'm
> missing
Simon Riggs writes:
> Here's the basic patch, will work on the refactoring if no objections.
ResolveRecoveryConflictWithDatabase works when you're not in recovery?
That seems pretty fragile at best. In any case, this is a 9.2 feature
at the earliest, please do not expect people to spend time on
hi,
thanks for taking a look.
> y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
>> the attached patch is to avoid unnecessary detoast'ing and EOF marker pages
>> when possible. does it make sense?
>
> The blob page size is already chosen not to allow for out-of-line
> storage, not to mention
hi,
> I wrote:
>> y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
>>> after systable_getnext_ordered returned NULL, is it ok to call it again?
>
>> I wouldn't rely on it working.
>
>>> i'm wondering because inv_truncate seems to do it and expecting NULL.
>
>> Hmm, that may well be a bug. Hav
Greg Smith wrote:
I think the right way to compute "relations to sync" is to finish the
sorted writes patch I sent over a not quite right yet update to already
Attached update now makes much more sense than the misguided patch I
submitted two weesk ago. This takes the original sorted write co
On mån, 2011-01-31 at 21:53 -0500, Tom Lane wrote:
> You would probably have better luck shoehorning in such a feature if the
> syntax looked like this:
>
> (foo).bar(baz)
>
> foo being a value of some type that has methods, and bar being a method
> name.
The SQL standard has the clause t
On Tue, Feb 1, 2011 at 10:11 AM, Peter Eisentraut wrote:
> The SQL standard has the clause that appears to
> allow:
>
> ...something.column.method(args)
>
> Good luck finding out how to interpret the dots, but it's specified
> somewhere.
My head just exploded.
> It'd be kind of nice as a syn
Em 14-01-2011 17:41, Jaime Casanova escreveu:
Here is a patch that implements "named restore points".
Sorry, I was swamped with work. :(
Your patch no longer applied so I rebased it and slightly modified it. Review
is below...
+ The default is to recover to the end of the WAL log.
+
2011/2/1 Robert Haas :
> On Mon, Jan 31, 2011 at 11:41 PM, Pavel Stehule
> wrote:
>> CREATE METHOD next_color (n INT)
>> RETURNS INT
>> FOR colored_part_t
>> RETURN SELF.color_id + n
>>
>> SELECT partno, color_id, DEREF(oid).next_color(1) AS next
>> FROM colored_parts
>
> DEREF(oid)? That's just
Itagaki Takahiro writes:
> Hi, the attached is a further cleanup of the latest commit
> (1db20cdd36cb1c2cc5ef2210a23b3c09f5058690).
Thanks! Given that the patch contains some merging from master's
branch, I'm not sure if I should apply it to my repository then handle
conflicts, or let you manage
2011/2/1 Robert Haas :
> On Mon, Jan 31, 2011 at 9:53 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> It would help if you were a bit more specific. Do you mean you want
>>> to write something like foo.bar(baz) and have that mean call the bar
>>> method of foo and pass it baz as an argument?
>>
>
On Mon, Jan 31, 2011 at 11:41 PM, Pavel Stehule wrote:
> CREATE METHOD next_color (n INT)
> RETURNS INT
> FOR colored_part_t
> RETURN SELF.color_id + n
>
> SELECT partno, color_id, DEREF(oid).next_color(1) AS next
> FROM colored_parts
DEREF(oid)? That's just bizarre.
--
Robert Haas
EnterpriseD
On Mon, Jan 31, 2011 at 9:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> It would help if you were a bit more specific. Do you mean you want
>> to write something like foo.bar(baz) and have that mean call the bar
>> method of foo and pass it baz as an argument?
>
>> If so, that'd certainly be p
On Tue, Feb 1, 2011 at 7:28 AM, Itagaki Takahiro
wrote:
> On Fri, Jan 28, 2011 at 17:12, Marko Tiikkaja
> wrote:
>> I still didn't address
>> the issue with pg_advisory_unlock_all() releasing transaction scoped locks,
>
> I guess you don't want independent locks, right? If an user object
> is loc
On Tue, Feb 1, 2011 at 12:08, Dave Page wrote:
> On Tue, Feb 1, 2011 at 10:45 AM, Andrew Dunstan wrote:
>>
>> Why are we only disabling the macro for WIN32 and not for the other
>> platforms that the macro is defined for? Do we know it's not also a problem
>> on Apple or Cygwin?
>
> No, not as fa
On Fri, Jan 28, 2011 at 17:12, Marko Tiikkaja
wrote:
> I still didn't address
> the issue with pg_advisory_unlock_all() releasing transaction scoped locks,
I guess you don't want independent locks, right? If an user object
is locked by session locks, it also blocks backends trying to lock it
with
> Updated patch attached.
I think we need to improve postgresql.conf.sample a bit more, especially
the long line for #log_csv_fields = '...'. 330 characters in it!
#1. Leave the long line because it is needed.
#2. Hide the variable from the default conf.
#3. Use short %x mnemonic both in log
On Tue, Feb 1, 2011 at 10:45 AM, Andrew Dunstan wrote:
>
> Why are we only disabling the macro for WIN32 and not for the other
> platforms that the macro is defined for? Do we know it's not also a problem
> on Apple or Cygwin?
No, not as far as I know.
--
Dave Page
Blog: http://pgsnake.blogspot
List,
Can anyone suggest where the below error comes from, given I'm attempting to
load HTTP access log data with reasonably small row and column value lengths?
logs=# COPY raw FROM '/path/to/big/log/file' DELIMITER E'\t' CSV;
ERROR: out of memory
DETAIL: Cannot enlarge
On 02/01/2011 03:47 AM, Dave Page wrote:
On Tue, Feb 1, 2011 at 8:29 AM, Magnus Hagander wrote:
On Tue, Feb 1, 2011 at 09:08, Dave Page wrote:
On Tue, Feb 1, 2011 at 5:36 AM, Itagaki Takahiro
wrote:
2011/1/27 Hiroshi Inoue:
I see now the following lines in libintl.h of version
0.18.1.1
On 1 February 2011 05:31, Itagaki Takahiro wrote:
> On Tue, Feb 1, 2011 at 00:37, Thom Brown wrote:
>> I've attached a small patch for the docs which adds a reference to the
>> client_encoding parameter description. This is in response to someone
>> attempting to submit a comment which explains
2011/2/1 Magnus Hagander :
> On Tue, Feb 1, 2011 at 07:56, Pavel Stehule wrote:
>
>> 2011/2/1 Magnus Hagander :
>>
>>> On Tue, Feb 1, 2011 at 05:53, Pavel Stehule wrote:
>>>
Hello
There are broken links inside messages from commiters.
projects /
404 - No s
On Tue, Feb 1, 2011 at 02:25, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> I just tried doing pg_upgrade on a database when logged in as user
>> "mha" rather than "postgres" on my system. And it failed. Even though
>> the db was initialized with superuser "mha". The reason for this was
>> that
On Mon, 2011-01-31 at 17:55 -0600, Kevin Grittner wrote:
> http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=6360b0d4ca88c09cf590a75409cd29831afff58b
>
> With confidence that it works, I looked it over some more and now
> like this a lot. It is definitely more readable
On Tue, 2011-02-01 at 07:35 +0100, Magnus Hagander wrote:
> On Tue, Feb 1, 2011 at 03:29, Robert Haas wrote:
> > On Mon, Jan 31, 2011 at 8:52 PM, Tom Lane wrote:
> >>> Then again - in theory, there's no reason why we couldn't drop a
> >>> database on the master when it's in use, kicking out every
On Tue, Feb 1, 2011 at 8:29 AM, Magnus Hagander wrote:
> On Tue, Feb 1, 2011 at 09:08, Dave Page wrote:
>> On Tue, Feb 1, 2011 at 5:36 AM, Itagaki Takahiro
>> wrote:
>>> 2011/1/27 Hiroshi Inoue :
I see now the following lines in libintl.h of version
0.18.1.1 which didn't exist in 0.17
On Tue, Feb 1, 2011 at 09:08, Dave Page wrote:
> On Tue, Feb 1, 2011 at 5:36 AM, Itagaki Takahiro
> wrote:
>> 2011/1/27 Hiroshi Inoue :
>>> I see now the following lines in libintl.h of version
>>> 0.18.1.1 which didn't exist in 0.17 version.
>>>
>>> The macro may cause a trouble especially on Wi
On Tue, Feb 1, 2011 at 07:56, Pavel Stehule wrote:
> 2011/2/1 Magnus Hagander :
>> On Tue, Feb 1, 2011 at 05:53, Pavel Stehule wrote:
>>> Hello
>>>
>>> There are broken links inside messages from commiters.
>>>
>>> projects /
>>>
>>>
>>> 404 - No such project
>>
>> Are you using gmail? They have
On Mon, 2011-01-31 at 20:52 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jan 31, 2011 at 7:25 PM, Tom Lane wrote:
> >> Robert Haas writes:
> >>> Seems a little weird to me, since the administrator hasn't done
> >>> anything.
>
> >> Sure he has: he issued the DROP DATABASE command th
On Tue, Feb 1, 2011 at 5:40 AM, Tom Lane wrote:
> AFAICT that would break on-disk compatibility of pg_trgm GIST indexes.
> I don't believe we have adequate evidence to justify doing that, and
> in any case it ought to be a separate patch rather than buried inside a
> mostly unrelated feature patc
On Mon, 2011-01-31 at 20:27 -0500, Robert Haas wrote:
> So I don't see why one particular kind of recovery conflict
> should be in a different class than all the others.
This point has been explained many times and is very clear in the code.
It has a clear functional purpose, not decoration or m
On Tue, Feb 1, 2011 at 5:36 AM, Itagaki Takahiro
wrote:
> 2011/1/27 Hiroshi Inoue :
>> I see now the following lines in libintl.h of version
>> 0.18.1.1 which didn't exist in 0.17 version.
>>
>> The macro may cause a trouble especially on Windows.
>> Attached is a patch to disable the macro on Win
69 matches
Mail list logo
