On Thu, Jun 16, 2011 at 02:52, Craig Ringer wrote:
> Hi (EnterpriseDB) folks
>
> I've been working with someone off list to get some information about a
> crash they encounter during a batch run. We're generating a crash dump, but
> I'm having some issues getting matching symbols so I can examine
Peter Eisentraut writes:
> On ons, 2011-06-15 at 22:19 -0400, Tom Lane wrote:
>> (FWIW, I've come around to liking the idea of using =~ and the obvious
>> variants of that for regex operators, mainly because of the Perl
>> precedent.)
> Maybe I'm not completely up to date on this, but I observe t
Peter Eisentraut writes:
> On tis, 2011-06-14 at 15:38 +0200, Florian Pflug wrote:
>> BTW, there's actually precedent for a commutator of "~", namely
>> "@". Some of the geometric types (polygon, box, circle, point,
>> path) use "~" as a commutator for "@" (which stands for "contains").
> I woul
"Ross J. Reedstrom" writes:
> As an operations guy, the idea of an upgrade using a random,
> non-repeatable port selection gives me the hebejeebees.
Yeah, I agree. The latest version of the patch doesn't appear to have
any random component to it, though --- it just expects the user to
provide po
On ons, 2011-06-15 at 22:19 -0400, Tom Lane wrote:
> (FWIW, I've come around to liking the idea of using =~ and the obvious
> variants of that for regex operators, mainly because of the Perl
> precedent.)
Maybe I'm not completely up to date on this, but I observe that Perl
itself doesn't appear to
On tis, 2011-06-14 at 15:38 +0200, Florian Pflug wrote:
> BTW, there's actually precedent for a commutator of "~", namely
> "@". Some of the geometric types (polygon, box, circle, point,
> path) use "~" as a commutator for "@" (which stands for "contains").
I wouldn't have a problem with naming t
On mån, 2011-06-13 at 10:19 -0400, Andrew Dunstan wrote:
> On 06/13/2011 10:07 AM, Robert Haas wrote:
> > Some languages use =~ and some use just ~... I was just
> > wondering if anyone thought the commutator of =~ was ~=...
>
> My feeling is it's a bit dangerous. It's too easy to fat-finger the
On Wed, Jun 15, 2011 at 09:14:16PM -0400, Stephen Frost wrote:
> Bruce,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > I have researched this and need feedback.
>
> In general, I like the whole idea of using random/special ports for the
> duration of the upgrade. I agree that we need to kee
Tom Lane wrote:
> Bruce Momjian writes:
> > I have researched this and need feedback. Initially I wanted to use a
> > single -p port flag to be used by the old and new clusters. However,
> > pg_upgrade allows --check mode while the old server is running, so we
> > need to allow you to use the cu
Bruce Momjian writes:
> I have researched this and need feedback. Initially I wanted to use a
> single -p port flag to be used by the old and new clusters. However,
> pg_upgrade allows --check mode while the old server is running, so we
> need to allow you to use the current old postmaster port
Florian Pflug writes:
> Comments are extremely welcome, especially ones regarding
> the overall approach taken in this patch. If people consider
> that to be acceptable, I'd try to add the missing features
> and add documentation.
Quite honestly, I don't like this one bit and would rather you not
I wrote:
> Peter Eisentraut writes:
>> As a secondary point, we have so far used mostly single quotes for
>> quoting the installation directories, in case someone wants to try other
>> funny characters besides spaces. The most recent patch uses double
>> quotes. I'm not sure what degree of suppo
Stephen Frost wrote:
-- Start of PGP signed section.
> * Bruce Momjian (br...@momjian.us) wrote:
> > Having long options mean different than short options seems very
> > confusing.
>
> Err, that wasn't what I was proposing.. Just having:
> --old-port-during-upgrade
>
> and similar would have to
* Bruce Momjian (br...@momjian.us) wrote:
> Having long options mean different than short options seems very
> confusing.
Err, that wasn't what I was proposing.. Just having:
--old-port-during-upgrade
and similar would have to be used if they want to specify the ports to
be used during the upgra
Stephen Frost wrote:
-- Start of PGP signed section.
> Bruce,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > I have researched this and need feedback.
>
> In general, I like the whole idea of using random/special ports for the
> duration of the upgrade. I agree that we need to keep the abil
On Wed, Jun 15, 2011 at 8:54 PM, Josh Berkus wrote:
> I've trolled this list, and I think I added in all patches which were
> submitted here but not on the commitfest app. Can someone double-check
> for me?
There's a "read and heed" that's appropriate here...
As hard as we may try, if you imag
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> I have researched this and need feedback.
In general, I like the whole idea of using random/special ports for the
duration of the upgrade. I agree that we need to keep the ability to
check the existing clusters. My gut feeling is this: keep t
Tom Lane wrote:
> Christopher Browne writes:
> > On Wed, Jun 15, 2011 at 5:35 PM, Bruce Momjian wrote:
> >> [ just recommend using a different port number during pg_upgrade ]
>
> > +1... That seems to have lots of nice properties.
>
> Yeah, that seems like an appropriate expenditure of effort.
All,
I've trolled this list, and I think I added in all patches which were
submitted here but not on the commitfest app. Can someone double-check
for me?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Thu, Jun 16, 2011 at 12:24 AM, Tom Lane wrote:
> Simon Riggs writes:
>> On Wed, Jun 15, 2011 at 8:05 PM, Tom Lane wrote:
>>> Simon Riggs writes:
So a function that is both STRICT and SET RETURNING will return rows.
>
>>> Really? The case behaves as expected for me.
>
>> Seems that's th
Alvaro Herrera writes:
> Here's an updated patch fixing all of the above. I stole your first
> test case and added it to regression, after some editorialization.
I've probably created some merge conflicts for you in process of fixing
the FOREIGN KEY NOT VALID patch, but in any case you need to c
Peter Eisentraut writes:
> I couldn't see a way good way of programming around this (perhaps in the
> second case, but it would get uselessly ugly), so perhaps just marking
> the variables as potentially unused would be appropriate? See patch.
Of course this would break not only on non-gcc compi
Simon Riggs writes:
> On Wed, Jun 15, 2011 at 8:05 PM, Tom Lane wrote:
>> Simon Riggs writes:
>>> So a function that is both STRICT and SET RETURNING will return rows.
>> Really? The case behaves as expected for me.
> Seems that's the wrong question. Let me return to why I raised this:
> Why
On Tue, Jun 14, 2011 at 5:28 AM, Noah Misch wrote:
> On Mon, Jun 13, 2011 at 04:16:06PM +0100, Simon Riggs wrote:
>> On Mon, Jun 13, 2011 at 3:11 AM, Robert Haas wrote:
>> > On Sun, Jun 12, 2011 at 3:01 PM, Noah Misch wrote:
>> >> Assuming that conclusion, I do think it's worth starting
>> >> wi
Peter Eisentraut writes:
> Is this a route we want to go down?
> - GISTENTRY vector[1]; /* variable-length array */
> + GISTENTRY vector[FLEXIBLE_ARRAY_MEMBER];
Yes, I was thinking about the same trick after noting these warnings on
Fedora 15, although personally
On Wed, Jun 15, 2011 at 10:42 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> So is somebody from 2nd Quadrant going to supply a patch to fix this?
>
> I'm already on it. The whole patch appears to need some review,
> considering this is about the fourth major flaw we've found in it.
I'll leave
Bruce Momjian writes:
> Peter Eisentraut wrote:
>> On non-Windows servers you could get this even safer by disabling the
>> TCP/IP socket altogether, and placing the Unix-domain socket in a
>> private temporary directory. The "port" wouldn't actually matter then.
> Yes, it would be nice to just
On Wed, Jun 15, 2011 at 9:59 PM, Alvaro Herrera
wrote:
> Excerpts from Simon Riggs's message of mié jun 15 16:31:45 -0400 2011:
>> On Wed, Jun 15, 2011 at 9:14 PM, Alvaro Herrera
>> wrote:
>>
>> > So is somebody from 2nd Quadrant going to supply a patch to fix this?
>>
>> My understanding was tha
Peter Eisentraut writes:
> As a secondary point, we have so far used mostly single quotes for
> quoting the installation directories, in case someone wants to try other
> funny characters besides spaces. The most recent patch uses double
> quotes. I'm not sure what degree of support we want to a
Alvaro Herrera writes:
> So is somebody from 2nd Quadrant going to supply a patch to fix this?
I'm already on it. The whole patch appears to need some review,
considering this is about the fourth major flaw we've found in it.
regards, tom lane
--
Sent via pgsql-hackers
Peter Eisentraut wrote:
> On ons, 2011-06-15 at 13:35 -0400, Bruce Momjian wrote:
> > I now believe we are overthinking all this. pg_upgrade has always
> > supported specification of a port number. Why not just tell users to
> > specify an unused port number > 1023, and not to use the default
> >
Tom Lane wrote:
> Christopher Browne writes:
> > On Wed, Jun 15, 2011 at 5:35 PM, Bruce Momjian wrote:
> >> [ just recommend using a different port number during pg_upgrade ]
>
> > +1... That seems to have lots of nice properties.
>
> Yeah, that seems like an appropriate expenditure of effort.
Excerpts from Simon Riggs's message of mié jun 15 16:31:45 -0400 2011:
> On Wed, Jun 15, 2011 at 9:14 PM, Alvaro Herrera
> wrote:
>
> > So is somebody from 2nd Quadrant going to supply a patch to fix this?
>
> My understanding was that your patch had a bug, rather than the
> existing code. If I
On tis, 2011-06-14 at 18:09 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 06/14/2011 05:45 PM, Tom Lane wrote:
> >> I've committed patches that fix these issues on my own OS X machine,
>
> > Well, OSX is just using our usual *nix paraphernalia, so if it's broken
> > won't all such platf
Hackers,
The first commitfest for PostgreSQL 9.2 has now started.
As such, if you have a patch for 9.2 which was not yet submitted, you
should add it to CommitFest 2011-9
(https://commitfest.postgresql.org/action/commitfest_view?id=11).
Currently we have 53 open patches. 17 of them need reviewe
On Wed, Jun 15, 2011 at 9:14 PM, Alvaro Herrera
wrote:
> So is somebody from 2nd Quadrant going to supply a patch to fix this?
My understanding was that your patch had a bug, rather than the
existing code. If I misunderstood, please explain the bug.
In terms of "2ndQuadrant" supplying patches,
The attached patch updates README-SSI. In addition to some minor edits,
changes include:
- add a section at the beginning that more clearly describes the SSI
rule and defines "dangerous structure" with a diagram. It describes
the optimizations we use about the relative commit times, and the
Another set of new gcc 4.6 warnings:
readfuncs.c: In function ‘_readCaseWhen’:
readfuncs.c:875:567: warning: variable ‘token’ set but not used
[-Wunused-but-set-variable]
readfuncs.c: In function ‘_readFromExpr’:
readfuncs.c:1159:568: warning: variable ‘token’ set but not used
[-Wunused-but-set-
On Wed, Jun 15, 2011 at 3:14 PM, Alvaro Herrera
wrote:
>
> So is somebody from 2nd Quadrant going to supply a patch to fix this?
>
well, i was going to give it a try... but in a couple of hours...
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Excerpts from Tom Lane's message of mié jun 15 11:54:25 -0400 2011:
> Dean Rasheed writes:
> > On 15 June 2011 07:56, Jaime Casanova wrote:
> >> Testing the CHECK NOT VALID patch i found $subject... is this intended?
>
> > Aside from the ugliness of the code, we can't just add a
> > ConstraintAt
gcc 4.6 has now arrived as the default compiler on my desktop, and as
previously reported, it throws a bunch of warnings, foiling my life-long
plan of compiling PostgreSQL with -Werror.
So looking more aggressively into fixing some of these, let's look at
this case:
gistutil.c: In function ‘gistM
On ons, 2011-06-15 at 13:35 -0400, Bruce Momjian wrote:
> I now believe we are overthinking all this. pg_upgrade has always
> supported specification of a port number. Why not just tell users to
> specify an unused port number > 1023, and not to use the default
> value? Both old and new clusters
On Wed, Jun 15, 2011 at 8:05 PM, Tom Lane wrote:
> Simon Riggs writes:
>> STRICT functions return NULL if any of their inputs are NULL according
>> to the manual, so that they need not be executed at all.
>
>> Unless it is a Set Returning Function, in which case a NULL input is
>> not reduced nor
Excerpts from Tom Lane's message of mié jun 15 14:49:04 -0400 2011:
> Alvaro Herrera writes:
> > Excerpts from Robert Haas's message of mié jun 15 12:53:59 -0400 2011:
> >> On Wed, Jun 15, 2011 at 12:24 PM, Alvaro Herrera
> >> wrote:
> >>> Hmm, I think this means we need to send a sinval message
On 06/12/2011 04:22 AM, Robert Haas wrote:
> One idea is that we could add outBuffer2/outBufSize2 to struct
> pg_conn, or something along those lines with less obviously stupid
> naming. Normally those would be unused, but in the special case where
> SSL indicates that we must retry the call with
On Wed, Jun 15, 2011 at 4:54 PM, Tom Lane wrote:
> Dean Rasheed writes:
>> On 15 June 2011 07:56, Jaime Casanova wrote:
>>> Testing the CHECK NOT VALID patch i found $subject... is this intended?
>
>> Aside from the ugliness of the code, we can't just add a
>> ConstraintAttributeSpec to the seco
Simon Riggs writes:
> STRICT functions return NULL if any of their inputs are NULL according
> to the manual, so that they need not be executed at all.
> Unless it is a Set Returning Function, in which case a NULL input is
> not reduced nor does it to appear to be handled as a special case in
> t
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of mié jun 15 12:53:59 -0400 2011:
>> On Wed, Jun 15, 2011 at 12:24 PM, Alvaro Herrera
>> wrote:
>>> Hmm, I think this means we need to send a sinval message to invalidate
>>> cached plans when a constraint is validated. I'll see abou
Christopher Browne writes:
> On Wed, Jun 15, 2011 at 5:35 PM, Bruce Momjian wrote:
>> [ just recommend using a different port number during pg_upgrade ]
> +1... That seems to have lots of nice properties.
Yeah, that seems like an appropriate expenditure of effort. It's surely
not bulletproof,
"Kevin Grittner" wrote:
> Unless I'm missing something, the only remaining changes needed
> are for documentation (as mentioned in previous posts).
I just found notes that we also need regression tests for the
SSI/DDL combination and a comment in lazy_truncate_heap.
At any rate, not anything
On Wed, Jun 15, 2011 at 5:35 PM, Bruce Momjian wrote:
> This requires no new backend code. We could even _require_ the port
> number to be specified in pg_upgrade.
+1... That seems to have lots of nice properties.
--
When confronted by a difficult problem, solve it by reducing it to the
questi
Robert Haas wrote:
> > Also, a standalone backend does not have libpq either so how do you get
> > values into application variables? ?Parse the text output? ?That seems
> > like a much larger kludge.
>
> Maybe we could do something like this.
>
> 1. pg_upgrade invokes the postmaster with --binar
Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of mi?? jun 15 12:52:30 -0400 2011:
> > Alvaro Herrera writes:
> > > Excerpts from Robert Haas's message of mi?? jun 15 08:45:21 -0400 2011:
> > >> As a separate issue, I tend to agree with Tom that using psql as part
> > >> of the pg_upgrad
On Wed, Jun 15, 2011 at 1:13 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié jun 15 12:51:29 -0400 2011:
>> On Wed, Jun 15, 2011 at 12:12 PM, Alvaro Herrera
>> wrote:
>
>> > Agreed on both counts ... but ... does this mean that we need a
>> > different program for programma
2011/6/15 PostgreSQL - Hans-Jürgen Schönig :
> hello ...
>
> 2.4? we know that some versions of 2.4 cause problems due to broken
> posix_fadvise. if i remember correctly we built some configure magic into
> PostgreSQL to check for this bug. what does this check do?
It doesn't check anything beyo
Excerpts from Tom Lane's message of mié jun 15 12:52:30 -0400 2011:
> Alvaro Herrera writes:
> > Excerpts from Robert Haas's message of mié jun 15 08:45:21 -0400 2011:
> >> As a separate issue, I tend to agree with Tom that using psql as part
> >> of the pg_upgrade process is a lousy idea and we n
Excerpts from Robert Haas's message of mié jun 15 12:51:29 -0400 2011:
> On Wed, Jun 15, 2011 at 12:12 PM, Alvaro Herrera
> wrote:
> > Agreed on both counts ... but ... does this mean that we need a
> > different program for programmable tasks as opposed to interactive
> > ones? Dealing with sta
Merlin Moncure writes:
> Due to unfortunate environmental conditions (don't ask) I've been
> trying to get postgres 9.0 up and running on a fairly ancient linux --
> redhat EL 3 which as kernel 2.4.21. initdb borks on the create
> database step with the error message "child process exited with e
Excerpts from Robert Haas's message of mié jun 15 12:53:59 -0400 2011:
> On Wed, Jun 15, 2011 at 12:24 PM, Alvaro Herrera
> wrote:
> > Hmm, I think this means we need to send a sinval message to invalidate
> > cached plans when a constraint is validated. I'll see about this.
>
> I feel like that
STRICT functions return NULL if any of their inputs are NULL according
to the manual, so that they need not be executed at all.
Unless it is a Set Returning Function, in which case a NULL input is
not reduced nor does it to appear to be handled as a special case in
the executor function scan code.
On Wed, Jun 15, 2011 at 12:24 PM, Alvaro Herrera
wrote:
> Hmm, I think this means we need to send a sinval message to invalidate
> cached plans when a constraint is validated. I'll see about this.
I feel like that really ought to be happening automatically, as a
result of committing the transact
--On 15. Juni 2011 16:47:55 + Greg Sabino Mullane wrote:
Or perhaps pg_connections. Yes, +1 to making things fully backwards
compatible by keeping pg_stat_activity around but making a better
designed and better named table (view/SRF/whatever).
I thought about that too when reading the t
On 15 June 2011 17:12, Merlin Moncure wrote:
> Due to unfortunate environmental conditions (don't ask) I've been
> trying to get postgres 9.0 up and running on a fairly ancient linux --
> redhat EL 3 which as kernel 2.4.21. initdb borks on the create
> database step with the error message "child
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of mié jun 15 08:45:21 -0400 2011:
>> As a separate issue, I tend to agree with Tom that using psql as part
>> of the pg_upgrade process is a lousy idea and we need a better
>> solution. But let's fix one thing at a time.
> Agreed on
On Wed, Jun 15, 2011 at 12:12 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié jun 15 08:45:21 -0400 2011:
> Seems good, except that passing the password as a command line argument
> is obviously broken from a privacy perspective -- anyone could see the
> process list and get
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> At any rate, I like "sessions". That's what it is, after all. But I
> will note that we had better be darn sure to make all the changes we
> want to make in one go, because I dowanna have to create pg_sessions2
> (or pg_tessions?) in a year
hello ...
2.4? we know that some versions of 2.4 cause problems due to broken
posix_fadvise. if i remember correctly we built some configure magic into
PostgreSQL to check for this bug. what does this check do?
many thanks,
hans
On Jun 15, 2011, at 6:12 PM, Merlin Mo
On Wed, Jun 15, 2011 at 12:13 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Robert Haas's message of mié jun 15 08:47:58 -0400 2011:
>>> Now, that's a suggestion I could very possibly get behind. Though the
>>> fact that it would leave us with pg_activity / pg_stat_replication
>>
Excerpts from Jaime Casanova's message of mié jun 15 02:09:15 -0400 2011:
> psql \h says (among other things) for ALTER TABLE
> """
>ADD table_constraint
>ADD table_constraint_using_index
>ADD table_constraint [ NOT VALID ]
> """
>
> ADD table_constraint appears twice and isn't true t
On Wed, Jun 15, 2011 at 11:12 AM, Merlin Moncure wrote:
> Due to unfortunate environmental conditions (don't ask) I've been
> trying to get postgres 9.0 up and running on a fairly ancient linux --
> redhat EL 3 which as kernel 2.4.21. initdb borks on the create
> database step with the error mes
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of mié jun 15 08:47:58 -0400 2011:
>> Now, that's a suggestion I could very possibly get behind. Though the
>> fact that it would leave us with pg_activity / pg_stat_replication
>> seems less than ideal. Maybe pg_activity isn't the be
Excerpts from Robert Haas's message of mié jun 15 08:45:21 -0400 2011:
> 1. pg_upgrade invokes the postmaster with --binary-upgrade=:
>
> 2. postmaster starts up into multi-user mode, but it does not start
> autovacuum and ignores pg_hba.conf, listen_addresses, and port.
> Instead it listens only
Due to unfortunate environmental conditions (don't ask) I've been
trying to get postgres 9.0 up and running on a fairly ancient linux --
redhat EL 3 which as kernel 2.4.21. initdb borks on the create
database step with the error message "child process exited with error
code 139". A bit of tracin
Heikki Linnakangas wrote:
>> There may be some places this can be checked which haven't yet
>> been identified and touched.
>
> Yeah - in 9.2.
No argument here. I'm all for stabilizing and getting the thing out
-- I think we've established that performance is good for many
workloads as it st
Excerpts from Robert Haas's message of mié jun 15 08:47:58 -0400 2011:
> On Wed, Jun 15, 2011 at 3:34 AM, Greg Smith wrote:
> > Putting on my stability hat instead of my "make it right" one, maybe this
> > really makes sense to expose as a view with a whole new name. Make this new
> > one pg_act
Dean Rasheed writes:
> On 15 June 2011 07:56, Jaime Casanova wrote:
>> Testing the CHECK NOT VALID patch i found $subject... is this intended?
> Aside from the ugliness of the code, we can't just add a
> ConstraintAttributeSpec to the second block, because that would
> enforce an order to these
Gurjeet Singh writes:
> On Wed, Jun 15, 2011 at 10:31 AM, Robert Haas wrote:
>> Well, that would probably be a lot slower, and wouldn't necessarily
>> deliver as consistent a snapshot of system activity. It's better to
>> have one set-returning function that dumps out all the data in a
>> single
On Wed, Jun 15, 2011 at 10:31 AM, Robert Haas wrote:
> On Wed, Jun 15, 2011 at 9:44 AM, Gurjeet Singh
> wrote:
> > Why not expose this new information as functions instead of a new view,
> like
> > we do for pg_is_in_replication(). People can use whatever alias they want
> in
> > the queries the
On Wed, Jun 15, 2011 at 9:44 AM, Gurjeet Singh wrote:
> Why not expose this new information as functions instead of a new view, like
> we do for pg_is_in_replication(). People can use whatever alias they want in
> the queries they write.
>
> SELECT get_current_query(pid), is_idle(pid), is_idle_in_
On 06/14/2011 08:04 PM, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
For me, the litmus test is whether the change provides enough
improvement that it outweighs the disruption when the user runs into
it.
For the procpid that started all of this, the clear ans
On Wed, Jun 15, 2011 at 10:05 AM, Andrew Dunstan wrote:
> What I actually had in mind was rather different: an HBA mechanism based on
> appname. But on second thoughts maybe the protocol wouldn't support that.
Ah, a similar thought struck me.
Independent of this particular feature, it would be r
On Wed, Jun 15, 2011 at 10:05 AM, Andrew Dunstan wrote:
> What I actually had in mind was rather different: an HBA mechanism based on
> appname. But on second thoughts maybe the protocol wouldn't support that.
Ah, a similar thought struck me.
Independent of this particular feature, it would be r
On 06/14/2011 11:01 PM, Bruce Momjian wrote:
You might remember we added a postmaster/postgres -b switch to indicate
binary upgrade mode. The attached patch prevents any client without an
application_name of 'binary-upgrade' from connecting to the cluster
while it is binary upgrade mode. This
On Tue, Jun 14, 2011 at 9:08 PM, Josh Kupershmidt wrote:
> On Tue, Jun 14, 2011 at 12:15 PM, Merlin Moncure wrote:
>> What I do wonder though is if the ; appending should really be
>> happening in printQuery() instead of in each query -- the idea being
>> that formatting for external consumption
On Wed, Jun 15, 2011 at 8:47 AM, Robert Haas wrote:
> On Wed, Jun 15, 2011 at 3:34 AM, Greg Smith wrote:
> > The whole thing is enormously frustrating, and it's an advocacy
> problem--it
> > contributes to people just starting to become serious about using
> PostgreSQL
> > lowering their opinion
On Tue, Jun 14, 2011 at 9:50 PM, Bruce Momjian wrote:
> Greg Smith wrote:
> > On 06/14/2011 06:00 PM, Tom Lane wrote:
> > > As far as Greg's proposal is concerned, I don't see how a proposed
> > > addition of two columns would justify renaming an existing column.
> > > Additions should not break
On Wed, Jun 15, 2011 at 3:34 AM, Greg Smith wrote:
> The whole thing is enormously frustrating, and it's an advocacy problem--it
> contributes to people just starting to become serious about using PostgreSQL
> lowering their opinion of its suitability for their business. If this is
> what's inclu
On Wed, Jun 15, 2011 at 8:05 AM, Bruce Momjian wrote:
> Bruce Momjian wrote:
>> Tom Lane wrote:
>> > Bruce Momjian writes:
>> > > You might remember we added a postmaster/postgres -b switch to indicate
>> > > binary upgrade mode. The attached patch prevents any client without an
>> > > applicati
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > You might remember we added a postmaster/postgres -b switch to indicate
> > > binary upgrade mode. The attached patch prevents any client without an
> > > application_name of 'binary-upgrade' from connecting to the cluster
> >
Jesper Krogh wrote:
> On 2011-06-15 05:01, Bruce Momjian wrote:
> > You might remember we added a postmaster/postgres -b switch to indicate
> > binary upgrade mode. The attached patch prevents any client without an
> > application_name of 'binary-upgrade' from connecting to the cluster
> > while i
Hello Heikki,
probably I found a bug in patch:
CREATE FUNCTION fx(i integer) RETURNS integer
LANGUAGE plpgsql
AS $$begin raise notice '>>%<<', i; return i; end;$$;
CREATE FUNCTION fx1(integer) RETURNS text
LANGUAGE sql
AS $_$ select case $1 when 1 then 'A' else 'B' end$_$;
CREAT
On Wed, Jun 15, 2011 at 10:53 AM, Ahmed Shinwari
wrote:
> Hi All,
>
> I faced a bug on Windows while connecting via SSPI authentication. I was
> able to find the bug and have attached the patch. Details listed below;
>
> Postgres Installer: Version 9.0.4
> OS: Windows Server 2008 R2/Windows 7
>
>
On 10.06.2011 18:05, Kevin Grittner wrote:
Heikki Linnakangas wrote:
* Is the SXACT_FLAG_ROLLED_BACK flag necessary? It's only set in
ReleasePredicateLocks() for a fleeting moment while the
function releases all conflicts and locks held by the
transaction, and finally the sxact stru
> > On Wed, May 25, 2011 at 3:05 PM, Simon Riggs
wrote:
> > Leonardo, can you submit an updated version of this patch today that
> > incorporates Simon's suggestion?
Mmmh, maybe it was simpler than I thought; I must be
missing something... patch attached
How can I test it with "weird" s
On 14.06.2011 17:57, Kevin Grittner wrote:
Heikki Linnakangas wrote:
I did some further changes, refactoring SkipSerialization so that
it's hopefully more readable, and added a comment about the
side-effects. See attached. Let me know if I'm missing something.
I do think the changes improve
On Wed, Jun 15, 2011 at 00:01, Andrew Dunstan wrote:
>
> On 06/14/2011 05:45 PM, Tom Lane wrote:
>>
>> Andrew Dunstan writes:
>>>
>>> On 06/13/2011 08:05 PM, Tom Lane wrote:
I looked into $SUBJECT. There appear to be two distinct issues:
...
>>>
>>> I think we can be a bit more li
Following this whole conversation rises the impression the topic is
going to get lost in
nirvana of personal preferences.
Most suggestions on change for itself are likely to not cross the border of
"not justifying a compatibility break".
I wonder, whether the actual point really is towards compati
On Wed, Jun 15, 2011 at 12:03 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> Is this relocation mechanism something that can be tuned, for different
> tradeoffs between index quality and build time?
>
Yes, it can. I believe that it can be index parameter.
> In any case, it
On 15 June 2011 07:56, Jaime Casanova wrote:
> Hi,
>
> Testing the CHECK NOT VALID patch i found $subject... is this intended?
>
I just noticed that too, and was about to raise it as a bug.
If it is intended, then it's not documented.
I noticed it while browsing gram.y, and thought it looks a b
On 15.06.2011 10:24, Alexander Korotkov wrote:
On Wed, Jun 15, 2011 at 11:21 AM, Alexander Korotkov
wrote:
I've tried index tuples sorting on penalty function before buffer
relocation on split. But it was without any success. Index quality becomes
even worse than without sorting.
The next thing
1 - 100 of 107 matches
Mail list logo
