I also think it is a good idea to summarize current status of
SE-PostgreSQL, as Simon Riggs doing on his works.
The current revision of SE-PostgreSQL is 1425, available here:
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1425.patch
[2/5]
http://sepgsql.googlecode.
Peter Eisentraut writes:
> CASE will be quite bad for optimization, and then you might as well go
> with IS DISTINCT FROM, which is just as bad but simpler.
Definitely avoid CASE if you can. Although the planner currently knows
nothing about IS DISTINCT FROM, that's fixable in principle. We'll
Here is my updated patch based on yours.
Outstanding issues, as far as I can see, are:
Critical:
* Updatability check must reject views where the select list references
the same column more than once.
* Various scenarios of REPLACE VIEW misbehave. I have marked these as
FIXME in the regres
On Fri, Jan 16, 2009 at 3:16 PM, Tom Lane wrote:
> Robert Haas writes:
>> I can't shake the feeling that this is about a couple
>> of PostgreSQL hackers (yourself included) not wanting to type \dfS or
>> \dfA or something to get the behavior they currently get with \df. If
>> that's the case, co
On Fri, 2009-01-16 at 22:09 +0200, Heikki Linnakangas wrote:
> >> RecentGlobalXmin is just a hint, it lags behind the real oldest xmin
> >> that GetOldestXmin() would return. If another backend has a more recent
> >> RecentGlobalXmin value, and has killed more recent tuples on the page,
> >> t
Zdenek Kotala wrote:
Severals animals complain about PL check. It seems that problem is in
new messages format introduced in latest update:
http://archives.postgresql.org/pgsql-committers/2009-01/msg00188.php
Datails:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_moth&dt=2009-01-15%
Robert Haas writes:
> I can't shake the feeling that this is about a couple
> of PostgreSQL hackers (yourself included) not wanting to type \dfS or
> \dfA or something to get the behavior they currently get with \df. If
> that's the case, come off it, because there's lots of evidence on this
> th
"Kevin Grittner" writes:
> Is the bare form (no U or S) going to search all schemas or the ones
> on the search path? Whatever the answer, do we need a way to get the
> other?
The former, if you specify "*.*" (or "*.anything") as your pattern.
The latter, if you don't specify a schema qualifier
Simon Riggs wrote:
On Fri, 2009-01-16 at 16:33 +0200, Heikki Linnakangas wrote:
I don't think RecentGlobalXmin is good enough here:
! /*
!* We would like to set an accurate latestRemovedXid,
but there
!* is no easy way of o
Robert Haas writes:
> I think you should make:
> \df - non-system only
> \dfS - system only
> \dfA - all
> Then you could make \dt the same way, and it wouldn't involve breaking
> the way \dt works now.
No, instead it would break \df. As I said before, a solution that was
designed for tables b
> Actually, now that I look at the code, the historical behavior of
> \d is even weirder than I thought:
>
>\d or \d+ *with no pattern* is equivalent to \dtvs(+)
>(and hence shows all user tables and no system tables)
>
>\d or \d+ *with a pattern* takes a completely
Josh Berkus writes:
> Tom,
>> which means that Robert's complaint about treating no-pattern
>> differently from pattern falls to the ground. It's exactly what
>> \d has done for years, and nobody has complained about that.
> Just because they haven't voiced loud complaints doesn't mean that they
On Fri, Jan 16, 2009 at 1:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> I feel pretty strongly that making the pattern search against a
>> different list of stuff than what the same command would display
>> without the pattern is confusing and a bad idea. It's a bad idea
>> regardless of which
Tom,
which means that Robert's complaint about treating no-pattern
differently from pattern falls to the ground. It's exactly what
\d has done for years, and nobody has complained about that.
Just because they haven't voiced loud complaints doesn't mean that they
haven't been *confused* by i
"Greg Sabino Mullane" writes:
>> I think either "\dfU a*" or "\dfU *.a*" is a sufficiently close
>> approximation to that. The behavior you are asking for is essentially
>> "I want to pay attention to the search path, except not actually follow
>> its rules", which is bogus. Either you want to s
"David E. Wheeler" writes:
> On Jan 16, 2009, at 10:43 AM, Joshua D. Drake wrote:
>>> but are we willing to change \d and \dt to work that way too?
>>> Or should we leave them inconsistent?
>>
>> I would prefer them consistent.
> I think that people will hate the changed behavior to \d and \dt.
>>> Tom Lane wrote:
> Comments? Does this cover all the cases?
I tend to think that changing which schemas are searched based on the
presence or absence of a search pattern is a bad idea.
Is the bare form (no U or S) going to search all schemas or the ones
on the search path? Whatever the a
On Jan 16, 2009, at 10:43 AM, Joshua D. Drake wrote:
\df -- all
\dfS-- system only
\dfU-- non-system only
but are we willing to change \d and \dt to work that way too?
Or should we leave them inconsistent?
I would prefer them consist
Tom Lane wrote:
Robert Haas writes:
I feel pretty strongly that making the pattern search against a
different list of stuff than what the same command would display
without the pattern is confusing and a bad idea. It's a bad idea
regardless of which particular backslash-sequence we're talking
On Fri, 2009-01-16 at 13:37 -0500, Tom Lane wrote:
> Robert Haas writes:
> > I feel pretty strongly that making the pattern search against a
> > different list of stuff than what the same command would display
> > without the pattern is confusing and a bad idea. It's a bad idea
> > regardless of
Robert Haas writes:
> I feel pretty strongly that making the pattern search against a
> different list of stuff than what the same command would display
> without the pattern is confusing and a bad idea. It's a bad idea
> regardless of which particular backslash-sequence we're talking about.
Wel
On Fri, 2009-01-16 at 16:33 +0200, Heikki Linnakangas wrote:
> I don't think RecentGlobalXmin is good enough here:
>
> > ! /*
> > !* We would like to set an accurate latestRemovedXid,
> > but there
> > !* is no easy way of obtaining a use
On Fri, Jan 16, 2009 at 1:09 PM, Tom Lane wrote:
> Robert Haas writes:
>> Changing the scope of the search on the basis of whether or not a
>> pattern is present strikes me as a terrible idea. It's confusing and
>> unlikely to make anyone happy.
>
> Huh? The pattern itself "changes the scope of
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> I think either "\dfU a*" or "\dfU *.a*" is a sufficiently close
> approximation to that. The behavior you are asking for is essentially
> "I want to pay attention to the search path, except not actually follow
> its rules", which is bogus. E
On Fri, Jan 16, 2009 at 06:39:11PM +0100, Gianni Ciolli wrote:
(...)
> During a Warm Standby session using current HEAD I obtained the
> following error on the standby node:
On Fri, Jan 16, 2009 at 12:56:59PM -0500, Tom Lane wrote:
> Gianni Ciolli writes:
> > we found a bug while testing the late
Robert Haas writes:
> Changing the scope of the search on the basis of whether or not a
> pattern is present strikes me as a terrible idea. It's confusing and
> unlikely to make anyone happy.
Huh? The pattern itself "changes the scope of the search", so I don't
see how this is a conceptual viol
David Fetter writes:
> Basically, there is no way I've found so far to qualify any window
> function in the target list, which makes a giant POLA violation.
The FM points out in at least two places that window functions logically
execute on the output of the WHERE/GROUP BY/HAVING steps. It's
co
Gianni Ciolli writes:
> we found a bug while testing the latest version of Hot Standby. Then
> we could reproduce it on the unpatched HEAD, so we are going to ignore
> it in the next few days.
You didn't actually say how to repeat it on unpatched HEAD.
regards, tom lane
> One issue here is that plain \d gets less useful because it'll now
> include system catalogs. We could add the additional rule that
> the above statements apply only when a pattern is specified, and
> without a pattern you get just user stuff (so omitting a pattern
> corresponds to pattern "*" w
"Greg Sabino Mullane" writes:
>> Comments? Does this cover all the cases?
> No: the user case someone had upthread, where they want to see all their
> functions starting with an "a" across all schemas in their path:
> \df a*
I think either "\dfU a*" or "\dfU *.a*" is a sufficiently close
appro
On Fri, Jan 16, 2009 at 12:41:59PM -0500, Tom Lane wrote:
> David Fetter writes:
> > We don't appear to be able to use the actual thing in the target list
> > either.
>
> Would you translate that into English? Or at least an example without
> trivial syntax errors?
This works:
SELECT
typ,
On Fri, 2009-01-16 at 12:15 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > No need to wait for idle-in-transaction sessions during index builds.
> > GetCurrentVirtualXIDs() specifically *includes* backends that have
> > proc->xmin == InvalidTransactionId (0), but I'm not sure why.
>
> Because
On Fri, 2009-01-16 at 12:40 -0500, Tom Lane wrote:
> "Joshua D. Drake" writes:
> >>> Again, "\dfS" would be a bit useless, unless we say that the implicit
> >>> U modifier for no pattern doesn't override an explicit S modifier.
> >>>
> >>> Comments? Does this cover all the cases?
> >>
> >> So
David Fetter writes:
> We don't appear to be able to use the actual thing in the target list
> either.
Would you translate that into English? Or at least an example without
trivial syntax errors?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
"Joshua D. Drake" writes:
> On Fri, 2009-01-16 at 09:14 -0800, David E. Wheeler wrote:
>> On Jan 16, 2009, at 8:36 AM, Tom Lane wrote:
>>> One issue here is that plain \d gets less useful because it'll now
>>> include system catalogs. We could add the additional rule that
>>> the above statements
Hello,
we found a bug while testing the latest version of Hot Standby. Then
we could reproduce it on the unpatched HEAD, so we are going to ignore
it in the next few days.
During a Warm Standby session using current HEAD I obtained the
following error on the standby node:
---8<--8<--8<--
On Fri, Jan 16, 2009 at 12:34:34PM -0500, Tom Lane wrote:
> David Fetter writes:
> > I tried this:
>
> > SELECT
> > typ,
> > ts,
> > rank() over w AS foo_rank
> > FROM
> > foo
> > WINDOW w AS (partition by typ order by ts desc)
> > WHERE
> > foo_rank < 4;
>
> > ERROR
On Jan 16, 2009, at 9:35 AM, Tom Lane wrote:
So would "\df" then be equivalent to "\dU"? Or am I misunderstanding
something?
You mean "\dfU"? Yes, if there's no pattern.
Yeah, that's what I meant. Thanks. +1.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> One issue here is that plain \d gets less useful because it'll now
> include system catalogs.
Are you kidding me? No way. That's a recipe for making all our users
unhappy with us.
> * \dfU will restrict the printout to non-system functions
"David E. Wheeler" writes:
> On Jan 16, 2009, at 8:36 AM, Tom Lane wrote:
>> Comments? Does this cover all the cases?
> So would "\df" then be equivalent to "\dU"? Or am I misunderstanding
> something?
You mean "\dfU"? Yes, if there's no pattern.
regards, tom lane
-
On Fri, 2009-01-16 at 12:13 -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > Simon Riggs wrote:
> >> SnapshotResetXmin is called 3 times after each statement in
> >> ReadCommitted mode.
>
> > Maybe we could check whether TransState is not TRANS_INPROGRESS and skip
> > it in those cases ...?
>
David Fetter writes:
> I tried this:
> SELECT
> typ,
> ts,
> rank() over w AS foo_rank
> FROM
> foo
> WINDOW w AS (partition by typ order by ts desc)
> WHERE
> foo_rank < 4;
> ERROR: syntax error at or near "WHERE"
> LINE 8: WHERE
> ^
RTFM ... WINDOW goes a
On Fri, Jan 16, 2009 at 12:23:16PM -0500, Jaime Casanova wrote:
> On Fri, Jan 16, 2009 at 12:07 PM, David Fetter wrote:
> >>
> >> Now i want only 3 records for every typ:
> >>
> >> test=# select typ, ts, rank() over (partition by typ order by ts desc )
> >> from foo where rank <= 3;
> >> ERROR:
On Fri, Jan 16, 2009 at 12:07 PM, David Fetter wrote:
>>
>> Now i want only 3 records for every typ:
>>
>> test=# select typ, ts, rank() over (partition by typ order by ts desc )
>> from foo where rank <= 3;
>> ERROR: column "rank" does not exist
>> LINE 1: ...rtition by typ order by ts desc )
On Fri, 2009-01-16 at 09:14 -0800, David E. Wheeler wrote:
> On Jan 16, 2009, at 8:36 AM, Tom Lane wrote:
>
> > One issue here is that plain \d gets less useful because it'll now
> > include system catalogs. We could add the additional rule that
> > the above statements apply only when a pattern
Simon Riggs writes:
> No need to wait for idle-in-transaction sessions during index builds.
> GetCurrentVirtualXIDs() specifically *includes* backends that have
> proc->xmin == InvalidTransactionId (0), but I'm not sure why.
Because they might be about to change xmin to something real?
On Jan 16, 2009, at 8:36 AM, Tom Lane wrote:
One issue here is that plain \d gets less useful because it'll now
include system catalogs. We could add the additional rule that
the above statements apply only when a pattern is specified, and
without a pattern you get just user stuff (so omitting
Alvaro Herrera writes:
> Simon Riggs wrote:
>> SnapshotResetXmin is called 3 times after each statement in
>> ReadCommitted mode.
> Maybe we could check whether TransState is not TRANS_INPROGRESS and skip
> it in those cases ...?
Surely this would take longer than the function itself does. What
On Thu, Jan 15, 2009 at 03:06:47PM +0100, A. Kretschmer wrote:
> Hi,
>
> first, many thanks to all for the great work, i'm waiting for 8.4.
>
>
> I have played with the new possibilities:
>
> test=# select typ, ts, rank() over (partition by typ order by ts desc ) from
> foo;
> typ |
No need to wait for idle-in-transaction sessions during index builds.
GetCurrentVirtualXIDs() specifically *includes* backends that have
proc->xmin == InvalidTransactionId (0), but I'm not sure why.
$SUBJECT is currently used by DefineIndex() to wait for all backends
that might be able to see ind
Simon Riggs wrote:
>
> SnapshotResetXmin is called 3 times after each statement in
> ReadCommitted mode.
>
> Too keen, perhaps?
It is called each time a snapshot is unregistered and each time an
active snapshot is popped. I don't see any way to reduce the number of
calls without complicating th
Gregory Stark writes:
> So it seems to me that we made \df consistent with \dt when in fact what we
> really wanted is for it to be consistent with \d. I hadn't actually realized
> that the behaviour for \d was so different from \dt myself.
Yeah, given that the battle cry for this patch was "let'
SnapshotResetXmin is called 3 times after each statement in
ReadCommitted mode.
Too keen, perhaps?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
Tom Lane writes:
> Well, as I said before, I'm not averse to having the default behavior
> *with no pattern* to be that we omit system objects --- and I think we
> could make that apply across the board. What I'm saying is that when
> you give a pattern it should not matter whether an object is
Tom Lane wrote:
> Alvaro Herrera writes:
>> Magnus Hagander wrote:
>>> If you want to override this behavior today, you can just call
>>> WSAStartup() in your application, and it should never happen. Right?
>
>> Or perhaps use _init() and _fini() or the Win32 equivalents?
>
> I thought we were a
Alvaro Herrera writes:
> Magnus Hagander wrote:
>> If you want to override this behavior today, you can just call
>> WSAStartup() in your application, and it should never happen. Right?
> Or perhaps use _init() and _fini() or the Win32 equivalents?
I thought we were already relying on DLL load/u
Andrew Dunstan wrote:
>
> Zdenek Kotala wrote:
>> URL Links to changed files diff are broken in the buildfarm report. See
>>
>> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_moth&dt=2009-01-15%2021:06:00
>>
>> Links points to the:
>>
>> http://developer.postgresql.org/cvsweb.cgi/pgsql/sr
Zdenek Kotala wrote:
URL Links to changed files diff are broken in the buildfarm report. See
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_moth&dt=2009-01-15%2021:06:00
Links points to the:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpython/nls.mk?rev=1.2
instead of
On 1/16/09, Magnus Hagander wrote:
> Andrew Chernow wrote:
> > WSACleanup is not really needed during a PQfinish. Its horribly slow if
> > the library ref count is 0 and it actually unloads the winsock library,
> > adds 225ms to PQfinish.
>
> Option A will make us leak the reference to it tho
Alvaro Herrera wrote:
Magnus Hagander wrote:
Andrew Chernow wrote:
WSACleanup is not really needed during a PQfinish. Its horribly slow if
the library ref count is 0 and it actually unloads the winsock library,
adds 225ms to PQfinish.
Solution:
A) Call WSAStartup once and never clean it up.
I have merged this with HEAD, written a brief document (which is mostly
a copy of the btree-gist page), added the module to the contrib
Makefile, and made some very minor changes. Patch attached.
Thank you
A couple comments:
1. Right now, to implement "less than" you need to start at the
begi
Alvaro Herrera wrote:
> Magnus Hagander wrote:
>> Andrew Chernow wrote:
>>> WSACleanup is not really needed during a PQfinish. Its horribly slow if
>>> the library ref count is 0 and it actually unloads the winsock library,
>>> adds 225ms to PQfinish.
>>>
>>> Solution:
>>> A) Call WSAStartup once
I don't think RecentGlobalXmin is good enough here:
! /*
!* We would like to set an accurate latestRemovedXid,
but there
!* is no easy way of obtaining a useful value. So we
use the
!* probably far to
Alvaro Herrera wrote:
Heikki Linnakangas escribió:
This patch adds a new column to pg_autovacuum, reflecting the new
vacuum_freeze_table_age GUC just like freeze_min_age column reflects
vacuum_freeze_min_age. If I commit this tomorrow, will I cause you a
lot of trouble with the reloptions patc
Magnus Hagander wrote:
> Andrew Chernow wrote:
> > WSACleanup is not really needed during a PQfinish. Its horribly slow if
> > the library ref count is 0 and it actually unloads the winsock library,
> > adds 225ms to PQfinish.
> >
> > Solution:
> > A) Call WSAStartup once and never clean it up.
Magnus Hagander wrote:
Andrew Chernow wrote:
WSACleanup is not really needed during a PQfinish. Its horribly slow if
the library ref count is 0 and it actually unloads the winsock library,
adds 225ms to PQfinish.
Solution:
A) Call WSAStartup once and never clean it up. When the app dies, so
Andrew Chernow wrote:
> WSACleanup is not really needed during a PQfinish. Its horribly slow if
> the library ref count is 0 and it actually unloads the winsock library,
> adds 225ms to PQfinish.
>
> Solution:
> A) Call WSAStartup once and never clean it up. When the app dies, so do
> the ref c
New version. Changes:
- synced with current CVS
- added all your changes
- autovacuum will run if fast update mode is turned on and
trigger of fresh tuple is fired
- gincostestimate now tries to calculate cost of scan of pending pages.
gincostestimate set disable_cost if it believe that
Stephen Frost wrote:
> Alvaro,
>
> * Alvaro Herrera (alvhe...@commandprompt.com) wrote:
>> Tom Lane escribió:
>>> If you have an idle evening you might want to peruse all the past
>>> threads about developing better support for modules.
>> All the useful material in this area is linked to on the T
Heikki Linnakangas writes:
> Jeff Davis wrote:
>> On Fri, 2009-01-09 at 13:49 +0200, Heikki Linnakangas wrote:
>>>
>>> I'm now leaning towards:
>>>
>>> autovacuum_freeze_max_age
>>> vacuum_freeze_table_age
>>> vacuum_freeze_min_age
>>>
>>> where autovacuum_freeze_max_age and vacuum_freeze_min_age
URL Links to changed files diff are broken in the buildfarm report. See
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_moth&dt=2009-01-15%2021:06:00
Links points to the:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpython/nls.mk?rev=1.2
instead of
http://anoncvs.postgre
Severals animals complain about PL check. It seems that problem is in
new messages format introduced in latest update:
http://archives.postgresql.org/pgsql-committers/2009-01/msg00188.php
Datails:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_moth&dt=2009-01-15%2021:06:00
I updated my patch set of SE-PostgreSQL and related stuff (r1425).
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1425.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1425.patch
[3/5]
http://sepgsql.googlecode.com/files/sepostgresql-po
73 matches
Mail list logo
