On Wed, Nov 28, 2012 at 3:55 PM, Hari Babu wrote:
> 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?
--
Michael Paquier
http://micha
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:06 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 rela
On Tue, Nov 27, 2012 at 5:52 PM, Amit kapila 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 message
> > ./pg_c
On Nov 28, 2012 1:54 AM, "Tom Lane" wrote:
>
> Alvaro Herrera 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 comp
2012/11/28 Merlin Moncure :
> On Tue, Nov 27, 2012 at 4:41 PM, Tom Lane wrote:
>> Merlin Moncure 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 woul
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 a
On Tue, Nov 27, 2012 at 8:13 PM, Bruce Momjian 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 git
>
Andres Freund writes:
> On 2012-11-27 16:31:15 -0500, Tom Lane wrote:
>> Andres Freund 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, you're right. Somebody wasn't p
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
> > 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 f
Alvaro Herrera 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
> dispchar thingy somewhat u
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 pgsql-
On Tue, Nov 27, 2012 at 4:41 PM, Tom Lane wrote:
> Merlin Moncure 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 interestin
Merlin Moncure 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 data on
exactly wh
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
On Tue, Nov 27, 2012 at 4:09 PM, Peter Eisentraut 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 point is
On 2012-11-27 16:31:15 -0500, Tom Lane wrote:
> Andres Freund 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
>
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 t
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
>
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
Peter Eisentraut wrote:
> On 11/27/12 4:20 PM, Magnus Hagander wrote:
> > On Tue, Nov 27, 2012 at 10:13 PM, Peter Eisentraut 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 st
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 ha
On 11/27/12 4:20 PM, Magnus Hagander wrote:
> On Tue, Nov 27, 2012 at 10:13 PM, Peter Eisentraut 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),
>>
>>
Andres Freund 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 think indoption mig
On Tue, Nov 27, 2012 at 10:13 PM, Peter Eisentraut 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?
Getting
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_basebacku
On Tue, Nov 27, 2012 at 3:21 PM, Tom Lane wrote:
> Robert Haas 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
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 re
Robert Haas writes:
> On Tue, Nov 27, 2012 at 2:26 PM, Tom Lane 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 exception in the
> code that dictates that
On Tue, Nov 27, 2012 at 2:59 PM, Jeff Davis 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. But I think there
On Tue, Nov 27, 2012 at 2:26 PM, Tom Lane 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 appear to be the beh
* 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
Robert Haas 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 pursuing. The thing t
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
On 2012-11-27 14:41:34 -0500, Tom Lane wrote:
> Andres Freund 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 froz
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 :
> Hi!
>
> On Tue, Jun 26, 2012 at 1:19 AM, Pavel S
Andres Freund 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 to guarantee. S
On 11/26/2012 12:31 PM, Robert Haas wrote:
On Mon, Nov 26, 2012 at 11:43 AM, Andrew Dunstan 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 quote and escape it,
Robert Haas 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 simplify things for f
On Tue, Nov 27, 2012 at 1:45 PM, Jeff Davis 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 few if any co
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 paren
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 13:45:08 -0500, Tom Lane wrote:
> Andres Freund 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 th
On Tue, Nov 27, 2012 at 12:47 PM, Tom Lane wrote:
> Robert Haas 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 g
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 contentious.
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 ab
Andres Freund 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 other two
>> flag
On 2012-11-27 12:50:36 -0500, Tom Lane wrote:
> Andres Freund 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 a wrapper macr
Andres Freund 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 callsites of
> Relat
Robert Haas 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 insert casts that
On 2012-11-27 12:02:09 -0500, Tom Lane wrote:
> Andres Freund 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
On Tue, Nov 27, 2012 at 4:46 AM, Jeff Davis 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 their
> qu
On Tue, Nov 27, 2012 at 12:02 PM, Tom Lane 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 touching the index an
On Tue, Nov 27, 2012 at 10:52 AM, Pavel Stehule 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 'anyelement'? ISTM th
Andres Freund 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 could break
>> it.
[ Sorry for the slow response on this, Thanksgiving interfered. ]
On Wed, Nov 21, 2012 at 3:41 PM, Andres Freund 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 node
> of the root n
2012/11/27 Bruce Momjian :
> 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
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
Alvaro Herrera 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 think splitting t
Andres Freund writes:
> On 2012-11-27 01:14:27 -0500, Tom Lane wrote:
>> Peter Eisentraut 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 shortcut to reduce some very
> mi
2012/11/27 David Johnston :
>> -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 Hacker
> -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] Materia
On Mon, Nov 19, 2012 at 2:46 PM, Tom Lane wrote:
> Jeff Davis 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 code in
> IndexOnlyNext is co
Dimitri Fontaine 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 ROW;
> UPDATE MA
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 c
"Kevin Grittner" 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 that in rela
On Tue, Nov 27, 2012 at 8:45 AM, Michael Paquier
wrote:
>
>
> On Tue, Nov 27, 2012 at 7:35 PM, Dimitri Fontaine
> wrote:
>>
>> Peter Eisentraut 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
Dimitri Fontaine wrote:
> "Kevin Grittner" 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
>> only changed the data contained within the
>> object a
"Kevin Grittner" 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
> only changed the data contained within the object and had no other
> impact. Are you
On Nov 27, 2012, at 5:25, Dimitri Fontaine 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 locking behavio
On 09.10.2012 17:44, Vik Reykja wrote:
On Tue, Oct 9, 2012 at 4:09 PM, Tom Lane wrote:
=?ISO-8859-1?Q?S=E9bastien_Lardi=E8re?= writes:
Indeed, brackets was not correct, it's better now (I think), and correct
some comments.
Still wrong ... at the very least you missed copyfuncs/equalfuncs.
Hi,
Pavel Stehule 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 indexes, exporting default
Pavel Stehule wrote:
> 2012/11/27 Dimitri Fontaine :
>> 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 support, and that
Hello
2012/11/12 Tomas Vondra :
> 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 - basically the
On Tue, Nov 27, 2012 at 7:35 PM, Dimitri Fontaine wrote:
> Peter Eisentraut 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?
>
+1, the current versi
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)" e
On Tue, Nov 27, 2012 at 4:49 PM, Andres Freund wrote:
> 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 statements
On Tue, Nov 27, 2012 at 11:38 AM, Tom Lane wrote:
> Pavan Deolasee writes:
> > On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane 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
On 2012-11-27 16:39:58 +0530, Pavan Deolasee wrote:
> On Tue, Nov 27, 2012 at 4:22 PM, Andres Freund wrote:
>
> > 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 mi
On 2012-11-26 22:44:49 -0500, Tom Lane wrote:
> Andres Freund 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 really though
On Tue, Nov 27, 2012 at 4:22 PM, Andres Freund wrote:
> 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
> > transformFkeyCheckAttrs makes me pr
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 wrote:
> > >
> > > > I wrote:
> > > >
> > > > Either state of indcheckxmin is valid with a
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 wrote:
> >
> > > I wrote:
> > >
> > > Either state of indcheckxmin is valid with all three of these
> > > combinations, so the specific kluge I was
On 2012-11-27 10:18:37 +0530, Pavan Deolasee wrote:
> On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane 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 valid rea
Peter Eisentraut 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, Formation et Suppo
2012/11/27 Dimitri Fontaine :
> Peter Eisentraut 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
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
Peter Eisentraut 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 refresh a M
On 2012-11-26 16:39:39 -0500, Tom Lane wrote:
> Andres Freund 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 Simon how t
Hello all
2012/11/27 Jeff Davis :
> 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
Hello
2012/11/27 Piyush Newe :
>
> 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
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 applic
On 2012-11-27 01:14:27 -0500, Tom Lane wrote:
> Peter Eisentraut 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*)’:
> > src
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 unnece
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 as
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
automati
97 matches
Mail list logo
