On 26.11.2012 14:53, Amit Kapila wrote:
On Friday, November 23, 2012 7:03 PM Heikki Linnakangas
This is what I came up with. It adds a new function, OpenFile, that
returns a raw file descriptor like BasicOpenFile, but the file
descriptor is associated with the current subtransaction and
On Sun, 2012-11-25 at 21:08 -0500, Robert Haas wrote:
That, however, is a separate question from what's under discussion
here, because the case at issue for the proposed patch is the one in
which only one possible candidate exists, and the question is whether
we ought to allow the use of
Just another thought !
When we are setting up the variable using \gset, I feel their should be a
provision
to drop a particular variable.
Internally, all the variables are set into VariableSpace linked-list. We
should provide
a command to Drop a particular variable, because in some cases
On 2012-11-27 01:14:27 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
In file included from ./src/include/utils/catcache.h:25:0,
from /tmp/cpluspluscheck.bt8VZr/test.cpp:3:
src/include/lib/ilist.h: In function ‘dlist_node*
dlist_head_node(dlist_head*)’:
On Wed, 2012-11-21 at 15:27 +, Simon Riggs wrote:
It would be useful if we issued a NOTICE when an ambiguity is
introduced, rather than when using it.
Like Bison's reporting of reduce conflicts.
This brings up a very important point, which is that a lot of the code
is frozen in
Hello
2012/11/27 Piyush Newe piyush.n...@enterprisedb.com:
Just another thought !
When we are setting up the variable using \gset, I feel their should be a
provision
to drop a particular variable.
Internally, all the variables are set into VariableSpace linked-list. We
should provide
a
Hello all
2012/11/27 Jeff Davis pg...@j-davis.com:
On Wed, 2012-11-21 at 15:27 +, Simon Riggs wrote:
It would be useful if we issued a NOTICE when an ambiguity is
introduced, rather than when using it.
Like Bison's reporting of reduce conflicts.
This brings up a very important point,
On 2012-11-26 16:39:39 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-10-31 11:41:37 +0530, Amit Kapila wrote:
There seems to be a problem in behavior of Create Index Concurrently and
Hot
Update in HEAD code .
At pgcon.it I had a chance to discuss with
Peter Eisentraut pete...@gmx.net writes:
I'm not fond of overloading LOAD as the refresh command. Maybe you
could go the Oracle route here as well and use a stored procedure. That
would also allow things like SELECT pg_refresh_mv(oid) FROM ... more
easily.
I would like that we have a way to
On 2012-11-26 22:31:50 -0500, Tom Lane wrote:
I wrote:
I'm a bit inclined to think that DROP INDEX CONCURRENTLY should have an
additional step that somehow marks the pg_index row in a new way that
makes RelationGetIndexList ignore it, and then wait out existing
transactions before taking
2012/11/27 Dimitri Fontaine dimi...@2ndquadrant.fr:
Peter Eisentraut pete...@gmx.net writes:
I'm not fond of overloading LOAD as the refresh command. Maybe you
could go the Oracle route here as well and use a stored procedure. That
would also allow things like SELECT pg_refresh_mv(oid) FROM
Peter Eisentraut pete...@gmx.net writes:
Sure, PQping is useful for this very specific use case of seeing whether
the server has finished starting up. If someone came with a plausible
Rename the utility to pg_isready?
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise,
On 2012-11-27 10:18:37 +0530, Pavan Deolasee wrote:
On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Either state of indcheckxmin is valid with all three of these
combinations, so the specific kluge I was contemplating above doesn't
work. But there is no
On 2012-11-27 11:48:08 +0100, Andres Freund wrote:
On 2012-11-27 10:18:37 +0530, Pavan Deolasee wrote:
On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Either state of indcheckxmin is valid with all three of these
combinations, so the specific kluge I
On 2012-11-27 11:52:11 +0100, Andres Freund wrote:
On 2012-11-27 11:48:08 +0100, Andres Freund wrote:
On 2012-11-27 10:18:37 +0530, Pavan Deolasee wrote:
On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Either state of indcheckxmin is valid with all
On Tue, Nov 27, 2012 at 4:22 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2012-11-27 11:48:08 +0100, Andres Freund wrote:
I haven't yet looked deeply enough to judge whether there are actually
bugs. But I can say that the e.g. the missing indisvalid checks in
On 2012-11-26 22:44:49 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-10-05 19:56:40 -0400, Tom Lane wrote:
I think this could possibly be fixed by using nontransactional
update-in-place when we're trying to change indisvalid and/or
indisready, but I've not
On 2012-11-27 16:39:58 +0530, Pavan Deolasee wrote:
On Tue, Nov 27, 2012 at 4:22 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2012-11-27 11:48:08 +0100, Andres Freund wrote:
I haven't yet looked deeply enough to judge whether there are actually
bugs. But I can say that the
On Tue, Nov 27, 2012 at 11:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Either state of indcheckxmin is valid with all three of these
combinations, so the specific kluge I was
On Tue, Nov 27, 2012 at 4:49 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2012-11-27 16:39:58 +0530, Pavan Deolasee wrote:
There might be a bug there as you are suggesting, but for me the CREATE
INDEX itself fails (and rightly so) because of duplicate keys. Do I need
to
run these
Friday, November 23, 2012 5:38 AM Muhammad Usama wrote:
Observations and Comments
---
- If no option is given to pg_computemaxlsn utility then we get a wrong
error message
./pg_computemaxlsn ../data
pg_computemaxlsn: file or directory (null) exists
On Tue, Nov 27, 2012 at 7:35 PM, Dimitri Fontaine dimi...@2ndquadrant.frwrote:
Peter Eisentraut pete...@gmx.net writes:
Sure, PQping is useful for this very specific use case of seeing whether
the server has finished starting up. If someone came with a plausible
Rename the utility to
Hello
2012/11/12 Tomas Vondra t...@fuzzy.cz:
Hi,
attached is a v4 of the patch. There are not many changes, mostly some
simple tidying up, except for handling the Windows.
After a bit more investigation, it seems to me that we can't really get
the same behavior as in other systems -
Pavel Stehule wrote:
2012/11/27 Dimitri Fontaine dimi...@2ndquadrant.fr:
I would like that we have a way to refresh a Materialized View
by calling a stored procedure, but I don't think it should be
the main UI.
I agree. I saw that Oracle uses a function for that without any
statement-level
Hi,
Pavel Stehule pavel.steh...@gmail.com writes:
** missing doc
I still would prefer to have an ack about the premises of this patch
before spending time on writing docs for it, namely:
- we want a normalized command string (schema, auto naming of some
objects such as constraints and
On 09.10.2012 17:44, Vik Reykja wrote:
On Tue, Oct 9, 2012 at 4:09 PM, Tom Lanet...@sss.pgh.pa.us wrote:
=?ISO-8859-1?Q?S=E9bastien_Lardi=E8re?=slardi...@hi-media.com writes:
Indeed, brackets was not correct, it's better now (I think), and correct
some comments.
Still wrong ... at the
On Nov 27, 2012, at 5:25, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
So my proposal for the current feature would be:
ALTER MATERIALIZED VIEW mv UPDATE [ CONCURRENTLY ];
UPDATE MATERIALIZED VIEW mv;
The choice of keywords and syntax here hopefully clearly hint the user
about the
Kevin Grittner kgri...@mail.com writes:
An ALTER MATERIALIZED VIEW option was my first thought on syntax to
do what LOAD does in the current patch. But it bothered me that I
couldn't think of any other cases where ALTER some-object-type
only changed the data contained within the object and had
Dimitri Fontaine wrote:
Kevin Grittner kgri...@mail.com writes:
An ALTER MATERIALIZED VIEW option was my first thought on syntax
to do what LOAD does in the current patch. But it bothered me
that I couldn't think of any other cases where ALTER
some-object-type only changed the data contained
On Tue, Nov 27, 2012 at 8:45 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Tue, Nov 27, 2012 at 7:35 PM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
Peter Eisentraut pete...@gmx.net writes:
Sure, PQping is useful for this very specific use case of seeing whether
the server
Kevin Grittner kgri...@mail.com writes:
changing the structure of the table. Somehow I don't find that
pursuasive as an argument for what ALTER MATERIALIZED VIEW should
rescan the source relations and build a whole new set of data for
exactly the same MV definition.
Fair enough.
Consider
Alvaro Herrera wrote:
Here's version 24.
Old review emails still contains some items that didn't lead to any
changes. I tried to keep close track of those. To that list I add a
couple of things of my own. Here they are, for those following along.
I welcome suggestions.
- Fix the multixact
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Under that light, using ALTER is strange indeed.
Agreed, seems like a poor choice.
I still don't like
using LOAD that much, allow me to try a last syntax proposal. Well all I
can find just now would be:
UPDATE MATERIALIZED VIEW mv FOR EACH
On Mon, Nov 19, 2012 at 2:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Davis pg...@j-davis.com writes:
As I said elsewhere in the thread, I'm not planning to introduce any
additional locking. There is already precedent in IndexOnlyNext.
Of course, that just begs the question of whether the
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Dimitri Fontaine
Sent: Tuesday, November 27, 2012 10:03 AM
To: Kevin Grittner
Cc: Pavel Stehule; Peter Eisentraut; Pgsql Hackers
Subject: Re: [HACKERS] Materialized
2012/11/27 David Johnston pol...@yahoo.com:
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Dimitri Fontaine
Sent: Tuesday, November 27, 2012 10:03 AM
To: Kevin Grittner
Cc: Pavel Stehule; Peter Eisentraut; Pgsql
Andres Freund and...@2ndquadrant.com writes:
On 2012-11-27 01:14:27 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Maybe some ifndef __cplusplus would help.
Its rather easy to fix in the ilist code at least - the cases it points
out are those where I took a slightly ugly
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane escribió:
FWIW, I'd vote for dumping all of these into *one* rmgrdesc directory
(which may as well be under access/ since that's where the xlog code is),
regardless of where the corresponding replay code is in the source tree.
I don't
On Tue, Nov 27, 2012 at 01:59:04AM -0800, Jeff Davis wrote:
On Wed, 2012-11-21 at 15:27 +, Simon Riggs wrote:
It would be useful if we issued a NOTICE when an ambiguity is
introduced, rather than when using it.
Like Bison's reporting of reduce conflicts.
This brings up a very
2012/11/27 Bruce Momjian br...@momjian.us:
On Tue, Nov 27, 2012 at 01:59:04AM -0800, Jeff Davis wrote:
On Wed, 2012-11-21 at 15:27 +, Simon Riggs wrote:
It would be useful if we issued a NOTICE when an ambiguity is
introduced, rather than when using it.
Like Bison's reporting of
[ Sorry for the slow response on this, Thanksgiving interfered. ]
On Wed, Nov 21, 2012 at 3:41 PM, Andres Freund and...@2ndquadrant.com wrote:
One very minor nitpick I unfortunately just found now, not sure when
that changed:
binaryheap_replace_first() hardcodes the indices for the left/right
Andres Freund and...@2ndquadrant.com writes:
On 2012-11-26 16:39:39 -0500, Tom Lane wrote:
I looked at this a bit. I am very unhappy with the proposed kluge to
open indexes NoLock in some places. Even if that's safe today, which
I don't believe in the least, any future change in this area
On Tue, Nov 27, 2012 at 10:52 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
it is a basic problem - PostgreSQL has unique possibilities -
polymorphic parameters and almost all databases doesn't support
overloading
Speaking of polymorphism, why not just implement lpad()'s first
argument as
On Tue, Nov 27, 2012 at 12:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The point of not wanting to open the index NoLock (and for that matter
of having DROP INDEX CONCURRENTLY take AccessExclusiveLock once it
thinks nobody is touching the index) is to make sure that if somehow
somebody is
On Tue, Nov 27, 2012 at 4:46 AM, Jeff Davis pg...@j-davis.com wrote:
Let's say you have only one function foo. All your queries are coded
into your application, and everything works fine, using assignment casts
where necessary.
Then the user is foolish enough to CREATE FUNCTION foo... and now
On 2012-11-27 12:02:09 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-11-26 16:39:39 -0500, Tom Lane wrote:
I looked at this a bit. I am very unhappy with the proposed kluge to
open indexes NoLock in some places. Even if that's safe today, which
I don't
Robert Haas robertmh...@gmail.com writes:
I admit that there are cases where this could happen, and that it will
happen a little more than it does now. But, as you say, this can
happen now, and yet we get very few if any complaints about it,
whereas we get regular complaints about the need to
Andres Freund and...@2ndquadrant.com writes:
So the idea would be to skip about-to-be-dropped indexes in
RelationGetIndexList directly - we don't ever need to watch those, not
even for HOT - because we only have the necessary knowledge there. The
normal valid/ready checks will be done at the
On 2012-11-27 12:50:36 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
I vote for introducing wrapper functions/macro to do the
about-to-be-dropped check, its hard enough to understand as-is.
Meh. If it's only going to be done in RelationGetIndexList, I'm
not sure that
Andres Freund and...@2ndquadrant.com writes:
On 2012-11-26 22:44:49 -0500, Tom Lane wrote:
I looked through the code a bit, and I think we should be able to make
this work, but note there are also places that update indcheckxmin using
heap_update, and that's just as dangerous as changing the
On Tue, 2012-11-27 at 12:19 -0500, Robert Haas wrote:
I admit that there are cases where this could happen, and that it will
happen a little more than it does now. But, as you say, this can
happen now, and yet we get very few if any complaints about it,
whereas we get regular complaints about
I mentioned the remaining issues in a previous email (see
message-id 20121025161751.ge6...@alvh.no-ip.org). Attached is a
patch that enables xlogdump to #include xlog_internal.h by way of
removing that file's inclusion of fmgr.h, which is problematic. I don't
think this should be too
On Tue, Nov 27, 2012 at 12:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I admit that there are cases where this could happen, and that it will
happen a little more than it does now. But, as you say, this can
happen now, and yet we get very few if any
On 2012-11-27 13:45:08 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-11-26 22:44:49 -0500, Tom Lane wrote:
I looked through the code a bit, and I think we should be able to make
this work, but note there are also places that update indcheckxmin using
BTW, I was thinking that the DROP INDEX CONCURRENTLY logic needed to be:
1. Unset indisvalid, commit, wait out all reading transactions.
2. Unset indisready, commit, wait out all writing transactions.
3. Unset indislive, commit (with parent table relcache flush),
wait out all reading-or-writing
On 2012-11-27 14:08:13 -0500, Tom Lane wrote:
BTW, I was thinking that the DROP INDEX CONCURRENTLY logic needed to be:
1. Unset indisvalid, commit, wait out all reading transactions.
2. Unset indisready, commit, wait out all writing transactions.
3. Unset indislive, commit (with parent
On Tue, Nov 27, 2012 at 1:45 PM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2012-11-27 at 12:19 -0500, Robert Haas wrote:
I admit that there are cases where this could happen, and that it will
happen a little more than it does now. But, as you say, this can
happen now, and yet we get very
Robert Haas robertmh...@gmail.com writes:
But as to your point about the system catalogs, it is true that adding
an additional function could reduce the number of cases where things
work today. But I think in many cases it would eliminate the need for
overloading that we already have, and
On 11/26/2012 12:31 PM, Robert Haas wrote:
On Mon, Nov 26, 2012 at 11:43 AM, Andrew Dunstan and...@dunslane.net wrote:
I don't understand why you would want to create such a cast. If the cast
doesn't exist it will do exactly what it does now, i.e. use the type's
output function and then json
Andres Freund and...@2ndquadrant.com writes:
On 2012-11-27 13:45:08 -0500, Tom Lane wrote:
In short, all flag changes in pg_index should be done by
update-in-place, and the tuple's xmin will never change from the
original creating transaction (until frozen).
Hm. That doesn't sound that easy
Hello
I am sending a updated version - now it is prepared for event triggers
and it is little bit more robust
I run pgindent, but I have no experience with it, so I am not sure about success
Regards
Pavel Stehule
2012/10/7 Selena Deckelmann sel...@chesnok.com:
Hi!
On Tue, Jun 26, 2012 at
On 2012-11-27 14:41:34 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-11-27 13:45:08 -0500, Tom Lane wrote:
In short, all flag changes in pg_index should be done by
update-in-place, and the tuple's xmin will never change from the
original creating transaction
On Tue, 2012-11-27 at 14:13 -0500, Robert Haas wrote:
I do think that applying some kind of explicit flag to the function
indicating whether it should allow implicit assignment
casting/implicit casting to text/overloading/whatever is a possibly
interesting alternative. It seems clear from our
Robert Haas robertmh...@gmail.com writes:
I do think that applying some kind of explicit flag to the function
indicating whether it should allow implicit assignment
casting/implicit casting to text/overloading/whatever is a possibly
interesting alternative.
That idea seems possibly worth
* Tom Lane (t...@sss.pgh.pa.us) wrote:
It also affects developers, in that adding a
new overloaded version of a system function (that previously wasn't
overloaded) could actually reduce the number of cases for which the
function works without an explicit cast.
We have got to be really
On Tue, Nov 27, 2012 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Uh, no, not really, and I think that assertion just goes to show that
this area is more subtle than you think. quote_literal() for instance
presently works for any datatype that has an explicit cast to text.
That doesn't
On Tue, Nov 27, 2012 at 2:59 PM, Jeff Davis pg...@j-davis.com wrote:
What user action are you concerned about? If we (eventually) made the
non-overloaded case the default, would that resolve your concerns?
I can't quite see how a non-overloaded flag would work, unless we get
rid of schemas.
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 27, 2012 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
After making the change you propose above, it would only work for types
for which the cast was assignment-grade or less.
...but that's everything, because there's a hardcoded
Asif Rehman escribió:
Hi,
I have tried to solve this issue. Please see the attached patch.
With this patch, any expression is allowed in the return statement. For any
invalid expression an error is generated without doing any special handling.
When a row expression is used in the return
On Tue, Nov 27, 2012 at 3:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I do think that applying some kind of explicit flag to the function
indicating whether it should allow implicit assignment
casting/implicit casting to text/overloading/whatever is a
On 11/22/12 6:44 AM, Magnus Hagander wrote:
I'm thinking it might be a better idea to just have PG_CONNINFO_NORMAL
and PG_CONNINFO_PASSWORD (which still make sense to separate),
What is the use case for separating them?
and
then plug in the exclusion of specific parameters in pg_basebackup,
On Tue, Nov 27, 2012 at 10:13 PM, Peter Eisentraut pete...@gmx.net wrote:
On 11/22/12 6:44 AM, Magnus Hagander wrote:
I'm thinking it might be a better idea to just have PG_CONNINFO_NORMAL
and PG_CONNINFO_PASSWORD (which still make sense to separate),
What is the use case for separating them?
Andres Freund and...@2ndquadrant.com writes:
On 2012-11-27 14:41:34 -0500, Tom Lane wrote:
The stuff you are allowed to ALTER is pretty much
irrelevant to the index's life as an index.
Isn't inisprimary updated when an ALTER TABLE ... ADD PRIMARY KEY
... USING someindex ; is done? Also I
On 11/27/12 4:20 PM, Magnus Hagander wrote:
On Tue, Nov 27, 2012 at 10:13 PM, Peter Eisentraut pete...@gmx.net wrote:
On 11/22/12 6:44 AM, Magnus Hagander wrote:
I'm thinking it might be a better idea to just have PG_CONNINFO_NORMAL
and PG_CONNINFO_PASSWORD (which still make sense to
On 11/25/12 6:36 PM, Robert Haas wrote:
I think that is true. But for whatever it's worth, and at the risk of
beating a horse that seems not to be dead yet in spite of the fact
that I feel I've already administered one hell of a beating, the LPAD
case is unambiguous, and therefore it is hard
Peter Eisentraut wrote:
On 11/27/12 4:20 PM, Magnus Hagander wrote:
On Tue, Nov 27, 2012 at 10:13 PM, Peter Eisentraut pete...@gmx.net wrote:
On 11/22/12 6:44 AM, Magnus Hagander wrote:
I'm thinking it might be a better idea to just have PG_CONNINFO_NORMAL
and PG_CONNINFO_PASSWORD (which
On 11/25/12 7:21 PM, Robert Haas wrote:
Sure, in theory that is true, but no other RDBMS that I know about
feels a need to error out in that situation. I'm skeptical of the
contention that we're smarter than everyone else.
Well, I think in most programming languages that have typed function
Amit Kapila escribió:
Friday, November 23, 2012 5:38 AM Muhammad Usama wrote:
- I think when finding the max LSN of single file the utility should
consider all relation segments.
Would you like to find for all relation related segments:
Like 12345, 12345.1 ... 12345.nOr
12345,
On 11/27/12 12:07 PM, Merlin Moncure wrote:
Speaking of polymorphism, why not just implement lpad()'s first
argument as 'anyelement'?
One of the arguments made here was that lpad(not-text) *should* fail.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On 2012-11-27 16:31:15 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-11-27 14:41:34 -0500, Tom Lane wrote:
The stuff you are allowed to ALTER is pretty much
irrelevant to the index's life as an index.
Isn't inisprimary updated when an ALTER TABLE ... ADD
On Tue, Nov 27, 2012 at 4:09 PM, Peter Eisentraut pete...@gmx.net wrote:
On 11/27/12 12:07 PM, Merlin Moncure wrote:
Speaking of polymorphism, why not just implement lpad()'s first
argument as 'anyelement'?
One of the arguments made here was that lpad(not-text) *should* fail.
Well, sure. My
On Tue, 2012-11-27 at 15:41 -0500, Robert Haas wrote:
I can't quite see how a non-overloaded flag would work, unless we get
rid of schemas.
It may work to pick the first schema in the search path that has any
functions by that name, and then choose the overloaded (or not)
candidate from among
Merlin Moncure mmonc...@gmail.com writes:
... I think if you relaxed
the function sigs of a few functions on this page
(http://www.postgresql.org/docs/9.2/interactive/functions-string.html),
most reported problems would go away.
That's an interesting way of approaching it. Do we have any
On Tue, Nov 27, 2012 at 4:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
... I think if you relaxed
the function sigs of a few functions on this page
(http://www.postgresql.org/docs/9.2/interactive/functions-string.html),
most reported problems would go
On 11/27/12 2:41 PM, Tom Lane wrote:
Tweaking the casting rules could have a lot of
unforeseen consequences.
understatement of the year. IMHO. $0.02 worth etc.
--
john r pierceN 37, W 122
santa cruz ca mid-left coast
--
Sent via
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Peter Eisentraut wrote:
There is already the PQconninfoOption.dispchar field for this purpose.
I had the impression that that field would go away with this patch, but
then again it might not be worth the compatibility break. I find the
1. This patch applies current git head cleanly, but installation
ends up with failure because of the lack of
pgstattuple--1.0--1.1.sql which added in Makefile.
Added pgstattuple--1.0--1.1.sql.
Good. Installation completed and ALTER EXTENSION UPDATE works
with that.
2. I feel
On Mon, Nov 26, 2012 at 05:26:42PM -0500, Bruce Momjian wrote:
I have developed the attached proof-of-concept patch to test this idea.
Unfortunately, I got poor results:
pg_upgrade
dump restore dmp|res git
Andres Freund and...@2ndquadrant.com writes:
On 2012-11-27 16:31:15 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Isn't inisprimary updated when an ALTER TABLE ... ADD PRIMARY KEY
... USING someindex ; is done? Also I think indoption might be written
to as well.
Ugh,
On Tue, Nov 27, 2012 at 8:13 PM, Bruce Momjian br...@momjian.us wrote:
I have some new interesting results (in seconds, test script attached):
-Fc --- dump | pg_restore/psql -- -
pg_upgrade -
dump restore -Fc-Fc|-1 -Fc|-j -Fp-Fp|-1
On Wednesday, November 28, 2012 3:36 AM Alvaro Herrera wrote:
Amit Kapila escribió:
Friday, November 23, 2012 5:38 AM Muhammad Usama wrote:
- I think when finding the max LSN of single file the utility should
consider all relation segments.
Would you like to find for all relation
2012/11/28 Merlin Moncure mmonc...@gmail.com:
On Tue, Nov 27, 2012 at 4:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
... I think if you relaxed
the function sigs of a few functions on this page
On Nov 28, 2012 1:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Peter Eisentraut wrote:
There is already the PQconninfoOption.dispchar field for this purpose.
I had the impression that that field would go away with this patch, but
then again
On Tue, Nov 27, 2012 at 5:52 PM, Amit kapila amit.kap...@huawei.com wrote:
Friday, November 23, 2012 5:38 AM Muhammad Usama wrote:
Observations and Comments
---
- If no option is given to pg_computemaxlsn utility then we get a wrong
error
On Wed, Nov 28, 2012 at 3:06 AM, Alvaro Herrera alvhe...@2ndquadrant.comwrote:
Amit Kapila escribió:
Friday, November 23, 2012 5:38 AM Muhammad Usama wrote:
- I think when finding the max LSN of single file the utility should
consider all relation segments.
Would you like to find
pg_basebackup is taking backup of extra files other than database related
files in side a TABLESPACE directory.
Scenario:
1) Create tablespace in existing directory '/opt/tblspc' having
some extra files and folders.
create tablespace tbs1 location '/opt/tblspc';
On Wed, Nov 28, 2012 at 3:55 PM, Hari Babu haribabu.ko...@huawei.comwrote:
pg_basebackup is taking backup of extra files other than database related
files in side a TABLESPACE directory.
And why do you have files not related to your PG server inside a folder
dedicated to a PG server?
--
97 matches
Mail list logo
