On Thu, 2011-02-17 at 13:38 +0900, Fujii Masao wrote:
> On Thu, Feb 17, 2011 at 4:30 AM, Simon Riggs wrote:
> > Hot Standby feedback for avoidance of cleanup conflicts on standby.
> > Standby optionally sends back information about oldestXmin of queries
> > which is then checked and applied to the
On Wed, Feb 16, 2011 at 12:21, Alvaro Herrera
wrote:
> Excerpts from Tim Bunce's message of mié feb 16 14:08:11 -0300 2011:
>> I'd suggest encode_typed_literal() as a better name.
>
> FYI I'm looking at this patch (v10), and I'll incorporate Tim's suggestion.
Looks good to me.
--
Sent via pgsql
On Wed, Feb 16 2011, Tom Lane wrote:
> Stephen Frost writes:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> In particular, getting rid of use of OpenSSL would not be sufficient
>>> to satisfy the most rabid GPL partisans that we were in compliance.
>
>> I've never heard anyone argue that position,
Jason,
* Jason Earl (je...@notengoamigos.org) wrote:
> Or he could just read this essay from the FSF website:
Which is all about the GPL's "can't be *more* restrictive"
requirement. That doesn't apply in this case, sorry. Reading back
through the thread from December of 2000, I see the same was
* Bruce Momjian (br...@momjian.us) wrote:
> Joshua D. Drake wrote:
> > Probably readline but does it matter? We distribute the source to the
> > click installers.
>
> Well, there is what the community is risking, and there is what the
> packagers are risking. Ideally we would make the job easier
YAMAMOTO Takashi wrote:
> with your previous patch or not?
With, thanks.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
>> Not sure. Do you have a link to the archives, or any idea when this
>> discussion occurred/what the subject line was?
>
> They presented at PgCon a couple of years in a row, iirc..
>
> http://www.pgcon.org/2007/schedule/events/16.en.html
Yes, this one. On page 18, they talked about their cus
Joshua D. Drake wrote:
> On Wed, 2011-02-16 at 22:53 -0500, Bruce Momjian wrote:
> > Stephen Frost wrote:
> > -- Start of PGP signed section.
> > > * Greg Stark (gsst...@mit.edu) wrote:
> > > > Well for what it's worth we want to support both. At least the project
> > > > philosophy has been that c
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Feb 16, 2011 at 11:13 PM, Tatsuo Ishii wrote:
> > I vaguely recall that UNISYS used to present patches to reduce the WAL
> > buffer lock contention and enhanced the CPU scalability limit from 12
> > to 16 or so(if my memory serves). Your secon
On Thu, Feb 17, 2011 at 4:30 AM, Simon Riggs wrote:
> Hot Standby feedback for avoidance of cleanup conflicts on standby.
> Standby optionally sends back information about oldestXmin of queries
> which is then checked and applied to the WALSender's proc->xmin.
> GetOldestXmin() is modified slightl
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> In particular, getting rid of use of OpenSSL would not be sufficient
>> to satisfy the most rabid GPL partisans that we were in compliance.
> I've never heard anyone argue that position, don't believe anyone would,
> and certainly
On Wed, 2011-02-16 at 22:53 -0500, Bruce Momjian wrote:
> Stephen Frost wrote:
> -- Start of PGP signed section.
> > * Greg Stark (gsst...@mit.edu) wrote:
> > > Well for what it's worth we want to support both. At least the project
> > > philosophy has been that commercial derivatives are expected
On Wed, Feb 16, 2011 at 11:13 PM, Tatsuo Ishii wrote:
> I vaguely recall that UNISYS used to present patches to reduce the WAL
> buffer lock contention and enhanced the CPU scalability limit from 12
> to 16 or so(if my memory serves). Your second idea is somewhat related
> to the patches?
Not sur
Robert Haas wrote:
> On Wed, Jul 21, 2010 at 11:06 PM, David Christensen
> wrote:
> >
> > On Jul 21, 2010, at 12:31 PM, Alvaro Herrera wrote:
> >
> >> Excerpts from Peter Eisentraut's message of mi? jul 21 10:24:26 -0400 2010:
> >>> On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote:
> It'
> I've been thinking about the problem of $SUBJECT, and while I know
> it's too early to think seriously about any 9.2 development, I want to
> get my thoughts down in writing while they're fresh in my head.
>
> It seems to me that there are two basic approaches to this problem.
> We could either
I've been thinking about the problem of $SUBJECT, and while I know
it's too early to think seriously about any 9.2 development, I want to
get my thoughts down in writing while they're fresh in my head.
It seems to me that there are two basic approaches to this problem.
We could either split up the
Stephen Frost wrote:
-- Start of PGP signed section.
> * Greg Stark (gsst...@mit.edu) wrote:
> > Well for what it's worth we want to support both. At least the project
> > philosophy has been that commercial derivatives are expected and
> > acceptable so things like EDB's products, or Greenplums, o
YAMAMOTO Takashi wrote:
> might be unrelated to the loop problem, but...
Aha! I think it *is* related. There were several places where data
was uninitialized here; mostly because Dan was working on this piece
while I was working on separate issues which added the new fields.
I missed the int
COPY ENCODING patch was returned with feedback,
https://commitfest.postgresql.org/action/patch_view?id=501
but we still need it for file_fdw. Using client_encoding at runtime
is reasonable for one-time COPY command, but logically nonsense for
persistent file_fdw tables.
Base on the latest patch
* Greg Stark (gsst...@mit.edu) wrote:
> Perhaps we should make configure print a warning for each
> non-Postgres-license software it's being configured to use with a
> pointer to the license for the configured. That might make it more
> obvious to people that while Postges is licensed under a given
* Greg Stark (gsst...@mit.edu) wrote:
> Well for what it's worth we want to support both. At least the project
> philosophy has been that commercial derivatives are expected and
> acceptable so things like EDB's products, or Greenplums, or for that
> matter Pokertracker's all include other propriet
On Thu, Feb 17, 2011 at 3:16 AM, Bruce Momjian wrote:
>> Well for what it's worth we want to support both. At least the project
>> philosophy has been that commercial derivatives are expected and
>> acceptable so things like EDB's products, or Greenplums, or for that
>> matter Pokertracker's all i
* Bruce Momjian (br...@momjian.us) wrote:
> Joshua D. Drake wrote:
> > > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > > In particular, getting rid of use of OpenSSL would not be sufficient
> > > > to satisfy the most rabid GPL partisans that we were in compliance.
> > >
> > > I've never heard anyo
Tom Lane wrote:
> I wrote:
> > In particular, now that there's a distinction between smgr flush
> > and relcache flush, maybe we could associate targblock reset with
> > smgr flush (only) and arrange to not flush the smgr level during
> > ANALYZE --- basically, smgr flush would only be needed when
Greg Stark wrote:
> On Thu, Feb 17, 2011 at 1:53 AM, Stephen Frost wrote:
> > I agree w/ the other responses to this, in particular from Stark, but I
> > just wanted to point out that we're much more likely to come across
> > other GPL-licensed things that we want to support linking against (and
>
Greg Stark wrote:
> On Thu, Feb 17, 2011 at 12:39 AM, Tom Lane wrote:
> > In particular, getting rid of use of OpenSSL would not be sufficient
> > to satisfy the most rabid GPL partisans that we were in compliance.
>
> Huh?
>
> In what way would we not be in compliance? Or rather, what part of t
Joshua D. Drake wrote:
> On Wed, 2011-02-16 at 20:53 -0500, Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > In particular, getting rid of use of OpenSSL would not be sufficient
> > > to satisfy the most rabid GPL partisans that we were in compliance.
> >
> > I've never heard
On Thu, Feb 17, 2011 at 1:53 AM, Stephen Frost wrote:
> I agree w/ the other responses to this, in particular from Stark, but I
> just wanted to point out that we're much more likely to come across
> other GPL-licensed things that we want to support linking against (and
> who might link against us
* Robert Haas (robertmh...@gmail.com) wrote:
> Ah, so it does. Sounds like you win. Have we a patch implementing
> the sounds-like-its-agreed change, then?
Patch attached, rebased to current master. Full git log:
Thanks,
Stephen
commit 47eebe20deb5da56ea6eb413ee801108
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Feb 16, 2011 at 8:58 PM, Stephen Frost wrote:
> > This list appears to miss out on
> > 8217cfbd991856d25d73b0f7afcf43d99f90b653 ..?
>
> Ah, so it does. Sounds like you win. Have we a patch implementing
> the sounds-like-its-agreed change, t
On Wed, Feb 16, 2011 at 8:58 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> CSV log files were introduced in 8.3.0 by commit
>> fd801f4faa8e0f00bc314b16549e3d8e8aa1b653. There are several follow-on
>> commits making adjustments, but they all appear to be 8.3-vintage:
>
On Wed, 2011-02-16 at 20:53 -0500, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > In particular, getting rid of use of OpenSSL would not be sufficient
> > to satisfy the most rabid GPL partisans that we were in compliance.
>
> I've never heard anyone argue that position, don't b
On Thu, Feb 10, 2011 at 10:40 AM, Steve Singer wrote:
> On 11-02-10 10:32 AM, Robert Haas wrote:
>> I was assuming those changes were sufficiently trivial that they could
>> be made at commit-time, especially if Peter is committing it himself.
>> Of course if he'd like a re-review, he can always p
* Robert Haas (robertmh...@gmail.com) wrote:
> CSV log files were introduced in 8.3.0 by commit
> fd801f4faa8e0f00bc314b16549e3d8e8aa1b653. There are several follow-on
> commits making adjustments, but they all appear to be 8.3-vintage:
>
> 230e8962f3a47cae4729ad7c017410d28caf1370
> 3bf66d6f1c3a8
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> In particular, getting rid of use of OpenSSL would not be sufficient
> to satisfy the most rabid GPL partisans that we were in compliance.
I've never heard anyone argue that position, don't believe anyone would,
and certainly don't agree with it.
> Whereas
On 02/16/2011 08:38 PM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I can't remember at the moment: have we changed the CSV format in any
releases since it was first created? And if so, did anyone complain?
It was changed between 8.4 and 9.0 (application_name was added). I'v
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I can't remember at the moment: have we changed the CSV format in any
> releases since it was first created? And if so, did anyone complain?
It was changed between 8.4 and 9.0 (application_name was added). I've
looked around a bit in the archives w/ googl
On Wed, Feb 16, 2011 at 7:42 PM, Tom Lane wrote:
> Robert Haas writes:
On Tue, Feb 15, 2011 at 1:02 PM, Stephen Frost wrote:
> I believe the suggestion that Robert and I were talking about above was
> to just unilatterally change the CSV log file output format to include
> curre
On Thu, Feb 17, 2011 at 12:39 AM, Tom Lane wrote:
> In particular, getting rid of use of OpenSSL would not be sufficient
> to satisfy the most rabid GPL partisans that we were in compliance.
Huh?
In what way would we not be in compliance? Or rather, what part of the
GPL would we be unable to com
On Wed, Feb 16, 2011 at 7:25 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > On Wed, Feb 16, 2011 at 10:26 AM, Tom Lane wrote:
> >> Yeah, hypothetical is the more-established term I think.
>
> > Please find the patch attached.
>
> Applied with minor adjustments to HEAD and 9.0.
>
Thanks Tom.
-
On Thu, Feb 17, 2011 at 2:39 AM, Tom Lane wrote:
> Greg Smith writes:
>> I find it hard to get excited about working to replace the software that
>> has a reasonable license here (readline) rather than trying to eliminate
>> dependence on the one with an unreasonable license (OpenSSL).
>
> Hm?
>
Greg Stark writes:
> On Thu, Feb 17, 2011 at 12:07 AM, Greg Smith wrote:
>> There appear to be two people working periodically on the upstream NetBSD
>> libedit: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/?sortby=date
>>
>> And a third who periodically packages that at
>> http://www.
On 17 February 2011 00:48, Tom Lane wrote:
> Thom Brown writes:
>> For my benefit, could you explain how ishypothetical gets set to true?
>
> In the core, it never does. An index advisor plugin would set it in
> IndexOptInfo structs that it makes.
I get the idea. Thanks Tom.
--
Thom Brown
Tw
Thom Brown writes:
> For my benefit, could you explain how ishypothetical gets set to true?
In the core, it never does. An index advisor plugin would set it in
IndexOptInfo structs that it makes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On 16 February 2011 23:02, Gurjeet Singh wrote:
> On Wed, Feb 16, 2011 at 10:26 AM, Tom Lane wrote:
>>
>> Gurjeet Singh writes:
>> > BTW, you use the term 'fictitious' in the comments, would it be
>> > better
>> > to standardize the term used for such an index? So either the comment
>> > wou
Robert Haas writes:
>>> On Tue, Feb 15, 2011 at 1:02 PM, Stephen Frost wrote:
I believe the suggestion that Robert and I were talking about above was
to just unilatterally change the CSV log file output format to include
current_role. No header lines, no variable output format, et
Greg Smith writes:
> I find it hard to get excited about working to replace the software that
> has a reasonable license here (readline) rather than trying to eliminate
> dependence on the one with an unreasonable license (OpenSSL).
Hm?
The trouble with readline is that it's GPL, not LGPL, and
On Thu, 2011-02-17 at 00:28 +, Greg Stark wrote:
> On Thu, Feb 17, 2011 at 12:07 AM, Greg Smith wrote:
>
> > There appear to be two people working periodically on the upstream NetBSD
> > libedit: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/?sortby=date
> >
> > And a third who period
On Thu, Feb 17, 2011 at 12:07 AM, Greg Smith wrote:
> There appear to be two people working periodically on the upstream NetBSD
> libedit: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/?sortby=date
>
> And a third who periodically packages that at http://www.thrysoee.dk/editline/
I'm rea
Gurjeet Singh writes:
> On Wed, Feb 16, 2011 at 10:26 AM, Tom Lane wrote:
>> Yeah, hypothetical is the more-established term I think.
> Please find the patch attached.
Applied with minor adjustments to HEAD and 9.0.
regards, tom lane
--
Sent via pgsql-hackers mailing
On 17/02/11 04:23, Tom Lane wrote:
> Florian Pflug writes:
>> Hm, I've browsed through the code and it seems that the current behaviour
>> was implemented on purpose.
>
> Yes, it's 100% intentional. The idea is to allow function authors to
> use OUT-parameter notation (in particular, the conven
On Wed, Feb 16, 2011 at 5:55 PM, Andrew Dunstan wrote:
> On 02/16/2011 04:24 PM, Robert Haas wrote:
>>
>> On Tue, Feb 15, 2011 at 1:02 PM, Stephen Frost wrote:
>>>
>>> * Andrew Dunstan (and...@dunslane.net) wrote:
On 02/15/2011 11:13 AM, Stephen Frost wrote:
>
> Think I suggeste
Andrew Dunstan wrote:
You're assuming a fact not in evidence, namely the existence of an
identifiable group of "libedit folks". Last time I looked there was no
such group.
There appear to be two people working periodically on the upstream
NetBSD libedit:
http://cvsweb.netbsd.org/bsdweb.cgi/
Gurjeet Singh writes:
> On Wed, Feb 16, 2011 at 10:25 AM, Tom Lane wrote:
>> The only reason you'd need that code is if you were trying to construct
>> a fake Relation structure, which seems unnecessary and undesirable.
> The planner requires IndexOptInfo, and for the planner to choose the
> hyp
Andrew Dunstan writes:
> On 02/16/2011 12:29 PM, Bruce Momjian wrote:
>> Can someone take ownership of this, get involved with the libedit folks,
>> get Debian to use their fixes, and solve this problem for us?
> You're assuming a fact not in evidence, namely the existence of an
> identifiable g
On 02/16/2011 09:07 AM, Marti Raudsepp wrote:
On Wed, Feb 16, 2011 at 18:03, Thom Brown wrote:
For the number of fortnights, that becomes:
select extract(epoch from now() - '2010-01-01 11:45:13'::timestamp)/60/60/24/14;
You'd think with PostgreSQL having such a rich type system, it
wouldn't n
On Feb 16, 2011, at 3:00 PM, Tom Lane wrote:
> According to our prior discussions of C.O.R. commands, the general
> principle that such a command ought to follow is that upon success,
> the object exists with exactly the properties implied by the command's
> arguments. So (1) if the extension isn
YAMAMOTO Takashi wrote:
> might be unrelated to the loop problem, but...
>
> i got the following SEGV when runnning vacuum on a table.
> vacuum on the table succeeded with the attached patch.
Thanks! I appreciate the heavy testing and excellent diagnostics.
On the face of it, this doesn't
Dimitri Fontaine writes:
> Tom Lane writes:
>> Fix corner case for binary upgrade: extension functions in pg_catalog.
> Do we only want to care about functions here?
Yes. Functions/aggregates are the only object type where pg_dump tries
to suppress fetching any information at all about system-
Dimitri Fontaine writes:
> Tom Lane writes:
>> [ scratches head ... ] Why is your version generating so many
>> unnecessary @extschema@ uses?
> I just ran create table tomlist as select your query and create table
> dimlist as select my query, then:
> ...
> No difference on @extschema@ use here
On Wed, Feb 16, 2011 at 10:26 AM, Tom Lane wrote:
> Gurjeet Singh writes:
> > BTW, you use the term 'fictitious' in the comments, would it be
> better
> > to standardize the term used for such an index? So either the comment
> would
> > be changed to call it hypothetical, or the structure me
Dimitri Fontaine writes:
> Tom Lane writes:
>> Another thought is that it'd probably be useful for there to be a
>> "CREATE OR REPLACE EXTENSION" syntax, with the behavior of "install the
>> extension if it's not present, else make sure it's of the specified or
>> default version"; this behavior
On 02/16/2011 05:54 PM, Alvaro Herrera wrote:
I cleaned up the patch a bit -- result is v11, attached. I'll give it
another look tomorrow and hopefully commit it.
Thanks for picking this up.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
On 02/16/2011 04:24 PM, Robert Haas wrote:
On Tue, Feb 15, 2011 at 1:02 PM, Stephen Frost wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
On 02/15/2011 11:13 AM, Stephen Frost wrote:
Think I suggested that at one point. I'm all for doing that on a major
version change like this one, b
I cleaned up the patch a bit -- result is v11, attached. I'll give it
another look tomorrow and hopefully commit it.
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
pg_to_perl_arrays_v11.patch.gz
Description
On Feb 14, 2011, at 11:44 PM, Oleg Bartunov wrote:
>> IMO, sooner or later we need to trash that code and replace it with
>> something a bit more modification-friendly.
>
> We thought about configurable parser, but AFAIR, we didn't get any support
> for this at that time.
What would it take to
On Feb 16, 2011, at 1:20 PM, Dimitri Fontaine wrote:
> We will then need "build"-time requires (build-depends would say debian)
> so that the system knows what's needed to run the install or upgrade
> scripts. I've been thinking that's for 9.2, but maybe that would be a
> simpler fix for you here
Le 14 févr. 2011 à 19:27, Rémi Zara a écrit :
>
> Le 12 févr. 2011 à 18:51, Peter Eisentraut a écrit :
>
>>
>> It's only failing on this one machine, but there isn't anything
>> platform-specific in this code, so I'd look for memory management faults
>> on the code or a compiler problem. Try
Dimitri Fontaine writes:
> Tom Lane writes:
>> Well, actually, we *do* have such a mechanism (plpgsql), we just don't
>> want to use it unless we have to. I wouldn't feel too bad about saying
>> "upgrading tsearch2 directly from 9.0 to 9.4 requires that you have
>> plpgsql installed when you iss
On Sat, Feb 12, 2011 at 8:19 AM, Robert Haas wrote:
> On Sat, Feb 12, 2011 at 7:47 AM, Stephen Frost wrote:
>> Oleg,
>>
>> * Oleg Bartunov (o...@sai.msu.su) wrote:
>>> what do you need for documentation ? From users point of view we add just
>>> knn support and all examples are available in btree
On Tue, Feb 15, 2011 at 1:02 PM, Stephen Frost wrote:
> * Andrew Dunstan (and...@dunslane.net) wrote:
>> On 02/15/2011 11:13 AM, Stephen Frost wrote:
>> >Think I suggested that at one point. I'm all for doing that on a major
>> >version change like this one, but I think we already had some concer
On mån, 2011-02-14 at 10:11 -0500, Tom Lane wrote:
> But before expending time on that, I'd want to see some evidence that
> it's actually helpful for production situations. I'm a bit dubious
> that you're going to gain much here.
If you want to build an index on a 500GB table and you have 1TB RA
Tom Lane writes:
> ERROR: version to install or update to must be different from old version
>
> On reflection it seems like this is overly paranoid, and it'd be more
> useful if the ALTER just reported a NOTICE along the lines of "version
> so-and-so is already installed". Any objections?
I se
Tom Lane writes:
> Well, actually, we *do* have such a mechanism (plpgsql), we just don't
> want to use it unless we have to. I wouldn't feel too bad about saying
> "upgrading tsearch2 directly from 9.0 to 9.4 requires that you have
> plpgsql installed when you issue the CREATE EXTENSION command"
On mån, 2011-02-14 at 15:01 +0200, Devrim GÜNDÜZ wrote:
> On Mon, 2011-02-14 at 13:52 +0100, Cédric Villemain wrote:
> > "Consider providing debian packages at debian.postgresql.org"
>
> apt.postgresql.org, please. :)
APT is not necessarily tied to Debian, nor is a Debian package
repository neces
Tom Lane writes:
> Fix corner case for binary upgrade: extension functions in pg_catalog.
Do we only want to care about functions here? What about the following?
CREATE EXTENSION hstore WITH SCHEMA pg_catalog;
When not doing binary upgrade, this will issue the right pg_dump
command, but it s
Alvaro Herrera wrote:
> Cleanup ClusterInfo initialization in pg_upgrade
Global structs are already initialized to zero, so no need to initialize
them. I discussed this with Alvaro, and he suggested that there is no
need to free memory before we exit. The attached, applied patch makes
both chang
Tom Lane writes:
> [ scratches head ... ] Why is your version generating so many
> unnecessary @extschema@ uses?
I just ran create table tomlist as select your query and create table
dimlist as select my query, then:
dim=# select * from tomlist except select * from dimlist;
On 26 November 2009 07:26, Heikki Linnakangas
wrote:
> David Christensen wrote:
>> 1) is there a hard limit of the number of times the archive_command will
>> attempt? I didn't see anything documented about this in the PITR or
>> config docs, so I'm guessing the 10 failures I saw in the log were
Excerpts from Tim Bunce's message of mié feb 16 14:08:11 -0300 2011:
> On Sat, Feb 12, 2011 at 02:17:12AM +0200, Alexey Klyukin wrote:
> >
> > So, here is the v8. Instead of rewriting the encode_array_literal I've added
> > another function, encode_type_literal (could use a better name).
> Given
On Wed, Feb 16, 2011 at 10:25 AM, Tom Lane wrote:
> Gurjeet Singh writes:
> > I understand that we need to hide guts of an implementation. But without
> > this the Index Advisor will have to emulate what LookupOpclassInfo() does
> > and that's a lot of code that I am afraid, if emulated by anoth
On Wed, 2011-02-16 at 12:29 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> Can someone take ownership of this, get involved with the libedit folks,
> get Debian to use their fixes, and solve this problem for us?
That is a lot easier said that done. To be frank, I thought it was
something that I
Robert Haas writes:
> Well, it sounds like we're in agreement at least about 9.1, so we can
> leave the rest of the argument to another day. I *am* surprised that
> you think it would take *thousands* of lines of code.
Well, it all depends on how much ALTER stuff you want to add. An
open-ended
On Wed, Feb 16, 2011 at 12:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> The trouble is that we have no mechanism for conditional logic in
>> upgrade scripts, so if the system catalog structure should change in a
>> way that causes the hook and unhook mechanism to require different
>> logic dep
On Wed, Feb 16, 2011 at 12:34 PM, Heikki Linnakangas
wrote:
> On 16.02.2011 19:29, Robert Haas wrote:
>>
>> Actually, on further reflection, I'm not even sure why we bother with
>> the fsync. It seems like a useful safeguard but I'm not seeing how we
>> can get to that point without having fsync'
On 02/16/2011 12:29 PM, Bruce Momjian wrote:
Tom Lane wrote:
Robert Haas writes:
On Fri, Feb 11, 2011 at 3:10 PM, Tom Lane wrote:
We have code that exists in both psql and the backend (cf src/port/)
so I'm not sure this really will satisfy the more rabid GPL partisans.
And this whole discu
On 16.02.2011 19:29, Robert Haas wrote:
Actually, on further reflection, I'm not even sure why we bother with
the fsync. It seems like a useful safeguard but I'm not seeing how we
can get to that point without having fsync'd everything anyway. Am I
missing something?
WalRcvDie() is called on
On 16.02.2011 19:17, Robert Haas wrote:
The trouble is that we have no mechanism for conditional logic in
upgrade scripts,...
Can't you put a DO-block there? It's not pretty, but should work..
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers maili
Robert Haas writes:
> The trouble is that we have no mechanism for conditional logic in
> upgrade scripts, so if the system catalog structure should change in a
> way that causes the hook and unhook mechanism to require different
> logic depending on which PG major version is in use, we're hosed.
On Wed, Feb 16, 2011 at 12:24 PM, Heikki Linnakangas
wrote:
> On 16.02.2011 19:17, Robert Haas wrote:
>>
>> The trouble is that we have no mechanism for conditional logic in
>> upgrade scripts,...
>
> Can't you put a DO-block there? It's not pretty, but should work..
Tom has repeatedly objected t
On Wed, Feb 16, 2011 at 11:32 AM, Simon Riggs wrote:
> On Wed, 2011-02-16 at 17:40 +0200, Heikki Linnakangas wrote:
>> On 16.02.2011 17:36, Simon Riggs wrote:
>> > On Tue, 2011-02-15 at 12:08 -0500, Robert Haas wrote:
>> >> On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao
>> >> wrote:
>> >>> On Fri
Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Feb 11, 2011 at 3:10 PM, Tom Lane wrote:
> >> We have code that exists in both psql and the backend (cf src/port/)
> >> so I'm not sure this really will satisfy the more rabid GPL partisans.
> >> And this whole discussion is about satisfying the m
On Wed, Feb 16, 2011 at 11:29 AM, Tom Lane wrote:
>> Hmm. Can we just invent a way to hook them from the opclasses? I
>> have a feeling that now that this extension stuff is in we're going to
>> discover a bunch of these little utility commands that we managed to
>> get by without in the past bu
On Sat, Feb 12, 2011 at 02:17:12AM +0200, Alexey Klyukin wrote:
>
> So, here is the v8. Instead of rewriting the encode_array_literal I've added
> another function, encode_type_literal (could use a better name).
Given that encode_array_literal() encodes an _array_ as a literal,
I'd assume encode_
On Wed, Feb 16, 2011 at 18:03, Thom Brown wrote:
> For the number of fortnights, that becomes:
>
> select extract(epoch from now() - '2010-01-01
> 11:45:13'::timestamp)/60/60/24/14;
>
> You'd think with PostgreSQL having such a rich type system, it
> wouldn't need to come to that. It's just aski
Thom Brown wrote:
> For the number of fortnights, that becomes:
>
> select extract(epoch from now() - '2010-01-01
> 11:45:13'::timestamp)/60/60/24/14;
>
> You'd think with PostgreSQL having such a rich type system, it
> wouldn't need to come to that. It's just asking for the number of
> inte
On Wed, 2011-02-16 at 17:40 +0200, Heikki Linnakangas wrote:
> On 16.02.2011 17:36, Simon Riggs wrote:
> > On Tue, 2011-02-15 at 12:08 -0500, Robert Haas wrote:
> >> On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao
> >> wrote:
> >>> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
> >>> wrote:
Robert Haas writes:
> On Tue, Feb 15, 2011 at 7:10 PM, Tom Lane wrote:
>> 2. We could add extra pg_proc.h entries matching the old signatures.
>> For the moment these would be stub functions that call the same C code,
>> though eventually perhaps they could be changed to throw errors.
> +1.
OK,
On Tue, 2011-02-15 at 06:49 +0200, Peter Eisentraut wrote:
> On mån, 2011-02-14 at 11:49 -0500, Stephen Frost wrote:
> > Perhaps a thought for next time would be to offset things a bit. eg:
> >
> > CF 2011-03 (or whatever):
> > 2011-02-14: Patches should all be submitted
> > 2011-02-14: Reviewers
On 16 February 2011 15:57, Jan-Benedict Glaw wrote:
> On Wed, 2011-02-16 10:52:13 -0500, Robert Haas wrote:
>> On Wed, Feb 16, 2011 at 10:47 AM, Thom Brown wrote:
>> > I'm wondering what people think of introducing some kind of function
>> > to extract the number of units between 2 dates? At th
1 - 100 of 131 matches
Mail list logo
