On Fri, Nov 4, 2011 at 10:34 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> I guess with the changes that showed different thing like fastpath,
>> that makes sense. But if we just mapped the states that are there
>> today straight off, is there any case where waiting can be true, when
>> we're
On Fri, Nov 4, 2011 at 3:28 PM, Robert Haas wrote:
> On Fri, Nov 4, 2011 at 2:46 PM, Scott Mead wrote:
>> If waiting == true, then state = WAITING
>> else
>> state = appropriate state
>
> No, I think the state and waiting columns should be completely independent.
>
If they aren't I do
On Fri, Nov 4, 2011 at 3:12 PM, Simon Riggs wrote:
> On Fri, Nov 4, 2011 at 6:18 PM, Robert Haas wrote:
>
>> Here's a new version. I fixed the second pass as discussed (which
>> turned out to be trivial). To address the concern about relpages, I
>> moved this pre-existing line to after we get t
2011/11/3 Tom Lane
> I wrote:
> > (Just offhand, it rather looks like dict_int and dict_xsyn are both
> > assuming that palloc will give back zeroed space, which is bogus...)
>
> Yeah, this is definitely broken. Patches committed; thanks for the
> report.
>
> http://git.postgresql.org/gitweb/?p=p
On Fri, Nov 4, 2011 at 2:46 PM, Scott Mead wrote:
> If waiting == true, then state = WAITING
> else
> state = appropriate state
No, I think the state and waiting columns should be completely independent.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreS
On Fri, Nov 4, 2011 at 6:18 PM, Robert Haas wrote:
> Here's a new version. I fixed the second pass as discussed (which
> turned out to be trivial). To address the concern about relpages, I
> moved this pre-existing line to after we get the buffer lock:
>
> + vacrelstats->scanned_p
Scott Mead writes:
>I leave the waiting flag in place for posterity. With this in mind, is
> the consensus:
>RUNNING
> or
>ACTIVE
Personally, I'd go for lower case.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Fri, Nov 4, 2011 at 2:31 PM, Robert Haas wrote:
> On Fri, Nov 4, 2011 at 2:28 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> Maybe there's a better term than "running", like "in progress" or
> >> something of that sort.
> >
> > "active"?
>
> +1.
>
>Letting this one 'poll' a bit more be
On Fri, Nov 4, 2011 at 2:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> Maybe there's a better term than "running", like "in progress" or
>> something of that sort.
>
> "active"?
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql
On Fri, Nov 4, 2011 at 2:17 PM, Tom Lane wrote:
> Now, heap_page_prune is in a slightly different place, because it
> doesn't actually know whether the current backend is going to make an
> insertion or update in the page. If it did know that was going to
> happen, then the analogy would be exact
Robert Haas writes:
> Maybe there's a better term than "running", like "in progress" or
> something of that sort.
"active"?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
On Fri, Nov 4, 2011 at 12:46 PM, Marti Raudsepp wrote:
> On Fri, Nov 4, 2011 at 15:42, Tom Lane wrote:
>> Marti Raudsepp writes:
>>> While we're already breaking everything, we could remove the "waiting"
>>> column and use a state with value 'waiting' instead.
>
>> -1 ... I think it's useful to
On Thu, Nov 3, 2011 at 12:57 PM, Simon Riggs wrote:
> On Thu, Nov 3, 2011 at 2:22 PM, Robert Haas wrote:
>> On Thu, Nov 3, 2011 at 9:52 AM, Simon Riggs wrote:
>>> On Thu, Nov 3, 2011 at 1:26 PM, Robert Haas wrote:
>>>
I think that should be OK, but:
- It looks to me like you have
Robert Haas writes:
> On Fri, Nov 4, 2011 at 10:46 AM, Tom Lane wrote:
>> IIRC, this code is following the very longstanding precedent of
>> RelationGetBufferForTuple.
> I don't understand the analogy - that function isn't freeing any
> space, just searching for a block that already has some. A
On Wed, 2011-11-02 at 22:59 +0200, Heikki Linnakangas wrote:
> This seems to be coming from the selectivity estimation function. The
> selectivity function for <@ is scalargtsel, which is usually used for
> scalar > and >=. That doesn't seem right. But what do we store in the
> statistics for ra
On Wed, 2011-11-02 at 21:29 +0200, Heikki Linnakangas wrote:
> > + else if (lower1.infinite || upper1.infinite)
> > + length1 = 1.0/0.0;
>
> That seems wrong. I take it that the point is to set length1 to infinity?
I reworked this in commit (on my private repo, of course):
619
On Thu, 2011-11-03 at 10:37 +0200, Heikki Linnakangas wrote:
> Looking at the most recent patch, I don't actually see any GiST support
> for the empty and non-empty operators (!? and ?). I don't see how those
> could be accelerated with GiST, anyway; I think if you want to use an
> index for tho
Tom Lane wrote:
> Alvaro Herrera writes:
> > Excerpts from Alvaro Herrera's message of vie oct 28 16:47:13 -0300 2011:
> >> BTW we had previous discussions about dropping pg_database's toast
> >> table. Maybe this is a good time to do it, even if there's no risk of
> >> this bug (or the hypotheti
Josh Berkus wrote:
> > We can always do nothing, which is a safe and viable option.
>
> Not really, no. The whole recovery.conf thing is very broken and
> inhibits adoption of PostgreSQL because our users can't figure it out.
>
> You've made it pretty clear that you're personally comfortable wit
On Fri, Nov 4, 2011 at 15:42, Tom Lane wrote:
> Marti Raudsepp writes:
>> While we're already breaking everything, we could remove the "waiting"
>> column and use a state with value 'waiting' instead.
> -1 ... I think it's useful to see the underlying state as well as the
> waiting flag. Also,
On Fri, Nov 4, 2011 at 10:46 AM, Tom Lane wrote:
> Robert Haas writes:
>> Seems a little hackish, though: we'd be reporting an amount of
>> freespace that we've deliberately set to an incorrect value. I'm
>> almost thinking we should report the freespace that's actually
>> available, on the theo
Magnus Hagander writes:
> Would you find it better if we showed blank (NULL) when it was -1?
Yeah, I would. Seems less confusing.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
Magnus Hagander writes:
> Updated patch attached that does this, and the proper schema qualifications.
I'd schema-qualify the quote_ident and regclass names too.
Also, just as a matter of style, I think it'd be better to assign short
aliases to the table names ("pg_catalog.pg_class c" etc) and u
On Fri, Nov 4, 2011 at 15:23, Tom Lane wrote:
> Magnus Hagander writes:
>> The attached patch adds a column for statistics target when viewing
>> tables in psql using \d+.
>
>> Comments/reivews?
>
> Isn't this going to show -1 most of the time? Seems rather useless,
> not to mention confusing to
On Fri, Nov 4, 2011 at 15:44, Tom Lane wrote:
> Stephen Frost writes:
>> I just noticed it was pulling from pg_depend and we could be creating
>> multiple dependencies on a single sequence by having two tables use it
>> as a default value. If that situation doesn't cause a problem for this,
>> t
Robert Haas writes:
> Seems a little hackish, though: we'd be reporting an amount of
> freespace that we've deliberately set to an incorrect value. I'm
> almost thinking we should report the freespace that's actually
> available, on the theory that Bload Is Bad (TM).
IIRC, this code is following
Stephen Frost writes:
> I just noticed it was pulling from pg_depend and we could be creating
> multiple dependencies on a single sequence by having two tables use it
> as a default value. If that situation doesn't cause a problem for this,
> then that's fine. :) Couldn't remember if we distingu
On Fri, Nov 4, 2011 at 10:34 AM, Tom Lane wrote:
> Robert's point about sinval catchup is another good one, though
> I don't remember what that does to the pg_stat_activity display.
My thought was that sinval catchup might require acquiring a relation
lock (e.g. on pg_class), and that might block
On Thu, Nov 3, 2011 at 3:45 PM, Kevin Grittner
wrote:
> "Kevin Grittner" wrote:
>> Untested patch attached for purposes of discussion.
>
> I got in a little testing on it -- not only does this patch
> eliminate the compile-time warning, but if you try to run pg_upgrade
> when another session has
Magnus Hagander writes:
> On Fri, Nov 4, 2011 at 15:19, Tom Lane wrote:
>> The join conditions are far from adequate. You can *not* just check the
>> objid, you *must* check classid (and refclassid) to avoid being fooled
> Uh, it does check classid. Or are you saying it's checked the wrong way?
On Fri, Nov 4, 2011 at 15:29, Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
>> If there is noone owning it at all, it just falls through the if/else
>> block and ignores it if that happens (PQntuples() returns 0).
>
> Ah, right, but 'result' is still non-zero, ok.
Yes, tha
Magnus Hagander writes:
> I guess with the changes that showed different thing like fastpath,
> that makes sense. But if we just mapped the states that are there
> today straight off, is there any case where waiting can be true, when
> we're either idle or idle in transaction? I think not..
I'm n
* Magnus Hagander (mag...@hagander.net) wrote:
> If there is noone owning it at all, it just falls through the if/else
> block and ignores it if that happens (PQntuples() returns 0).
Ah, right, but 'result' is still non-zero, ok.
> Is there really a case for multiple sequences to own it? How woul
On Thu, Nov 3, 2011 at 10:18 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> Hmm, I was kind of expecting that to be wrong at least in some minor way.
>
>> +/* contrib/hstore/hstore-1.0-1.1.sql */
>> +
>> +-- complain if script is sourced in psql, rather than via CREATE EXTENSION
>> +\echo U
On 04/11/11 12:15, Florian Pflug wrote:
AFAICS, the internal storage layout of tsvector should allow you to extract an
individual lexem's positions quite efficiently (with time complexity log(N)
where
N is the number of lexems in the tsvector). Doing so will require you to
implement
your functi
On Fri, Nov 4, 2011 at 15:19, Tom Lane wrote:
> Magnus Hagander writes:
>> The attached patch makes the \d output for psql on a sequence show
>> which table/column owns the sequence. The table already showed the
>> dependency the other way through the default value, but going from
>> sequence bac
Magnus Hagander writes:
> The attached patch adds a column for statistics target when viewing
> tables in psql using \d+.
> Comments/reivews?
Isn't this going to show -1 most of the time? Seems rather useless,
not to mention confusing to people who don't know what that means.
On Wed, Nov 2, 2011 at 6:02 PM, Andrew Dunstan wrote:
> On 09/02/2011 03:15 PM, Josh Berkus wrote:
>>>
>>> OK, this seems to have some pluses and no negative comments, so it seems
>>> worth going forward. Do we want an equivalent pg_restore option?
>>
>> I'm not sure it's *as* important for pg_res
Magnus Hagander writes:
> The attached patch makes the \d output for psql on a sequence show
> which table/column owns the sequence. The table already showed the
> dependency the other way through the default value, but going from
> sequence back to table was not possible.
> Comments/reviews?
Th
2011/11/4 Josh Kupershmidt :
> On Fri, Nov 4, 2011 at 10:05 AM, Magnus Hagander wrote:
>> On Fri, Nov 4, 2011 at 14:53, Cédric Villemain
>>> Interesting, can the ouput be clear on the value being a default or an
>>> explicit stat target ? (not mandatory but I believe I would like to
>>> have it on
Magnus Hagander wrote:
>> Interesting, can the ouput be clear on the value being a default
>> or an explicit stat target ? (not mandatory but I believe I would
>> like to have it only when the stat target is jnot the default)
>
> It shows -1 when it's the default.
>
> We could map that to the
On Fri, Nov 4, 2011 at 15:09, Stephen Frost wrote:
> Magnus,
>
> * Magnus Hagander (mag...@hagander.net) wrote:
>> The attached patch makes the \d output for psql on a sequence show
>> which table/column owns the sequence. The table already showed the
>> dependency the other way through the defaul
On Fri, Nov 4, 2011 at 9:48 AM, Magnus Hagander wrote:
> On Fri, Nov 4, 2011 at 14:42, Tom Lane wrote:
> > Marti Raudsepp writes:
> >> While we're already breaking everything, we could remove the "waiting"
> >> column and use a state with value 'waiting' instead.
> >
> > -1 ... I think it's use
* Magnus Hagander (mag...@hagander.net) wrote:
> On Fri, Nov 4, 2011 at 15:06, Robert Haas wrote:
> >> Comments/reivews?
> >
> > "Statistics" doesn't seem like a very clear name for the column header.
>
> Got any ideas for a better one? "Statistics Target" seemed too long to
> me, and "Statstarge
On Fri, Nov 4, 2011 at 10:05 AM, Magnus Hagander wrote:
> On Fri, Nov 4, 2011 at 14:53, Cédric Villemain
>> Interesting, can the ouput be clear on the value being a default or an
>> explicit stat target ? (not mandatory but I believe I would like to
>> have it only when the stat target is jnot the
On Fri, Nov 4, 2011 at 10:09 AM, Magnus Hagander wrote:
> On Fri, Nov 4, 2011 at 15:06, Robert Haas wrote:
>> On Fri, Nov 4, 2011 at 9:34 AM, Magnus Hagander wrote:
>>> The attached patch adds a column for statistics target when viewing
>>> tables in psql using \d+.
>>>
>>> Comments/reivews?
>>
On Fri, Nov 4, 2011 at 9:48 AM, Magnus Hagander wrote:
> On Fri, Nov 4, 2011 at 14:42, Tom Lane wrote:
>> Marti Raudsepp writes:
>>> While we're already breaking everything, we could remove the "waiting"
>>> column and use a state with value 'waiting' instead.
>>
>> -1 ... I think it's useful to
On Fri, Nov 4, 2011 at 15:06, Robert Haas wrote:
> On Fri, Nov 4, 2011 at 9:34 AM, Magnus Hagander wrote:
>> The attached patch adds a column for statistics target when viewing
>> tables in psql using \d+.
>>
>> Comments/reivews?
>
> "Statistics" doesn't seem like a very clear name for the column
Magnus,
* Magnus Hagander (mag...@hagander.net) wrote:
> The attached patch makes the \d output for psql on a sequence show
> which table/column owns the sequence. The table already showed the
> dependency the other way through the default value, but going from
> sequence back to table was not pos
On Fri, Nov 4, 2011 at 9:34 AM, Magnus Hagander wrote:
> The attached patch adds a column for statistics target when viewing
> tables in psql using \d+.
>
> Comments/reivews?
"Statistics" doesn't seem like a very clear name for the column header.
--
Robert Haas
EnterpriseDB: http://www.enterpri
On Fri, Nov 4, 2011 at 14:53, Cédric Villemain
wrote:
> 2011/11/4 Magnus Hagander :
>> The attached patch adds a column for statistics target when viewing
>> tables in psql using \d+.
>>
>> Comments/reivews?
>
> Interesting, can the ouput be clear on the value being a default or an
> explicit stat
2011/11/4 Magnus Hagander :
> The attached patch adds a column for statistics target when viewing
> tables in psql using \d+.
>
> Comments/reivews?
Interesting, can the ouput be clear on the value being a default or an
explicit stat target ? (not mandatory but I believe I would like to
have it onl
On Fri, Nov 4, 2011 at 14:42, Tom Lane wrote:
> Marti Raudsepp writes:
>> While we're already breaking everything, we could remove the "waiting"
>> column and use a state with value 'waiting' instead.
>
> -1 ... I think it's useful to see the underlying state as well as the
> waiting flag. Also,
On Thu, Nov 3, 2011 at 8:27 PM, Jim Nasby wrote:
> On Nov 2, 2011, at 11:27 AM, Robert Haas wrote:
>> The following comment - or at least the last sentence thereof -
>> appears to be out of date.
>>
>> /*
>> * XXX Should we update the FSM information of this page ?
>> *
>>
On Fri, Nov 4, 2011 at 9:01 AM, Magnus Hagander wrote:
> The attached patch makes the \d output for psql on a sequence show
> which table/column owns the sequence. The table already showed the
> dependency the other way through the default value, but going from
> sequence back to table was not pos
Marti Raudsepp writes:
> While we're already breaking everything, we could remove the "waiting"
> column and use a state with value 'waiting' instead.
-1 ... I think it's useful to see the underlying state as well as the
waiting flag. Also, this would represent breakage of part of the API
that d
The attached patch adds a column for statistics target when viewing
tables in psql using \d+.
Comments/reivews?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index d5466f8..426d934 100644
---
2011/11/4 Miroslav Šimulčík :
> If I restrict any DML operation to internal tables (history tables) in phase
> of parse analyze, nobody can do such operation regardless of user rights.
There is absolutely zero point in trying to prevent the superuser from
doing whatever they want. The superuser h
On Fri, Nov 4, 2011 at 5:15 AM, Simon Riggs wrote:
> On Fri, Nov 4, 2011 at 2:36 AM, Fujii Masao wrote:
>> If we introduce "walrestore" process, pg_standby seems no longer useful.
>> We should get rid of it?
>
> Removing things too quickly can cause problems. There's no harm done
> by keeping it
The attached patch makes the \d output for psql on a sequence show
which table/column owns the sequence. The table already showed the
dependency the other way through the default value, but going from
sequence back to table was not possible.
Comments/reviews?
--
Magnus Hagander
Me: http://www.
On 17 December 2010 22:12, Peter Eisentraut wrote:
> I have often found myself wanting that psql automatically switch between
> normal and \x mode depending on the width of the output. Would others
> find this useful?
+1
Sounds like a very good idea.
--
Peter Geoghegan http://www.2ndQu
This patch adds basic support of arrays in foreign keys, by allowing to
define a referencing column as an array of elements having the same type
as the referenced column in the referenced table.
Every NOT NULL element in the referencing array is matched against the
referenced table.
Example:
On Wed, Nov 2, 2011 at 20:18, Scott Mead wrote:
> State will display , , in transaction, etc...
While we're already breaking everything, we could remove the "waiting"
column and use a state with value 'waiting' instead.
Also, returning these as text seems a little lame. Should there be an
en
On Tue, Nov 01, 2011 at 06:22:47AM +0200, Peter Eisentraut wrote:
> I wrote:
> > I have often found myself wanting that psql automatically switch between
> > normal and \x mode depending on the width of the output. Would others
> > find this useful?
> >
> > Attached is a crude demo patch. Enable
On Nov4, 2011, at 11:15 , Yoann Moreau wrote:
> On 03/11/11 19:19, Florian Pflug wrote:
>> Postgres doesn't seem to contain such a function currently (don't believe
>> that,
>> though - go and recheck the documentation. I don't know all thousands of
>> built-in
>> functions by heart). But it's ea
On Fri, Nov 4, 2011 at 11:08 AM, Dimitri Fontaine
wrote:
> Fujii Masao writes:
>> If we introduce "walrestore" process, pg_standby seems no longer useful.
>
> pg_standby is one possible restore_command, right? I had understood
> that walrestore would be the process that cares for running that
>
Fujii Masao writes:
> If we introduce "walrestore" process, pg_standby seems no longer useful.
pg_standby is one possible restore_command, right? I had understood
that walrestore would be the process that cares for running that
command, not another implementation of it.
That said, I would reall
Hello
I found a interesting issue when I checked a tsearch prefix searching.
We use a ispell based dictionary
CREATE TEXT SEARCH DICTIONARY cspell
(template=ispell, dictfile = czech, afffile=czech, stopwords=czech);
CREATE TEXT SEARCH CONFIGURATION cs (copy=english);
ALTER TEXT SEARCH CONFIGU
On 03/11/11 19:19, Florian Pflug wrote:
There's a difference between values of type tsvector, and what GIN indices
on columns or expressions of type tsvector store.
I was wondering what was the point about storing the tsvector in the
table, I now understand. I then should use the GIN index to
If I restrict any DML operation to internal tables (history tables) in
phase of parse analyze, nobody can do such operation regardless of user
rights. However, triggers can't be used in this case.
2011/11/4 Szymon Guz
>
>
> On 4 November 2011 10:20, Miroslav Šimulčík wrote:
>
>> Hi.
>>
>> I'm wo
On Fri, Nov 4, 2011 at 5:26 AM, Fujii Masao wrote:
>> Additionally what about moving all built-in functions defined in xlog.c
>> to xlogfuncs.c?
>
> Oh, you've already posted the patch which does that.
> http://archives.postgresql.org/message-id/CA+U5nMK=ybzczkdvj8kojfsz+d9lfmxvw+928nhu4x1hbyh...
On 4 November 2011 10:20, Miroslav Šimulčík wrote:
> Hi.
>
> I'm working on transactiontime temporal support for postgresql 9.0.4. Each
> original table with transactiontime support has associated history table,
> where original row is stored before each update or delete operation on it.
> Both o
Hi.
I'm working on transactiontime temporal support for postgresql 9.0.4. Each
original table with transactiontime support has associated history table,
where original row is stored before each update or delete operation on it.
Both original and history tables have internal timestamp columns for
s
On Fri, Nov 4, 2011 at 2:36 AM, Fujii Masao wrote:
> If we introduce "walrestore" process, pg_standby seems no longer useful.
> We should get rid of it?
Removing things too quickly can cause problems. There's no harm done
by keeping it a while longer.
I agree it should go, just want to be absol
On Fri, Nov 4, 2011 at 2:16 PM, Fujii Masao wrote:
> On Fri, Nov 4, 2011 at 3:14 AM, Simon Riggs wrote:
>> Next steps in refactoring are bigger steps, but not huge ones.
>>
>> I propose this
>>
>> * everything to do with XLOG rmgr into a file called xlogrmgr.c
>> Thats xlog_redo() and most everyt
On Fri, Nov 4, 2011 at 03:27, Fujii Masao wrote:
> On Thu, Nov 3, 2011 at 3:18 AM, Scott Mead wrote:
>> ISTM that we're all for:
>> creating a new column: state
>> renaming current_query => query
>> State will display , , in transaction, etc...
>> query will display the last query th
76 matches
Mail list logo
