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
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
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
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
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
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
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
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
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.
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
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:
> 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 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 and never clean it up.
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
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
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
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
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
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
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
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'
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
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
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 |
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 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
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 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
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, 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:
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, 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 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
-
-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
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
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
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<--
"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
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
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
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, 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,
"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
> 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
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
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
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
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
-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 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
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
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 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
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 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:
> 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
"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.
"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
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
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
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
> 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
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
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
"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
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
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%
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
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
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
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
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.
73 matches
Mail list logo
