Pavel Stehule wrote:
Hello
I wrote a few functions for record type - record_expand,
record_get_fields, record_get_field, record_set_fields.
A usage of this functions is described in my blog
http://okbob.blogspot.com/2010/12/iteration-over-record-in-plpgsql.html
Do you think, so these functions
Hello
I wrote a few functions for record type - record_expand,
record_get_fields, record_get_field, record_set_fields.
A usage of this functions is described in my blog
http://okbob.blogspot.com/2010/12/iteration-over-record-in-plpgsql.html
Do you think, so these functions can be in core? These
* Vaibhav Kaushal (vaibhavkaushal...@gmail.com) wrote:
> I would like to do that (coding), but I do not have a SSD on my
> machine! :( Would it be impractical to try it for me? Again I do not
> know how to test PG :(
No, it's not a trivial amount of work. Perhaps someone will be curious
enough t
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Dec 10, 2010 at 10:33 PM, Tom Lane wrote:
> > Anybody have a problem with adopting this behavior?
>
> Seems a bit surprising.
Yeahh.. I'm not really sure about mkdir -p type actions from a SQL
command. Not entirely sure why but it doesn't
On Fri, 2010-12-10 at 23:19 -0500, Stephen Frost wrote:
> * Vaibhav Kaushal (vaibhavkaushal...@gmail.com) wrote:
> > I would like to do that (coding), but I do not have a SSD on my
> > machine! :( Would it be impractical to try it for me? Again I do not
> > know how to test PG :(
>
> No, it's not
On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote:
> On 12/10/10 5:06 PM, Daniel Loureiro wrote:
> > An quicksort method in
> > sequential disk its just awful to be thinking in a non SSD world, but
> > its possible in an SSD.
>
> So, code it. Shouldn't be hard to write a demo comparison. I do
On Fri, Dec 10, 2010 at 10:33 PM, Tom Lane wrote:
> I wrote:
>>> Basically, I'm thinking that given CREATE TABLESPACE LOCATION '/foo/bar'
>>> the creation and properties of /foo/bar/PG_9.0_201004261 ought to be
>>> handled *exactly* the way that the -D target directory of initdb is.
>
> One intere
I wrote:
>> Basically, I'm thinking that given CREATE TABLESPACE LOCATION '/foo/bar'
>> the creation and properties of /foo/bar/PG_9.0_201004261 ought to be
>> handled *exactly* the way that the -D target directory of initdb is.
One interesting point here is that initdb uses the equivalent of mkdi
On Fri, Dec 10, 2010 at 8:14 PM, Josh Berkus wrote:
>> I don't believe that extension SQL scripts should rely on DO blocks.
>> There is no requirement that plpgsql be installed, and we're not going
>> to create one as part of this feature. What this means is that the
>> design you offer above doe
On 12/10/10 5:06 PM, Daniel Loureiro wrote:
> An quicksort method in
> sequential disk its just awful to be thinking in a non SSD world, but
> its possible in an SSD.
So, code it. Shouldn't be hard to write a demo comparison. I don't
believe that SSDs make quicksort-on-disk feasible, but would b
On Fri, 2010-12-10 at 07:38 -0500, Robert Haas wrote:
> On Fri, Dec 10, 2010 at 1:39 AM, Vaibhav Kaushal
> wrote:
> > Most of you already know I am new to this list and newer to any OSS
> > development. However, while browsing the source code (of 9.0.1) I find
> > that there is only one way to sto
Tom,
> I don't believe that extension SQL scripts should rely on DO blocks.
> There is no requirement that plpgsql be installed, and we're not going
> to create one as part of this feature. What this means is that the
> design you offer above doesn't work at all, since it fundamentally
> assumes
> You can believe whatever you want, that doesn't make it true.
completely agree. Like yours, Its just my point of view, not the reality.
I agree with some points here, but I wondering how many good ideas are
killed with the thought: "this will be a performance killer with so
many random access, l
Tom,
> I'd much rather expect the extension author to explicitly support each
> pair of (from, to) version numbers that he's prepared to deal with.
> If he can build those update scripts as simple concatenations of
> single-step scripts, great; but let's not hard-wire the assumption that
> that ap
On Dec 10, 2010, at 4:39 PM, Tom Lane wrote:
> This idea is not exactly free of disadvantages.
>
> 1. It assumes that the underlying .so supports not only the current
> version, but every intermediate version of the SQL objects. For
> example, say the previously installed version was 1.10, and w
"David E. Wheeler" writes:
> On Dec 10, 2010, at 4:15 PM, Tom Lane wrote:
>> How do you select which upgrade script to apply?
> You run all those that contain version numbers higher than the
> currently-installed one.
> This of course assumes that one can correctly tell that one version number
Thanks alot for all the replies. Very helpful, really appreciate it.
- Original Message -
From: "Jeff Janes"
To: "Hamza Bin Sohail"
Cc:
Sent: Friday, December 10, 2010 7:18 PM
Subject: Re: [HACKERS] would hw acceleration help postgres (databases in
general) ?
On Fri, Dec 10, 2010
On Dec 10, 2010, at 4:34 PM, Cédric Villemain wrote:
>>> Other possibilities include TRANSIENT, EPHEMERAL, TRANSIENT, TENUOUS.
>>
>> EVANESCENT.
>
> UNSAFE ?
LOLZ.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
2010/12/8 Kineticode Billing :
> On Dec 8, 2010, at 10:37 AM, Chris Browne wrote:
>
>> Other possibilities include TRANSIENT, EPHEMERAL, TRANSIENT, TENUOUS.
>
> EVANESCENT.
UNSAFE ?
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Supp
On Fri, Dec 10, 2010 at 3:09 PM, Hamza Bin Sohail wrote:
>
> Hello hackers,
>
> I think i'm at the right place to ask this question.
>
> Based on your experience and the fact that you have written the Postgres code,
> can you tell what a rough break-down - in your opinion - is for the time the
> d
On Dec 10, 2010, at 4:15 PM, Tom Lane wrote:
>> Huh? It's in the pg_extension catalog.
>
> How do you select which upgrade script to apply?
You run all those that contain version numbers higher than the
currently-installed one.
This of course assumes that one can correctly tell that one versio
"David E. Wheeler" writes:
> On Dec 10, 2010, at 3:03 PM, Tom Lane wrote:
>>> Yeah, it should be *to* 1.12. FWIW, this is how Bricolage upgrade scripts
>>> are handled: version-string-named directories with the appropriate scripts
>>> to upgrade *to* the named version number.
>> But you still h
On 12/10/10 3:09 PM, Hamza Bin Sohail wrote:
> There is not much utility in doing this if there aren't considerable compute-
> intensive operations in the database (which i would be surprise if true ). I
> would suspect joins, complex queries etc may be very compute-intensive.
> Please
> correc
On 10.12.2010 21:21, Daniel Loureiro wrote:
The fact that it's called md.c is a hangover from the '80s. These days,
the logic that the Berkeley guys envisioned being at that code level
is generally in kernel device drivers. md.c can drive anything that
behaves as a block device + filesystem,
On Fri, Dec 10, 2010 at 3:13 PM, Joshua D. Drake wrote:
>
> Actually, the only (that I know of) optimized for sequential access code
> we have would be for the xlogs.
And even that is more of a book-keeping simplification, rather than an
optimization.
You have to know where to find the logically
>> Heck, even RAM isn't 1.0. I'm also involved with the Redis project,
>> which is an in-memory database. Even for a pure-RAM database, it turns
>> out that just using linked lists and 100% random access is slower than
>> accessing page images.
>
> That's a slightly different problem, though.
On Dec 10, 2010, at 3:03 PM, Tom Lane wrote:
>> Yeah, it should be *to* 1.12. FWIW, this is how Bricolage upgrade scripts
>> are handled: version-string-named directories with the appropriate scripts
>> to upgrade *to* the named version number.
>
> But you still have to know what you're upgradi
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Hamza Bin Sohail
> Sent: Friday, December 10, 2010 3:10 PM
> To: pgsql-hackers@postgresql.org
> Subject: [HACKERS] would hw acceleration help postgres (databases in
>
On Fri, Dec 10, 2010 at 6:08 PM, Josh Berkus wrote:
> Heck, even RAM isn't 1.0. I'm also involved with the Redis project,
> which is an in-memory database. Even for a pure-RAM database, it turns
> out that just using linked lists and 100% random access is slower than
> accessing page images.
Th
On Fri, 2010-12-10 at 15:08 -0800, Josh Berkus wrote:
> > I believe that PostgreSQL was been developed and optimized for
> > sequential access. To get full advantage of SSDs its necessary to
> > rewrite almost the whole project - there are so much code written with
> > the sequential mechanism in m
Hello hackers,
I think i'm at the right place to ask this question.
Based on your experience and the fact that you have written the Postgres code,
can you tell what a rough break-down - in your opinion - is for the time the
database spends time just "fetching and writing " stuff to memory and
On 12/10/2010 06:01 PM, Tom Lane wrote:
Robert Haas writes:
+1 for src/port.
...
At the moment, I'm not feeling hot to back-patch this.
Yeah, that squares with my feelings. Will go do it that way,
unless other people object.
I think this is the sensible way to go
> I believe that PostgreSQL was been developed and optimized for
> sequential access. To get full advantage of SSDs its necessary to
> rewrite almost the whole project - there are so much code written with
> the sequential mechanism in mind.
You can believe whatever you want, that doesn't make it
"David E. Wheeler" writes:
> Yeah, it should be *to* 1.12. FWIW, this is how Bricolage upgrade scripts are
> handled: version-string-named directories with the appropriate scripts to
> upgrade *to* the named version number.
But you still have to know what you're upgrading *from*.
If we use sub
Robert Haas writes:
> +1 for src/port.
> ...
> At the moment, I'm not feeling hot to back-patch this.
Yeah, that squares with my feelings. Will go do it that way,
unless other people object.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On Dec 10, 2010, at 2:58 PM, Tom Lane wrote:
> Maybe I misread David's meaning, but I thought he was saying that
> there's no value in inventing all those control file entries in the
> first place. Just hard-wire in ALTER EXTENSION UPGRADE the convention
> that the name of an upgrade script to up
On Dec 10, 2010, at 2:55 PM, Dimitri Fontaine wrote:
> Tom Lane writes:
>> If we assume the target is the current version, then we only need the
>> old-version number in the file name, so it doesn't matter how many
>> parts it has.
>
> IIUC, that puts even more work on the shoulders of the exten
Dimitri Fontaine writes:
> "David E. Wheeler" writes:
>> You keep making extension authors have to do more work. I keep trying
>> to make it so they can do less. We want the barrier to be as low as
>> possible, which means a lot of DRY. Make it *possible* to do more
>> complicated things, but don
Tom Lane writes:
> If we assume the target is the current version, then we only need the
> old-version number in the file name, so it doesn't matter how many
> parts it has.
IIUC, that puts even more work on the shoulders of the extension
authors, because the file named foo-1.12.sql is the one us
On Fri, Dec 10, 2010 at 3:26 PM, Tom Lane wrote:
> I'm finally getting around to something that's been on my todo list for
> a couple of months.
>
> I wrote:
>> Basically, I'm thinking that given CREATE TABLESPACE LOCATION '/foo/bar'
>> the creation and properties of /foo/bar/PG_9.0_201004261 ough
On Dec 10, 2010, at 2:43 PM, Dimitri Fontaine wrote:
> "David E. Wheeler" writes:
>> You keep making extension authors have to do more work. I keep trying
>> to make it so they can do less. We want the barrier to be as low as
>> possible, which means a lot of DRY. Make it *possible* to do more
>>
Jeff Janes writes:
> Of course if you do a full table scan because their are no better
> options, then it scans sequentially. But you have to scan the pages
> in *some* order, and it is hard to see how something other than
> sequential would be systematically better.
In fact, if sequential *isn'
On Dec 10, 2010, at 2:40 PM, Tom Lane wrote:
>> Since you know the existing version number, you just run all that come
>> after. For example, if the current version is 1.12, then you know to run
>> foo-1.13.sql and foo-1.15.sql.
>
> If we assume the target is the current version, then we only n
Josh Berkus writes:
> I'd say that for anything in /contrib, it gets a new version with each
> major version of postgresql, but not with each minor version. Thus,
> say, dblink when 9.1.0 is release would be dblink 9.1-1. If in 9.1.4 we
> fix a bug in dblink, then it becomes dblink 9.1-2.
> ...
"David E. Wheeler" writes:
> You keep making extension authors have to do more work. I keep trying
> to make it so they can do less. We want the barrier to be as low as
> possible, which means a lot of DRY. Make it *possible* to do more
> complicated things, but don't *require* it.
Sorry, imposin
"David E. Wheeler" writes:
> On Dec 10, 2010, at 1:50 PM, Dimitri Fontaine wrote:
> (Actually, we could probably assume that the target version is
> implicitly "the current version", as identified from the control file,
> and omit that from the script file names. That would avoid ambiguity
> if v
On Dec 10, 2010, at 2:32 PM, Dimitri Fontaine wrote:
> "David E. Wheeler" writes:
>> On Dec 10, 2010, at 1:50 PM, Dimitri Fontaine wrote:
>>> I don't think we can safely design around one part version numbers here,
>>> because I'm yet to see that happening in any extension I've had my hands
>>> o
"David E. Wheeler" writes:
> On Dec 10, 2010, at 1:50 PM, Dimitri Fontaine wrote:
>> I don't think we can safely design around one part version numbers here,
>> because I'm yet to see that happening in any extension I've had my hands
>> on, which means a few already, as you can imagine.
>
> Why no
On Dec 10, 2010, at 1:50 PM, Dimitri Fontaine wrote:
>> (Actually, we could probably assume that the target version is
>> implicitly "the current version", as identified from the control file,
>> and omit that from the script file names. That would avoid ambiguity
>> if version numbers can have m
On Dec 10, 2010, at 1:55 PM, Josh Berkus wrote:
> I'd say that for anything in /contrib, it gets a new version with each
> major version of postgresql, but not with each minor version. Thus,
> say, dblink when 9.1.0 is release would be dblink 9.1-1. If in 9.1.4 we
> fix a bug in dblink, then it
On Fri, Dec 10, 2010 at 12:21 PM, Daniel Loureiro wrote:
>>> Most of you already know I am new to this list and newer to any OSS
>>> development. However, while browsing the source code (of 9.0.1) I find
>>> that there is only one way to store relations on disk - the magnetic
>>> disk.
>
>>The fac
On Fri, Dec 10, 2010 at 4:50 PM, Dimitri Fontaine
wrote:
> Now, what about having the control file host an 'upgrade' property where
> to put the script name? We would have to support a way for this filename
> to depend on the already installed version, I'm thinking that %v might
> be the easiest
Josh Berkus writes:
> The alternative would be to match postgresql minor version numbering
> exactly, and then come up with some way to have a "no-op" upgrade in the
> frequent cases where the contrib module isn't changed during a minor
> release. This would also require some kind of "upgrade all
On 12/10/10 12:34 PM, Dimitri Fontaine wrote:
> Josh Berkus writes:
>> I think that each contrib needs its own version numbers. The reason
>> being that most minor updates don't touch contrib.
>
> Fair enough. What are the version numbers of each current contribs?
I'd say that for anything in /
Tom Lane writes:
> I don't believe that extension SQL scripts should rely on DO blocks.
> There is no requirement that plpgsql be installed, and we're not going
> to create one as part of this feature. What this means is that the
> design you offer above doesn't work at all, since it fundamentall
"Joshua D. Drake" writes:
> On Fri, 2010-12-10 at 15:42 -0500, Andrew Dunstan wrote:
>> On 12/10/2010 03:24 PM, Josh Berkus wrote:
>>> Also, once extensions and pgxn are operating full swing, I see contrib
>>> going away anyway ...
>> We've heard this before, but I'm still quite skeptical about i
Dimitri Fontaine writes:
> On to your question about the upgrade design, in order not to paint
> ourselves into a corner. What I now have in mind is the following:
> When there's an extension upgrade the user will have to install the new
> files (.so, .sql, .control) and run an upgrade command in
On Fri, 2010-12-10 at 15:42 -0500, Andrew Dunstan wrote:
>
> On 12/10/2010 03:24 PM, Josh Berkus wrote:
> >
> > Also, once extensions and pgxn are operating full swing, I see contrib
> > going away anyway ...
>
> We've heard this before, but I'm still quite skeptical about it. Quite
> apart from
On 12/10/2010 03:24 PM, Josh Berkus wrote:
Also, once extensions and pgxn are operating full swing, I see contrib
going away anyway ...
We've heard this before, but I'm still quite skeptical about it. Quite
apart from anything else we should keep enough extensions in core to
test the exten
Josh Berkus writes:
> I think that each contrib needs its own version numbers. The reason
> being that most minor updates don't touch contrib.
Fair enough. What are the version numbers of each current contribs?
> Also, once extensions and pgxn are operating full swing, I see contrib
> going awa
Josh Berkus writes:
> On 12/10/10 12:17 PM, Dimitri Fontaine wrote:
>> Or do we want contrib's specific version numbers that are not all the
>> same as the current PostgreSQL version number?
> I think that each contrib needs its own version numbers. The reason
> being that most minor updates don
On 12/04/2010 11:11 PM, Itagaki Takahiro wrote:
On Sun, Dec 5, 2010 at 07:24, Andrew Dunstan wrote:
Looking at file_parser.c, it seems to be largely taken from copy.c. Wouldn't
it be better to call those functions, or refactor them so they are callable
if necessary?
We could export private f
I'm finally getting around to something that's been on my todo list for
a couple of months.
I wrote:
> Basically, I'm thinking that given CREATE TABLESPACE LOCATION '/foo/bar'
> the creation and properties of /foo/bar/PG_9.0_201004261 ought to be
> handled *exactly* the way that the -D target dire
On 12/10/10 12:17 PM, Dimitri Fontaine wrote:
> Or do we want contrib's specific version numbers that are not all the
> same as the current PostgreSQL version number?
I think that each contrib needs its own version numbers. The reason
being that most minor updates don't touch contrib.
Also, once
>> Most of you already know I am new to this list and newer to any OSS
>> development. However, while browsing the source code (of 9.0.1) I find
>> that there is only one way to store relations on disk - the magnetic
>> disk.
>The fact that it's called md.c is a hangover from the '80s. These days
Tom Lane writes:
> Why would you choose to maintain it in the Makefile? In most cases
> makefiles are the least likely thing to be changing during a minor
> update.
I must have a packager skewed view of things here, but ok, point noted.
> I would think that the right place for it is in the C c
On Dec 10, 2010, at 11:47 AM, Tom Lane wrote:
> Why would you choose to maintain it in the Makefile? In most cases
> makefiles are the least likely thing to be changing during a minor
> update. I would think that the right place for it is in the C code
> (if we're trying to version .so files) or
Dimitri Fontaine writes:
> Tom Lane writes:
>> This doesn't answer my question of why it couldn't be done the other
>> way. Why does the makefile need to know it? If it does need to know
>> it, couldn't it get it out of the control file instead of vice versa?
> Well the Makefile support is jus
"David E. Wheeler" writes:
> On Dec 10, 2010, at 11:28 AM, Dimitri Fontaine wrote:
>> Upgrade are left for a future patch, did we decide. Still, it seems to
>> me that we will support some upgrade scripts so that author can decide
>> what to do knowing current and next version, and yes, knowing th
On Dec 10, 2010, at 11:28 AM, Dimitri Fontaine wrote:
> Well the Makefile support is just a facility to fill in the control file
> automatically for you, on the grounds that you're probably already
> maintaining your version number in the Makefile. Or that it's easy to
> get it there, as in:
>
>
On 12/10/2010 11:19 AM, Tom Lane wrote:
> Robert Haas writes:
>> So in theory we could have a GUC under "file locations" to override
>> this, similarly to data_directory or hba_file or ident_file. But
>> since it's been like this for a really long time (I think), I wouldn't
>> be inclined to go m
Tom Lane writes:
> This doesn't answer my question of why it couldn't be done the other
> way. Why does the makefile need to know it? If it does need to know
> it, couldn't it get it out of the control file instead of vice versa?
Well the Makefile support is just a facility to fill in the contr
On Dec 10, 2010, at 10:20 AM, Tom Lane wrote:
> True. Consider a situation like an RPM upgrade: it's going to drop in a
> new .so version, *and nothing else*. It's pure fantasy to imagine that
> the RPM script is going to find all your databases and execute some SQL
> commands against them. Sin
Robert Haas writes:
> On Fri, Dec 10, 2010 at 12:30 PM, Tom Lane wrote:
>> ... In particular, keeping the
>> version number in the system catalogs seems pretty dubious. The common
>> method for upgrading an already-installed contrib module just involves
>> dropping in a new .so --- that's not go
On Fri, Dec 10, 2010 at 12:30 PM, Tom Lane wrote:
> I'm not convinced that this is actually a requirement, or that doing it
> this specific way is a good solution. In particular, keeping the
> version number in the system catalogs seems pretty dubious. The common
> method for upgrading an alread
Hitoshi Harada writes:
> Hm? Once percent_rank() scans to the partition end, any other window
> functions that scans row by row don't need to care the memory
> reduction, aren't they? Or more generally, if the partition was
> scanned to the end, we don't need to trim tuplestore anymore. Am I
> mis
On 12/10/2010 11:19 AM, Tom Lane wrote:
Robert Haas writes:
So in theory we could have a GUC under "file locations" to override
this, similarly to data_directory or hba_file or ident_file. But
since it's been like this for a really long time (I think), I wouldn't
be inclined to go monkeying
2010/12/10 Robert Haas
> On Fri, Dec 10, 2010 at 11:46 AM, Dmitriy Igrishin
> wrote:
> > It would be quicker to answer my question and help than to teach me
> > the alphabet of communication. Although, thank you, and for that :-)
>
> It would be quicker still to ignore your email altogether, but
On Thu, Dec 09, 2010 at 09:48:25AM +, Simon Riggs wrote:
> On Fri, 2010-12-03 at 21:43 +0200, Heikki Linnakangas wrote:
> > On 29.11.2010 08:10, Noah Misch wrote:
> > > I have a hot_standby system and use it to bear the load of various
> > > reporting
> > > queries that take 15-60 minutes each
3. Shutdown should abort all the blocking transactions?
* Problem is that a client thinks that those transactions have been
aborted
even though those WAL records have been written on the master. But
this is very common problem for DBMS, so we don't need to worry about
2010/12/11 Tom Lane :
> Hitoshi Harada writes:
>> I see it's too late now that you've committed it,
>
> Patches can always be reverted...
>
>> but it seems there
>> was another way to avoid it by not trimming from percent_rank()
>> individually. Once the whole partition is fit to the memory, you d
On Fri, Dec 10, 2010 at 11:46 AM, Dmitriy Igrishin wrote:
> It would be quicker to answer my question and help than to teach me
> the alphabet of communication. Although, thank you, and for that :-)
It would be quicker still to ignore your email altogether, but I'm
guessing you're not going to re
Hitoshi Harada writes:
> I see it's too late now that you've committed it,
Patches can always be reverted...
> but it seems there
> was another way to avoid it by not trimming from percent_rank()
> individually. Once the whole partition is fit to the memory, you don't
> need to trim it since it
2010/12/10 Tom Lane :
> I wrote:
>> We're throwing away one tuple at a time as we advance forward through
>> the tuplestore, and moving 10+ tuple pointers each time. Ugh.
>> This code was all right when written, because (IIRC) the mergejoin
>> case was actually the only caller. But it's not a
On Dec 10, 2010, at 7:32 AM, Tom Lane wrote:
> Are there any actual remaining use-cases for that sed step? It's
> certainly vestigial as far as the contrib modules are concerned:
> it would be simpler and more readable to replace MODULE_PATHNAME with
> $libdir in the sources. Unless somebody can
On Dec 10, 2010, at 12:26 AM, Dimitri Fontaine wrote:
> What if $extension.control exists? Is it a byproduct of the .in file
> from previous `make` run or a user file? What if we have both the .in
> and the make variable because people are confused? Or both the make
> variables and a .control and
Dimitri Fontaine writes:
> Tom Lane writes:
>> Why is it in the makefile at all? If the makefile does need to know it,
>> why don't we have it scrape the number out of the control file? Or even
>> more to the point, since when do we need version numbers in extensions?
> It's in the Makefile so
Hey Kevin,
Oh, I am sorry! Thanks!
2010/12/10 Kevin Grittner
> Dmitriy Igrishin wrote:
>
> > Where is it written ?
>
>
> http://wiki.postgresql.org/wiki/Guide_to_reporting_problems#Things_Not_To_Do
>
> -Kevin
>
>
--
// Dmitriy.
Dmitriy Igrishin wrote:
> Where is it written ?
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems#Things_Not_To_Do
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera writes:
> Excerpts from Jeff Janes's message of vie dic 10 12:24:34 -0300 2010:
>> As far as I can tell, bgwriter never adds things to the freelist.
>> That is only done at start up, and when a relation or a database is
>> dropped. The clock sweep does the vast majority of the work
Hey Robert,
2010/12/10 Robert Haas
> On Fri, Dec 10, 2010 at 2:53 AM, Dmitriy Igrishin
> wrote:
> > [ message that was forwarded to three mailing lists in an 12 hour period
> ]
>
> Come on, give me a break!
Please sorry ! But I don't mail to you personally.
> How quickly do you expect people
Excerpts from Jeff Janes's message of vie dic 10 12:24:34 -0300 2010:
> On Fri, Dec 10, 2010 at 5:45 AM, Alvaro Herrera
> wrote:
> > Excerpts from Jim Nasby's message of jue dic 09 16:54:24 -0300 2010:
> >> To do that I think we'd want the bgwriter to target there being X number
> >> of buffers
Tom Lane writes:
> Why is it in the makefile at all? If the makefile does need to know it,
> why don't we have it scrape the number out of the control file? Or even
> more to the point, since when do we need version numbers in extensions?
It's in the Makefile so that you find it in the control
Dimitri Fontaine writes:
> Tom Lane writes:
>> Are there any actual remaining use-cases for that sed step?
> The goal here is to allow extension authors to maintain their version
> number in the Makefile rather than in the Makefile and in the control
> file separately. Having the same version nu
Robert Haas writes:
> So in theory we could have a GUC under "file locations" to override
> this, similarly to data_directory or hba_file or ident_file. But
> since it's been like this for a really long time (I think), I wouldn't
> be inclined to go monkeying with it unless more than one person
>
On Fri, Dec 10, 2010 at 2:53 AM, Dmitriy Igrishin wrote:
> [ message that was forwarded to three mailing lists in an 12 hour period ]
Come on, give me a break! How quickly do you expect people to answer
your questions? It's reasonable to follow up if you haven't heart
anything in a few days, bu
On Fri, Dec 10, 2010 at 10:54 AM, Andrew Dunstan wrote:
> Here's my understanding.
>
> It's not initdb that's really complaining. The timezone files are not inputs
> to initdb. It's the postgres that initdb invokes that's complaining.
That was my impression, too, from the log that was sent.
> Po
On 12/10/2010 10:25 AM, Andrew Dunstan wrote:
Not claiming any knowledge in this area - would it be
reasonable to expect that if -L option works for other input files
it should
also work for timezones?
...this seems reasonable.
OK, this has nothing at all to do with the abs
Tom Lane writes:
> Are there any actual remaining use-cases for that sed step?
The goal here is to allow extension authors to maintain their version
number in the Makefile rather than in the Makefile and in the control
file separately. Having the same version number in more than one place
never e
Dimitri Fontaine writes:
> "David E. Wheeler" writes:
>>> What if $extension.control exists? Is it a byproduct of the .in file
>>> from previous `make` run or a user file? What if we have both the .in
>>> and the make variable because people are confused? Or both the make
>>> variables and a .con
1 - 100 of 115 matches
Mail list logo
