Re: [HACKERS] guc fallback to default

2007-01-29 Thread Zdenek Kotala

Joachim Wieland wrote:

I'm working again on the patch for making guc variables fall back to their
default value if they get removed (or commented) in the configuration file.

There is still an issue with custom variables that needs discussion.

Remember that for regular variables we have the following semantics:

BEGIN;
SET enable_seqscan TO off;
COMMIT;

The effect of the commit on the variable is that the variable is set to the
specified value from then on in that session (outside of the transaction).

This is also valid for custom variables. But those can be removed from the
configuration file while all other variables can not (all other variables
fall back to some default value).

Imagine the following example:

Configuration file:
custom_variable_classes = foo
foo.var = 3

In a session we do:
BEGIN;
SET foo.var TO 5;

With the transaction still being open, we remove the definition of foo.var
from the configuration file and send SIGHUP.

Then we commit the transaction:

COMMIT;

So what should happen?

Interpretation 1:
foo.var got deleted. COMMIT can not assure that the value of
foo.var gets applied, because foo.var does not exist anymore.
The transaction fails.

Interpretation 2:
The foo.var variable from the configuration file got deleted but the
SET command in the transaction defines a new variable which is
valid, because we still have custom_variable_classes = foo. The
transaction succeeds.



Current status is when you change variable value in conf file, it 
changes inside all transaction also. However if SET command is used then 
value is override and any change in conf file does not affect this 
variable. SET command has higher priority and override all changes in 
postgresql.conf.


In this point of view I think interpretation 2 is correct.


Zdenek


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


[HACKERS] Petizione

2007-01-29 Thread Enrico
Dateci un occhio

http://www.petitiononline.com/RESETINC/petition.html

Enrico
-- 
If Bill Gates had a penny for everytime Windows crashed,he'd be a 
multi-billionaire by now ...oh look, he already is 
[EMAIL PROTECTED] - Skype:sscotty71
http://www.linuxtime.it/enricopirozzi

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


[HACKERS] Phantom command ids again

2007-01-29 Thread Heikki Linnakangas

Hi,

I was about to resubmit the phantom command ids patch for review, as I 
noticed a little problem.


In fmgr.c in record_C_func, we cache the xmin and cmin, and later in 
lookup_C_func we check that they match to determine if the cached 
information is still valid. With phantom command ids, the cmin is not 
valid outside the inserting transaction, which makes it unusable for 
that purpose.


Similar caching code is used for other PL languages as well.

The best solution I've come up with this far is to use the stored 
commandid, even if it's a phantom one, and a flag indicating if it's 
phantom or not. Any suggestions?


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] Recursive query syntax ambiguity

2007-01-29 Thread Gregory Stark
Tom Lane [EMAIL PROTECTED] writes:

 Gregory Stark [EMAIL PROTECTED] writes:
 Having fixed that everything works fine with SET and WITH being reserved
 keywords. You didn't mean to say I should be able to leave WITH unreserved 
 did
 you?

 I think we'd decided that was a lost cause, unless you see a way?

No, I decided it was a lost cause right at the start of this. I was just
double checking that you didn't think otherwise when you said you didn't see
anything else that needed to be reserved.

 Of course that was the easy part...

 Yup ;-)


I think I've finally wrapped my head around the idea of mutually recursive and
non-linearly recursive queries. Good thing too since in thinking about them I
realized that the approach I had intended to use for plain non-recursive
queries wasn't really adequate and needs the same machinery.

The fundamental feature Postgres needs to implement this that it doesn't have
is the ability to be running the same subplan from two different contexts in
the plan simultaneously. That is, the ability to start a scan from the
beginning without disturbing a scan already in progress for that same node.

In retrospect this isn't terribly surprising since it's the same
characteristic functions need in a programming language to be safely callable
recursively. They need to be reentrant.

The normal way to make functions reentrant is to remove all local state and
make the caller responsible for providing space to allocate memory for
temporary state. But teaching every node type about passing its state up to
the parent including bundling up all the state of its children seems like too
much work. Both for me and the computer :)

In any case that would result in an n^2 algorithm for recursive queries as it
would force the executor to re-execute each node for the same record over and
over. Much as the obvious recursive fibonacci algorithm is n^2 for example.
It also would mean making non-recursive WITH clauses pointless since they
would still be executed once per call-site.

Instead I suggest we create one type of reentrant node, which memoizes its
output. It would be a kind of on-demand Materialize. It would be paired with a
second node type which would be the only type of node which can invoke it.
This RecursiveCall node would invoke the Memoize node using a special
interface in which it passes enough state for the Memoize node to seek to the
correct place in its output.

Because it memoizes its output it should never actually need to be able to
handle recursive calls. When the call depth is maximum each call site would be
able to make at most 1 call to the Memoize node. A second one would
necessarily have been stopped higher up the call chain by the memoization
table. (I've convinced myself that that's true but I should probably work out
a good proof of it before I make all this depend on it.)

There are three general cases of the Memoize node. Breadth-first, Depth-first,
and non-linearly-recursive. 

In the case of breadth-first search we would want to keep two tuplestore
around, one for the current generation, and one for its parent. Once we finish
a generation we can free its parent since we know a linearly-recursive scan
won't be needing it any more.

In the case of depth-first we really want to memoize into a stack. I'm not
sure how to fit that into our current model of tuplestores. At worst though,
we just allocate a tuplestore for each generation as it appears. We can still
throw away old generations once their scans are finished, it just won't be
until quite late.

Non-linearly-recursive searches are the same case as non-recursive queries.
Memoize would just allocate one tuplestore and store tuples blindly without
any idea of generation. It could arrange to throw away old tuples whenever
all call-sites' scans have past them. That's the same optimization Simon wants
to make in the merge-join case when the mark is moved forward.

There are a few open issues to consider. Namely, how to cost a RecursiveCall
node.

Also, if a subplan has exactly one call-site we really ought to inline it as
it will get much more reliable plans. Similarly if there are two call sites we
should consider inlining it if the cost of materializing the results (and
reading them back) is more than n-call-sites x the cost of executing the
query. I would expect That would happen with plain sequential scans for
example.

Note that we need the Memoize/RecursiveCall nodes even for non-recursive
queries. Except in the simplest cases where each common table expression only
has a single call site (in which case we could have just inlined them anyways)
we need some way to retain state and avoid reexecuting the plan multiple
times.

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] Phantom command ids again

2007-01-29 Thread Tom Lane
Heikki Linnakangas [EMAIL PROTECTED] writes:
 I was about to resubmit the phantom command ids patch for review, as I 
 noticed a little problem.

 In fmgr.c in record_C_func, we cache the xmin and cmin, and later in 
 lookup_C_func we check that they match to determine if the cached 
 information is still valid. With phantom command ids, the cmin is not 
 valid outside the inserting transaction, which makes it unusable for 
 that purpose.

I think that actually that's just belt-and-suspenders programming;
it should be sufficient to compare tuple TID and xmin.  AFAICS a single
transaction cannot fill the same TID twice, since VACUUM would never
dare remove a tuple entered by a still-in-progress transaction.  So the
cmin check doesn't seem necessary.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] Phantom command ids again

2007-01-29 Thread Heikki Linnakangas

Tom Lane wrote:

Heikki Linnakangas [EMAIL PROTECTED] writes:
I was about to resubmit the phantom command ids patch for review, as I 
noticed a little problem.


In fmgr.c in record_C_func, we cache the xmin and cmin, and later in 
lookup_C_func we check that they match to determine if the cached 
information is still valid. With phantom command ids, the cmin is not 
valid outside the inserting transaction, which makes it unusable for 
that purpose.


I think that actually that's just belt-and-suspenders programming;
it should be sufficient to compare tuple TID and xmin.  AFAICS a single
transaction cannot fill the same TID twice, since VACUUM would never
dare remove a tuple entered by a still-in-progress transaction.  So the
cmin check doesn't seem necessary.


We don't currently use tid in the up-to-dateness check. Just  Oid, xmin 
and cmin. Good point, tid would work. I'll change it do that in the patch.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


[HACKERS] shared_preload_libraries support on Win32?

2007-01-29 Thread korryd
(working on the PL debugger...) 

It appears that the libraries listed in shared_preload_libraries will
*not* be inherited by spawned backends on Win32 platforms.

Do we have to do something special to make that work?

Using ProcessExplorer (from sysinternals.com), I can see that my plugins
are loaded into the postmaster, but not into the individual backends.

If I set local_preload_libraries equal to shared_preload_libraries, the
plugins are loaded into the backends as expected (so it seems unlikely
that I have a pathname or permissions problem).

Should we just call process_shared_preload_libraries() after calling
read_nondefault_variables() (in SubPostmasterMain())?

-- Korry


--
  Korry Douglas[EMAIL PROTECTED]
  EnterpriseDB  http://www.enterprisedb.com


Re: [HACKERS] shared_preload_libraries support on Win32?

2007-01-29 Thread Tom Lane
[EMAIL PROTECTED] writes:
 It appears that the libraries listed in shared_preload_libraries will
 *not* be inherited by spawned backends on Win32 platforms.

Well, yeah, because it's a fork/exec on that platform.

 Should we just call process_shared_preload_libraries() after calling
 read_nondefault_variables() (in SubPostmasterMain())?

I don't entirely see the point.  The value of shared_preload_libraries
is to avoid paying per-process overhead to load the libraries, and that
benefit is already lost in a fork/exec world.  Might as well just let
the libraries be loaded when and if needed.

I think we've failed to document that shared_preload_libraries doesn't
work on Windows, which is an oversight.

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] shared_preload_libraries support on Win32?

2007-01-29 Thread Andrew Dunstan



Tom Lane wrote:

[EMAIL PROTECTED] writes:
  

It appears that the libraries listed in shared_preload_libraries will
*not* be inherited by spawned backends on Win32 platforms.



Well, yeah, because it's a fork/exec on that platform.

  

Should we just call process_shared_preload_libraries() after calling
read_nondefault_variables() (in SubPostmasterMain())?



I don't entirely see the point.  The value of shared_preload_libraries
is to avoid paying per-process overhead to load the libraries, and that
benefit is already lost in a fork/exec world.  Might as well just let
the libraries be loaded when and if needed.

  


The only benefit I can see is that it would assist in having a common 
configuration.



I think we've failed to document that shared_preload_libraries doesn't
work on Windows, which is an oversight.

  


Maybe postmaster should also log a warning if it detects this.

cheers

andrew


---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] shared_preload_libraries support on Win32?

2007-01-29 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes:
 Tom Lane wrote:
 I don't entirely see the point.  The value of shared_preload_libraries
 is to avoid paying per-process overhead to load the libraries, and that
 benefit is already lost in a fork/exec world.  Might as well just let
 the libraries be loaded when and if needed.

 The only benefit I can see is that it would assist in having a common 
 configuration.

Actually ... I take that back.  I was thinking of the original purpose
of preload_libraries, which was strictly performance optimization.
But in the new world of plugins there may be functional reasons for
wanting libraries to be loaded into backends --- and
shared_preload_libraries is not isomorphic to local_preload_libraries.
The permissions situation is different.

Korry's right, we should force re-loading of shared_preload_libraries
in the EXEC_BACKEND case.  The needed documentation change is to point
out that on Windows this is not a performance win, but it might still
be wanted for instrumentation or debugging plugins.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] Updateable cursors

2007-01-29 Thread Richard Troy

On Wed, 24 Jan 2007, John Bartlett wrote:
[regarding optional DBA/SysAdmin logging of Updateable Cursors]

 I can see where you are coming from but I am not sure if a new log entry
 would be such a good idea. The result of creating such a low level log could
 be to increase the amount of logging by a rather large amount.


Given that logging can be controlled via the contents of postgresql.conf,
this sounds like an answer from someone who's never had to support a
production environment; Putting a check for log_min_error_statement being
set to, say, info, hardly seems like a big burden to me. A casual study of
the controls in postgresql.conf reveals we already have many controlls to
get things logged when we want/need them - all of which were deemed
appropriate previously. So ISTM that if the DBA/SysAdmin thinks they need
the information, who are you to tell them, in effect, No, I don't want
you to have to spend any of your machine's performace giving you the
information you need?

Help your user by giving them information when they want it. ... Do you
argue that this is useless information?

Richard

-- 
Richard Troy, Chief Scientist
Science Tools Corporation
510-924-1363 or 202-747-1263
[EMAIL PROTECTED], http://ScienceTools.com/


---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [HACKERS] [BUGS] Missing error message on missing ssl-key-files

2007-01-29 Thread Magnus Hagander
Harald Armin Massa wrote:
 PostgreSQL 8.1.5 and 8.2.1
 
 both on W2K3, installed from the standard win32 msi installer.
 
 Problem:
 
 in postgresql.conf
 
 ssl=on
 
 but the files server.key etc. are NOT present.
 
 Result: PostgreSQL service does not start. And no error message in any
 log I could access: nothing in the Windows Event Log, nothing in the
 pg_log (not even starts a file)
 
 [in this case it was me doing the SSL-setup, missing to copy the key
 files; BUT... they could get deleted / made inaccessible a later time,
 and THEN it get's impossible to diagnose the problem]
 
 Proposed solution:
 write an error message to pg_log/ or windows event log on missing
 ssl-server-key-files.


I took a quick look at this, and it's certainly correct. If I change the
log_destination to be eventlog, it works and logs the proper error message.

This may show a much bigger problem. When we have set redirect_stderr
(which is what the MSI installer does by default), what happens to
everything that is logged *before* SysLogger_Start()? There are a lot of
startup things that happen then, but where does the output go?

I'm thinking we need a check in elog.c on the:
if ((!Redirect_stderr || am_syslogger)  pgwin32_is_service())
write_eventlog(edata-elevel, buf.data);


line, that checks if the syslogger process has been started yet. So it'd
 be something like
if ((!Redirect_stderr || am_syslogger || syslogger_not_started_yet) 
pgwin32_is_service())


Does that seem reasonable? Or am I looking at this the wrong way?

//Magnus

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] 10 weeks to feature freeze (Pending Work)

2007-01-29 Thread Magnus Hagander
Henry B. Hotz wrote:
 Henry B. Hotz:  GSSAPI authentication method for C (FE/BE) and Java (FE).
 Magnus Haglander:  SSPI (GSSAPI compatible) authentication method for C
 (FE) on Windows.
 
 (That fair Magnus? Or you want to volunteer for BE support as well?)

Seems fair and about what we discussed. And no, I won't volunteer as
long as you're on it - not sure I'll have the time to do it all in time.


 GSSAPI isn't much more than a functional replacement for Kerberos 5, but
 it's supported on lots more platforms.  In particular Java and Windows
 have native support (as well as Solaris 9).

Yeah, getting rid of the dependency on MIT KRB5 on windows would be very
nice indeeed.


//Magnus


---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] psql possible TODO

2007-01-29 Thread Alvaro Herrera
Joshua D. Drake wrote:
 On Fri, 2006-12-29 at 20:59 -0500, Bruce Momjian wrote:
  Alvaro Herrera wrote:
   Tom Lane wrote:
Richard Troy [EMAIL PROTECTED] writes:
 ... it occurs to me that perhaps Josh can implement
 a command line switch to turn on command line numbering.

That would solve the problem I have with changing \s.  I think a psql
\set variable (comparable to ON_ERROR_STOP and friends) might be the way
to go instead of inventing another \-command, but it's not real
important.
   
   So, is anybody working on this?  I think it should be put in the TODO
   list:
   
- Allow psql to display item numbers along each history item, depending
  on a \set variable
  
  I thought Joshua Drake was going to submit a patch, but if doesn't
  appear shortly, I will add it to the TODO list with the agreed API.
 
 I will claim this for now. I will let it go if I can't get at least
 something productive done on it by end of January.

Now that the embargo period seems to be over, I think it would be a good
time to add it to the TODO list.  Also, I'd modify the idea slightly to
allow a more general facility, using %-escapes (or similar) for line
numbers, dates and so on.  Bash allows something like this (albeit
limited to only times) using the HISTTIMEFORMAT environment variable.

This is the first case I know of of an embargo to an agreed TODO item.
Why was it put in place?  I find it distracting, because the item has to
be put on someone else's TODO list and then that person has to pinch
others to get it added to the central TODO list.  Not sure I see the
point.  (I understand about bashing Joshua ---a sport I also practice in
Command Prompt's internal lists ;-) --- but in this case it seems to be
counterproductive).

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] shared_preload_libraries support on Win32?

2007-01-29 Thread korryd
 Actually ... I take that back.  I was thinking of the original purpose
 of preload_libraries, which was strictly performance optimization.
 But in the new world of plugins there may be functional reasons for
 wanting libraries to be loaded into backends --- and
 shared_preload_libraries is not isomorphic to local_preload_libraries.
 The permissions situation is different.


And, shared_preload_libraries is processed (in the postmaster) before
the shared-memory segment is created, so a shared_preload_library can
call RequestAddinShmemSpace() and RequestAddinLWLocks(), but a
local_preload_library cannot.


-- Korry


Re: [HACKERS] weird buildfarm failures on arm/mipsel and --with-tcl

2007-01-29 Thread Stefan Kaltenbrunner
Tom Lane wrote:
 I wrote:
 One possibility for fixing it is that maybe we should be making an
 effort to execute Tcl_Finalize() before exiting the backend.  If so,
 having pltcl set up an on_proc_exit callback to do it would be the
 appropriate thing.  This is all speculation though.
 
 Just for grins I tried this, and I can see by strace'ing that it changes
 the process-shutdown-time behavior quite a lot: the secondary thread now
 exits first, apparently after being told to via a message from the
 primary.  So I think this might indeed be something good to do.  Would
 you try the attached patch and see if it changes the behavior on your
 systems?  (This patch is very ugly and will draw compiler warnings, but
 don't worry about that yet.)

this patch definitly changes behaviour but not actually for the better :-(

after running the tcl regression tests and exiting psql I'm left with
two(!) backends(and I'm unable to stop the postmaster short of using -m
immedidate):


UIDPID  PPID   LWP  C NLWP STIME TTY  TIME CMD
1000  7191 1  7191  01 19:02 pts/000:00:03
/home/mastermind/pginst/bin/postgres -D /home/mastermind/data
1000  7202  7191  7202  01 19:02 ?00:00:00 postgres:
writer process
1000  7203  7191  7203  01 19:02 ?00:00:00 postgres:
stats collector process
1000  7235  7191  7235  01 19:06 ?00:00:01 postgres:
mastermind pl_regression [local] idle
1000  7267  7235  7267  01 19:08 ?00:00:00 postgres:
mastermind pl_regression [local] idle

tracefile for 7235:

http://www.kaltenbrunner.cc/files/strace2.out

backtrace for 7235:

(gdb) bt
#0  0x41f04d80 in __pthread_sigsuspend () from /lib/libpthread.so.0
#1  0x41f03a7c in __pthread_wait_for_restart_signal () from
/lib/libpthread.so.0
#2  0x41f05d18 in pthread_key_delete () from /lib/libpthread.so.0
#3  0x41edbe1c in TclpFinalizeThreadDataKey () from /usr/lib/libtcl8.4.so.0
#4  0x41ec96dc in TclFinalizeSynchronization () from /usr/lib/libtcl8.4.so.0
#5  0x41e92040 in Tcl_Finalize () from /usr/lib/libtcl8.4.so.0
#6  0x001ab204 in proc_exit (code=0) at ipc.c:109
#7  0x001be3a8 in PostgresMain (argc=1074783216, argv=value optimized
out, username=0x0) at postgres.c:3638
#8  0x0018fb98 in ServerLoop () at postmaster.c:2953
#9  0x00190898 in PostmasterMain (argc=3, argv=0x36e5c0) at postmaster.c:963
#10 0x001468b0 in main (argc=3, argv=value optimized out) at main.c:188


Stefan

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] weird buildfarm failures on arm/mipsel and --with-tcl

2007-01-29 Thread Alvaro Herrera
Stefan Kaltenbrunner wrote:

 backtrace for 7235:
 
 (gdb) bt

Please do this in GDB:

thread apply all bt

(or maybe it is
threads apply all bt)

This'll give you backtraces for all threads in the process.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] weird buildfarm failures on arm/mipsel and --with-tcl

2007-01-29 Thread Tom Lane
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
 this patch definitly changes behaviour but not actually for the better :-(

Oh well, it was worth a try.  At this point I think we have to suppose
this is a Tcl bug and not our fault.  Can you reproduce the problem in
bare tclsh?  Try

$ tclsh
% interp create
interp0
% interp create -safe
interp1
% exit
$

If tclsh doesn't quit when told then it's easy to file (but you might
want to try the latest tcl version first --- they're up to 8.4.14)

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] weird buildfarm failures on arm/mipsel and --with-tcl

2007-01-29 Thread Stefan Kaltenbrunner
Alvaro Herrera wrote:
 Stefan Kaltenbrunner wrote:
 
 backtrace for 7235:

 (gdb) bt
 
 Please do this in GDB:
 
 thread apply all bt
 
 (or maybe it is
 threads apply all bt)
 
 This'll give you backtraces for all threads in the process.

sorry forgot to mention that - the backtrace for the other one is an
endless loop of:

Thread 2 (Thread 32769 (LWP 7267)):
#0  0x4018062c in poll () from /lib/libc.so.6
#1  0x41f023b4 in __pthread_manager () from /lib/libpthread.so.0
#2  0x41f023b4 in __pthread_manager () from /lib/libpthread.so.0
#3  0x41f023b4 in __pthread_manager () from /lib/libpthread.so.0
#4  0x41f023b4 in __pthread_manager () from /lib/libpthread.so.0
#5  0x41f023b4 in __pthread_manager () from /lib/libpthread.so.0
#6  0x41f023b4 in __pthread_manager () from /lib/libpthread.so.0
#7  0x41f023b4 in __pthread_manager () from /lib/libpthread.so.0
#8  0x41f023b4 in __pthread_manager () from /lib/libpthread.so.0
#9  0x41f023b4 in __pthread_manager () from /lib/libpthread.so.0
#10 0x41f023b4 in __pthread_manager () from /lib/libpthread.so.0
#11 0x41f023b4 in __pthread_manager () from /lib/libpthread.so.0
#12 0x41f023b4 in __pthread_manager () from /lib/libpthread.so.0


Stefan

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


[HACKERS] XML type and XPath

2007-01-29 Thread Peter Eisentraut
Now that the xml type as per SQL:2003 is pretty much finished, one 
starts to wonder about what useful things one might do with it.  What 
we have so far contains only functions to construct XML values from SQL 
data, but there is nothing that you can do with the type at the moment 
except look at it.

The basic kind of operation on XML values is XPath queries.  This is the 
equivalent of what substring/position/length/concat/etc. does for text 
types, and it's also the gist of the contrib/xml2 module, and it's 
typically provided by other DBMS with XML support.  SQL:2003 says 
nothing on the matter, whereas SQL:2006 specifies XQuery support, but I 
don't think we can implement that at the moment because there is no 
library available to do it.  (XPath is in libxml2.)

So, while I realize that I've been arguing for a lean core recently, I 
want to propose that we add a small set of XPath support functions to 
the core.  This would come down to approximately the following set

xpath_boolean(query, xml)
xpath_number(query, xml)
xpath_string(query, xml)
xpath_nodeset(query, xml) -- API and return type still unclear

We also have prospects that later on we might get fancy GIN-based 
indexing support for XPath, which might need another xpath_matches() 
function or operator of some kind.

As far as contrib/xml2 is concerned, I'm not going to make any efforts 
to make the interface compatible because that module has a rather 
pragmatic design, whereas I'd rather just provide the raw operations 
that can be assembled easily by the user to achieve some of the things 
that contrib/xml2 does now.  Once some description of transition steps 
has been developed, I'd deprecate the contrib/xml2 module and probably 
remove it after 8.3.

In the wiki we have collected some random ideas of other interesting 
operations on XML types 
(http://developer.postgresql.org/index.php/XML_Todo, near the bottom). 
That list at the moment says:

DTD validation
Relax-NG
XSLT
XML Canonical (to compare XML values)
Pretty-printing XML (e.g., indenting)

I would argue for keeping these sort of things in a non-core module or a 
PgFoundry repository.  

Comments?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] shared_preload_libraries support on Win32?

2007-01-29 Thread Tom Lane
[EMAIL PROTECTED] writes:
 But in the new world of plugins there may be functional reasons for
 wanting libraries to be loaded into backends --- and
 shared_preload_libraries is not isomorphic to local_preload_libraries.
 The permissions situation is different.

 And, shared_preload_libraries is processed (in the postmaster) before
 the shared-memory segment is created, so a shared_preload_library can
 call RequestAddinShmemSpace() and RequestAddinLWLocks(), but a
 local_preload_library cannot.

That doesn't seem like an issue though, since the copy in the postmaster
will have done that anyway.

regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] weird buildfarm failures on arm/mipsel and --with-tcl

2007-01-29 Thread Stefan Kaltenbrunner
Tom Lane wrote:
 Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
 this patch definitly changes behaviour but not actually for the better :-(
 
 Oh well, it was worth a try.  At this point I think we have to suppose
 this is a Tcl bug and not our fault.  Can you reproduce the problem in
 bare tclsh?  Try
 
   $ tclsh
   % interp create
   interp0
   % interp create -safe
   interp1
   % exit
   $
 
 If tclsh doesn't quit when told then it's easy to file (but you might
 want to try the latest tcl version first --- they're up to 8.4.14)

hmm the above sequence just works fine on that box - will experiment
with a more recent version as time permits (there is no other version
available in the debian repo right now which makes this a bit more
difficult).

Stefan

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] [pgsql-patches] Autovacuum launcher patch

2007-01-29 Thread Markus Schiltknecht

Alvaro Herrera wrote:

I'd suggest sticking to something closer to the current two-phase design
where you make some preliminary decision which database to send a worker
to, and then the worker determines exactly what to do once it can look
around inside the DB.  Possibly we need some back-signaling mechanism
whereby a worker can tell the launcher hey boss, send help if it sees
that there are enough tables that need work, but I'm unenthused about
having the launcher figure that out itself.


Hmm, yeah, we'll probably need some communication channel eventually.


Maybe my IMessages code could be of use?

It's still awfully slow compared with UNIX pipes or even System V IPC 
message queues, since it uses LWLocks for sending and retrieving 
messages. That could certainly be optimized, maybe even towards a 
lock-free implementation, which could theoretically be as fast as System 
V IPC messages. OTOH, such stuff is hard to get right.


Regards

Markus

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] shared_preload_libraries support on Win32?

2007-01-29 Thread korryd
  And, shared_preload_libraries is processed (in the postmaster) before
  the shared-memory segment is created, so a shared_preload_library can
  call RequestAddinShmemSpace() and RequestAddinLWLocks(), but a
  local_preload_library cannot.
 
 That doesn't seem like an issue though, since the copy in the postmaster
 will have done that anyway.


You're right - we need the copy in the postmaster (to setup shared
memory and LW locks), and we need them in the backends too.  I just want
to avoid having to set both shared_preload_libraries and
local_preload_libraries (to the same thing).  Adding a call to
process_shared_preload_libraries() in SubPostmasterMain() seems to fix
the problem for me.

Thanks for your input.  I'll submit a patch.


-- Korry


Re: [HACKERS] [pgsql-patches] Autovacuum launcher patch

2007-01-29 Thread Alvaro Herrera
Markus Schiltknecht wrote:
 Alvaro Herrera wrote:
 I'd suggest sticking to something closer to the current two-phase design
 where you make some preliminary decision which database to send a worker
 to, and then the worker determines exactly what to do once it can look
 around inside the DB.  Possibly we need some back-signaling mechanism
 whereby a worker can tell the launcher hey boss, send help if it sees
 that there are enough tables that need work, but I'm unenthused about
 having the launcher figure that out itself.
 
 Hmm, yeah, we'll probably need some communication channel eventually.
 
 Maybe my IMessages code could be of use?
 
 It's still awfully slow compared with UNIX pipes or even System V IPC 
 message queues, since it uses LWLocks for sending and retrieving 
 messages. That could certainly be optimized, maybe even towards a 
 lock-free implementation, which could theoretically be as fast as System 
 V IPC messages. OTOH, such stuff is hard to get right.

Hmm, I remember eyeballing that code.  Would you mind sending me an URL
to that file, or something?  Or maybe send me the files themselves?

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] shared_preload_libraries support on Win32?

2007-01-29 Thread Alvaro Herrera
[EMAIL PROTECTED] wrote:
   And, shared_preload_libraries is processed (in the postmaster) before
   the shared-memory segment is created, so a shared_preload_library can
   call RequestAddinShmemSpace() and RequestAddinLWLocks(), but a
   local_preload_library cannot.
  
  That doesn't seem like an issue though, since the copy in the postmaster
  will have done that anyway.
 
 
 You're right - we need the copy in the postmaster (to setup shared
 memory and LW locks), and we need them in the backends too.  I just want
 to avoid having to set both shared_preload_libraries and
 local_preload_libraries (to the same thing).  Adding a call to
 process_shared_preload_libraries() in SubPostmasterMain() seems to fix
 the problem for me.

Just make sure you don't load the libraries in bgwriter et al ...

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] 10 weeks to feature freeze (Pending Work)

2007-01-29 Thread Henry B. Hotz


On Jan 29, 2007, at 9:49 AM, Magnus Hagander wrote:


Henry B. Hotz wrote:
Henry B. Hotz:  GSSAPI authentication method for C (FE/BE) and  
Java (FE).
Magnus Haglander:  SSPI (GSSAPI compatible) authentication method  
for C

(FE) on Windows.

(That fair Magnus? Or you want to volunteer for BE support as well?)


Seems fair and about what we discussed. And no, I won't volunteer as
long as you're on it - not sure I'll have the time to do it all in  
time.


I'm only volunteering BE for Unix, not Windows.  Not sure we need BE  
for Windows for 8.3 though.  This is enough.


The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]



---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] shared_preload_libraries support on Win32?

2007-01-29 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes:
 [EMAIL PROTECTED] wrote:
 You're right - we need the copy in the postmaster (to setup shared
 memory and LW locks), and we need them in the backends too.

 Just make sure you don't load the libraries in bgwriter et al ...

I see that Korry's patch doesn't do that, but I'm wondering why exactly.
In a Unix environment such libraries *would* be propagated into bgwriter
and every other postmaster child; is there a reason for the setup on
Windows to be different?  In particular, what about autovacuum, which
ISTM should be as close to a standard backend as possible?

Either way we do it, authors of plugins used this way will have to test
both cases (I'm glad I insisted on EXEC_BACKEND mode being testable under
Unix ...)

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] Modifying and solidifying contrib

2007-01-29 Thread Bruce Momjian
David Fetter wrote:
 On Sun, Jan 28, 2007 at 02:14:36PM -0800, Joshua D. Drake wrote:
   I don't think all or nothing is a good way to do this.  500
   functions in a schema called extensions isn't much more helpful
   than 500 in public.  There's a reason namespaces were invented
   long ago, and this is classic use case for same. :)
  
  I disagree, see my post previously about initializing the extensions
  schema to not be accessible initially. It would be there, it would
  be loaded, but it would take a superuser to grant ability to access
  functions.
  
  This allows a clean distinction between the modules while allowing
  their access on a case by case basis.
 
 It's 982 functions as of this writing in CVS TIP's contrib.  Do you
 not get how wacky it is to have that many functions, none of which
 have any collision-prevention built into their install scripts, in a
 flat namespace?

We currently have 1695 standard functions.  I don't see a problem with
putting the extensions all in one schema, but I also don't see the
point.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] Modifying and solidifying contrib

2007-01-29 Thread Andrew Dunstan

Bruce Momjian wrote:

David Fetter wrote:
  

It's 982 functions as of this writing in CVS TIP's contrib.  Do you
not get how wacky it is to have that many functions, none of which
have any collision-prevention built into their install scripts, in a
flat namespace?



We currently have 1695 standard functions.  I don't see a problem with
putting the extensions all in one schema, but I also don't see the
point.

  


I certainly don't see the point.  But I do see a considerable point in 
having extensions use their own schemas. The fact that we have 1695 
standard functions means we bear the responsibility of ensuring we don't 
have name clashes among them. We should encourage extension authors by 
example to use the namespace facility to relieve themselves of having to 
ensure they don't clash not only with the standard functions but with 
other extensions. IOW we should act with respect to the namespace for 
extensions we distribute just like we would reasonably expect authors of 
third party extensions to behave.


For backwards compatibility, we might be well advised also to distribute 
load scripts that put extension objects in the public schema as is done 
now, but this should be a deprecated practice, IMNSHO.


cheers

andrew

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [HACKERS] Modifying and solidifying contrib

2007-01-29 Thread Bruce Momjian

Keep in mind all contrib loads into public, and I don't remember any
namespace conflict issues in the past.

---

Andrew Dunstan wrote:
 Bruce Momjian wrote:
  David Fetter wrote:

  It's 982 functions as of this writing in CVS TIP's contrib.  Do you
  not get how wacky it is to have that many functions, none of which
  have any collision-prevention built into their install scripts, in a
  flat namespace?
  
 
  We currently have 1695 standard functions.  I don't see a problem with
  putting the extensions all in one schema, but I also don't see the
  point.
 

 
 I certainly don't see the point.  But I do see a considerable point in 
 having extensions use their own schemas. The fact that we have 1695 
 standard functions means we bear the responsibility of ensuring we don't 
 have name clashes among them. We should encourage extension authors by 
 example to use the namespace facility to relieve themselves of having to 
 ensure they don't clash not only with the standard functions but with 
 other extensions. IOW we should act with respect to the namespace for 
 extensions we distribute just like we would reasonably expect authors of 
 third party extensions to behave.
 
 For backwards compatibility, we might be well advised also to distribute 
 load scripts that put extension objects in the public schema as is done 
 now, but this should be a deprecated practice, IMNSHO.
 
 cheers
 
 andrew
 
 ---(end of broadcast)---
 TIP 3: Have you checked our extensive FAQ?
 
http://www.postgresql.org/docs/faq

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] Modifying and solidifying contrib

2007-01-29 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
 Keep in mind all contrib loads into public, and I don't remember any
 namespace conflict issues in the past.

(A) I'm not sure we would have heard about it, and (B) any one user is
probably only using a subset of what has been proposed to be loaded by
default, so the odds of collisions would go way up.

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] Modifying and solidifying contrib

2007-01-29 Thread Andrew Dunstan

Bruce Momjian wrote:

Keep in mind all contrib loads into public, and I don't remember any
namespace conflict issues in the past.
  


That is beside the point. Of course there haven't been conflicts - 
precisely because a single group controls the whole lot. What I said was 
that we should behave as sane third party extension authors would, 
namely to use their own namespace to protect themselves from conflicts 
with other unknown extensions. It's called setting a good example or 
eating your own dog food.


cheers

andrew



---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Modifying and solidifying contrib

2007-01-29 Thread Bruce Momjian
Andrew Dunstan wrote:
 Bruce Momjian wrote:
  Keep in mind all contrib loads into public, and I don't remember any
  namespace conflict issues in the past.

 
 That is beside the point. Of course there haven't been conflicts - 
 precisely because a single group controls the whole lot. What I said was 
 that we should behave as sane third party extension authors would, 
 namely to use their own namespace to protect themselves from conflicts 
 with other unknown extensions. It's called setting a good example or 
 eating your own dog food.

The problem I see controlling per-user search_path if +10 extensions are
instlalled, and you want them always to be available by default.

Also, are we going to use per-schema permissions so that the schemas are
not visible by default?  That _might_ allow us to install more by
default.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Modifying and solidifying contrib

2007-01-29 Thread Andrew Dunstan

Bruce Momjian wrote:

Andrew Dunstan wrote:
  

Bruce Momjian wrote:


Keep in mind all contrib loads into public, and I don't remember any
namespace conflict issues in the past.
  
  
That is beside the point. Of course there haven't been conflicts - 
precisely because a single group controls the whole lot. What I said was 
that we should behave as sane third party extension authors would, 
namely to use their own namespace to protect themselves from conflicts 
with other unknown extensions. It's called setting a good example or 
eating your own dog food.



The problem I see controlling per-user search_path if +10 extensions are
instlalled, and you want them always to be available by default.
  


This suggests maybe we need to look at beefing up a few things. For 
example, an alias facility that provided a name in schema X for things 
in schema Y would help lots here. (You want everything visible? Just 
alias it in public.) ISTR such things in DB2, although it's now many 
years since I laid hands on it, so my memory could well be very faulty.


Also, ability to append to the search path rather than just set it could 
help, as might ability to add names of non-existent schemas (which would 
be ignored at run time when found not to exist).


cheers

andrew



---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] Modifying and solidifying contrib

2007-01-29 Thread Bruce Momjian
Andrew Dunstan wrote:
 Bruce Momjian wrote:
  Andrew Dunstan wrote:

  Bruce Momjian wrote:
  
  Keep in mind all contrib loads into public, and I don't remember any
  namespace conflict issues in the past.


  That is beside the point. Of course there haven't been conflicts - 
  precisely because a single group controls the whole lot. What I said was 
  that we should behave as sane third party extension authors would, 
  namely to use their own namespace to protect themselves from conflicts 
  with other unknown extensions. It's called setting a good example or 
  eating your own dog food.
  
 
  The problem I see controlling per-user search_path if +10 extensions are
  instlalled, and you want them always to be available by default.

 
 This suggests maybe we need to look at beefing up a few things. For 
 example, an alias facility that provided a name in schema X for things 
 in schema Y would help lots here. (You want everything visible? Just 
 alias it in public.) ISTR such things in DB2, although it's now many 
 years since I laid hands on it, so my memory could well be very faulty.

I think that is SYNONYM.

 Also, ability to append to the search path rather than just set it could 
 help, as might ability to add names of non-existent schemas (which would 
 be ignored at run time when found not to exist).

Agreed.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] Modifying and solidifying contrib

2007-01-29 Thread David Fetter
On Mon, Jan 29, 2007 at 04:44:44PM -0500, Andrew Dunstan wrote:
 Bruce Momjian wrote:
 Andrew Dunstan wrote:
   
 Bruce Momjian wrote:
 
 Keep in mind all contrib loads into public, and I don't remember any
 namespace conflict issues in the past.
   
 That is beside the point. Of course there haven't been conflicts -
 precisely because a single group controls the whole lot. What I
 said was that we should behave as sane third party extension
 authors would, namely to use their own namespace to protect
 themselves from conflicts with other unknown extensions. It's
 called setting a good example or eating your own dog food.
 
 The problem I see controlling per-user search_path if +10
 extensions are instlalled, and you want them always to be available
 by default.
 
 This suggests maybe we need to look at beefing up a few things. For
 example, an alias facility that provided a name in schema X for
 things in schema Y would help lots here. (You want everything
 visible? Just alias it in public.) ISTR such things in DB2, although
 it's now many years since I laid hands on it, so my memory could
 well be very faulty.
 
 Also, ability to append to the search path rather than just set it
 could help, as might ability to add names of non-existent schemas
 (which would be ignored at run time when found not to exist).

You can already do this via the following (baroque, but idempotent)
method:

UPDATE
pg_catalog.pg_settings
SET
setting =
CASE WHEN 'foo' = ANY(string_to_array(setting, ','))
THEN setting
ELSE setting || ',foo'
END
WHERE
name = 'search_path'
;

Cheers,
D
-- 
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 415 235 3778AIM: dfetter666
  Skype: davidfetter

Remember to vote!

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] psql possible TODO

2007-01-29 Thread Bruce Momjian

It is actually still in my mailbox to be added to TODO when I get up to it.

---

Alvaro Herrera wrote:
 Joshua D. Drake wrote:
  On Fri, 2006-12-29 at 20:59 -0500, Bruce Momjian wrote:
   Alvaro Herrera wrote:
Tom Lane wrote:
 Richard Troy [EMAIL PROTECTED] writes:
  ... it occurs to me that perhaps Josh can implement
  a command line switch to turn on command line numbering.
 
 That would solve the problem I have with changing \s.  I think a psql
 \set variable (comparable to ON_ERROR_STOP and friends) might be the 
 way
 to go instead of inventing another \-command, but it's not real
 important.

So, is anybody working on this?  I think it should be put in the TODO
list:

 - Allow psql to display item numbers along each history item, depending
   on a \set variable
   
   I thought Joshua Drake was going to submit a patch, but if doesn't
   appear shortly, I will add it to the TODO list with the agreed API.
  
  I will claim this for now. I will let it go if I can't get at least
  something productive done on it by end of January.
 
 Now that the embargo period seems to be over, I think it would be a good
 time to add it to the TODO list.  Also, I'd modify the idea slightly to
 allow a more general facility, using %-escapes (or similar) for line
 numbers, dates and so on.  Bash allows something like this (albeit
 limited to only times) using the HISTTIMEFORMAT environment variable.
 
 This is the first case I know of of an embargo to an agreed TODO item.
 Why was it put in place?  I find it distracting, because the item has to
 be put on someone else's TODO list and then that person has to pinch
 others to get it added to the central TODO list.  Not sure I see the
 point.  (I understand about bashing Joshua ---a sport I also practice in
 Command Prompt's internal lists ;-) --- but in this case it seems to be
 counterproductive).
 
 -- 
 Alvaro Herrerahttp://www.CommandPrompt.com/
 The PostgreSQL Company - Command Prompt, Inc.
 
 ---(end of broadcast)---
 TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] psql possible TODO

2007-01-29 Thread Bruce Momjian
Alvaro Herrera wrote:
  I will claim this for now. I will let it go if I can't get at least
  something productive done on it by end of January.
 
 Now that the embargo period seems to be over, I think it would be a good
 time to add it to the TODO list.  Also, I'd modify the idea slightly to
 allow a more general facility, using %-escapes (or similar) for line
 numbers, dates and so on.  Bash allows something like this (albeit
 limited to only times) using the HISTTIMEFORMAT environment variable.
 
 This is the first case I know of of an embargo to an agreed TODO item.
 Why was it put in place?  I find it distracting, because the item has to
 be put on someone else's TODO list and then that person has to pinch
 others to get it added to the central TODO list.  Not sure I see the
 point.  (I understand about bashing Joshua ---a sport I also practice in
 Command Prompt's internal lists ;-) --- but in this case it seems to be
 counterproductive).

The only reason it isn't on the TODO is because I am still catching up
for the 8.3 queue.  I know of no embargo.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] shared_preload_libraries support on Win32?

2007-01-29 Thread korryd
  You're right - we need the copy in the postmaster (to setup shared
  memory and LW locks), and we need them in the backends too.
 
  Just make sure you don't load the libraries in bgwriter et al ...
 
 I see that Korry's patch doesn't do that, but I'm wondering why exactly.
 In a Unix environment such libraries *would* be propagated into bgwriter
 and every other postmaster child; is there a reason for the setup on
 Windows to be different?  In particular, what about autovacuum, which
 ISTM should be as close to a standard backend as possible?

I thought about that too...  does autovacuum ever need to re-index?  If
so, it seems that it would need access to any index functions (for
function-based indexes) that might reside in a shared_preload_library.


 Either way we do it, authors of plugins used this way will have to test
 both cases (I'm glad I insisted on EXEC_BACKEND mode being testable under
 Unix ...)


And I'm glad that RequestAddinShmemSpace() and RequestAddinLWLocks()
don't complain if called after postmaster start :-)

-- Korry


--
  Korry Douglas[EMAIL PROTECTED]
  EnterpriseDB  http://www.enterprisedb.com


Re: [HACKERS] XML type and XPath

2007-01-29 Thread Nikolay Samokhvalov

BTW,

Moreover, I would like xpath_string() which return

On 1/29/07, Peter Eisentraut [EMAIL PROTECTED] wrote:
[...]


So, while I realize that I've been arguing for a lean core recently, I
want to propose that we add a small set of XPath support functions to
the core.  This would come down to approximately the following set

xpath_boolean(query, xml)
xpath_number(query, xml)
xpath_string(query, xml)
xpath_nodeset(query, xml) -- API and return type still unclear


As for the latest one, I am for xml[] as a result type, especially if
we have xpath* in contrib. This is not XQuery sequences, but at least
it allows user to see all XML fragments (and manage them somehow -- if
he wants, he would concatenate them to one value using corresponding
function).

As for #1-3 -- they are very simple things; I do not like them,
because they return only one scalar value, which is the one
encountered first. I do not think it's very useful functions at all...
Moreover, in case of xpath_string() I think it should work in the
following manner:
 1. Find all nodes that correspond the expression given. In general
case it will be a set of nodes; OK, let's take only the first one, as
we do with other functions...
 2. For this node retrieve all text nodes that are its descendant. It
will be an ordered set of text values.
 3. Concatenate all these values and return as a single string.
I suppose, only such behaviour is in compliance with XML data model --
as an example, consider following XML fragment: 'amost
badvanced/b open source database/a'.

So, for xpath_string() I see two issues -- 1) a lack of usability if
it returns only one (the first) value from possible sequences of
values; 2) bad conformance if it take only one text node which belongs
to the first context node.

BTW, maybe it would be useful to have several functions, with every
behaviour that can be useful.

Also, I think it'd be better not to use the word query speaking of
XPath, XPath expression is much better (to avoid confusion with XML
Query).


We also have prospects that later on we might get fancy GIN-based
indexing support for XPath, which might need another xpath_matches()
function or operator of some kind.


Now I'm trying to collect all thought regarding indexes and express it
in a short message (what types of queries should be considered; what
types of indexes would support that queries).

BTW, Do not forget that some type of index is already available - it's
simply functional indexes on xpath_*() with static (i.e. known as a
constant value a priori) XPath expression.


As far as contrib/xml2 is concerned, I'm not going to make any efforts
to make the interface compatible because that module has a rather
pragmatic design, whereas I'd rather just provide the raw operations
that can be assembled easily by the user to achieve some of the things
that contrib/xml2 does now.  Once some description of transition steps
has been developed, I'd deprecate the contrib/xml2 module and probably
remove it after 8.3.

In the wiki we have collected some random ideas of other interesting
operations on XML types
(http://developer.postgresql.org/index.php/XML_Todo, near the bottom).
That list at the moment says:

DTD validation
Relax-NG
XSLT
XML Canonical (to compare XML values)
Pretty-printing XML (e.g., indenting)


I've added Shredding with annotated schemas to this list (with brief
description why it could be needed).

Also, in a long term I see such items as
 - integration/support in pl/perl and other pl-langs that can work with XML;
 - work with web services (maybe it'd better to use pl/perl here).
Maybe it too early to add such things even to the bottom of Todo list :-)

--
Best regards,
Nikolay

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


Re: [HACKERS] Modifying and solidifying contrib

2007-01-29 Thread Richard Huxton

Joshua D. Drake wrote:

Tom Lane wrote:

Joshua D. Drake [EMAIL PROTECTED] writes:

So what are we thinking here? Along with my suggestion of extensions /
contrib that we modify initdb to load an extensions schema with all
extensions into template1?

No, I don't think so.  If you do that it's effectively moving all that
stuff into core, especially if you haven't provided a way to turn it off.


O.k. any thoughts there? What if we didn't make the extensions schema
PUBLIC? Meaning that explicits rights would have to be given for the
extensions to be used by anyone but a super user?

Obviously the initdb switch could also be selective:


I was thinking last week about what I wanted from a packaging system...

1. Add a new column for all system objects, separate from schema: 
package. So you would have core, tsearch, ltree, etc.
At the very least this lets you manually uninstall a package by 
searching for and dropping by package-name. Most of what is currently 
considered PostgreSQL would be core package I suppose, but you could 
 split out various of the types (numeric, text, internet etc.) I 
suppose). Each project in contrib/ would be a package, as would each 
procedural language.


2. All packages have the following attributes:
 a. Name, description, version number, supplier name/website
 b. Installation script, removal script (as functions - obviously 
they'll need some bootstrapping)/

We might want hooks for various upgrade functions too.
 c. Test function(s) with predictable names (perhaps just test001() 
test002()). These might be dropp-able for a production deployment.
 d. A list of dependencies on other packages/versions. This implies 
some pg_package_is_installed() function perhaps.
 e. A default search_path to override any user search_path settings (so 
your package always calls the desired version of foo()).
 f. Permissions at a package-level, so that a package can be loaded but 
not installed, or installed but not usable by non-superusers.


3. All packages that ship with the standard PG distribution are:
  a. built by default
  b. installed to a suitable extensions/packages directory.
  c. have install/remove functions
  d. have some semi-standard naming (pgx_...)
  e. have test functions
  f. are documented in the main manuals

From my limited knowledge of the code, none of this should require 
major surgery except perhaps permissions at the package level and the 
bootstrapping for installation.


Bootstrapping could consist of nothing more than a set of SQL scripts 
which set up some temporary tables and create and call the _install() 
function.


Any of this in the direction that other people were thinking of?

--
  Richard Huxton
  Archonet Ltd

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Modifying and solidifying contrib

2007-01-29 Thread Tom Lane
Richard Huxton dev@archonet.com writes:
 1. Add a new column for all system objects, separate from schema: 
 package.

Wouldn't it be a whole lot easier just to drive it off schema, rather
than inventing duplicative parallel infrastructure?  That is, say that a
package has one or more schemas and what it owns is whatever is in
those schemas.  This lets you, for example, use schema permissions to
manage access to the package.

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] Modifying and solidifying contrib

2007-01-29 Thread Richard Huxton

Tom Lane wrote:

Richard Huxton dev@archonet.com writes:
1. Add a new column for all system objects, separate from schema: 
package.


Wouldn't it be a whole lot easier just to drive it off schema, rather
than inventing duplicative parallel infrastructure?  That is, say that a
package has one or more schemas and what it owns is whatever is in
those schemas.  This lets you, for example, use schema permissions to
manage access to the package.


Four differences:
1. You couldn't have a tsearch package with functions in public. At 
least not without some IMPORT TSEARCH.foo() INTO public
2. You can't easily disable access to a whole package if it's spread 
over multiple schemas.
3. You can't determine what package various objects belong to - is this 
stopwords table from tsearch2 or ArchonetSearch17?
4. You can't have one package depending upon another (webstats v2.1 
depends on internet_addr v2.3).


With the current search_path functionality I think it's important the 
package names are separate. I think I'm right in saying there are two 
packaging schemes out there - you either have a single hierarchy 
(Perl/Java) or something parallel (at 90 degrees to?) to an existing 
setup (RPM/deb). I think our search_path means we're dealing with 
something more like a Linux packaging setup.


--
  Richard Huxton
  Archonet Ltd

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] Modifying and solidifying contrib

2007-01-29 Thread Tom Lane
Richard Huxton dev@archonet.com writes:
 Tom Lane wrote:
 Wouldn't it be a whole lot easier just to drive it off schema, rather
 than inventing duplicative parallel infrastructure?

 Four differences:
 1. You couldn't have a tsearch package with functions in public. At 
 least not without some IMPORT TSEARCH.foo() INTO public

So?  That's what a search path is for.

 2. You can't easily disable access to a whole package if it's spread 
 over multiple schemas.

The main reason I can see for separating a package into more than one
schema is exactly that some parts would be public and others
private.  So schema-level access controls are what you want, *not*
package-level.

 3. You can't determine what package various objects belong to - is this 
 stopwords table from tsearch2 or ArchonetSearch17?

Sure you can; you look to see what schema it's in.

 4. You can't have one package depending upon another (webstats v2.1 
 depends on internet_addr v2.3).

What's that have to do with it?  Perhaps I should be clearer: I agree
with having an explicit representation of a package in some new system
catalog for that purpose.  That does not translate to needing to add
package hooks to every other catalog.  Indirect links through schemas
seem more than sufficient.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


[HACKERS] How to configure Postgres to make it not to use (load) crypto libraries.

2007-01-29 Thread Tom Dong
Hi,

 

I am looking for a way via configuration to make Postgres
not to use the openssl lib libeay32.dll as I need to delete that
library. I basically need to remove any encryption (hash is fine)
features from my Postgres (8.x) installation.  This is quite urgent for
me.  I would be very grateful if someone in this communicate can reply
to this email and help me.

 

Thanks!

Tom



Re: [HACKERS] PostgreSQL Data Loss

2007-01-29 Thread desrocchi


On 27 Gen, 06:31, [EMAIL PROTECTED] (Martijn van Oosterhout) wrote:

  To repeat: If you think this may have happened DO NOT run vacuum 
  now.Actually, for XID wraparound a VACUUM may actually be the right thing.
 I looked at this (with guidence from Tom) and we came to the conclusion
 that XID wraparound will hide tuples older than 2 billion transaction,
 but VACUUM will mark as frozen anything newer than 3 billion
 transactions, so for 1 billion transactions you can actually get your
 data back.

 Expect for things like uniqueness guarentees, but they're solvable.

Hello,
 thank you all for the help.
@Andrew Dunstan: this is the first time I'm having this kind of 
problem with PostgreSQL, I'm sorry I didn't provide all the needed 
information.
Let me try to fill in something:
- the postgresql version is 8.1.4-1
- as far as I know, nothing happened to the machine. I work near 
Milan, my customer is from something between Rome and Tuscany. It 
would be a long jurney to retrieve a PC that he surely won't give us.
- The server logs... huh? Never heard of them... or better, never 
needed. Where can I find them?

There is even a more foolish explanation to all of this, but my 
customer denied this happened:
in my program it is possible to deactivate the auto-save function of 
the work done. Without this option the user has to click himself the 
button to store the data on the database... so it could even be that 
I'm trying to find data that has never even been saved.

Anyway this teaches me that I have to put logs in my programs to trace 
every single time the users change settings.

Bye,
Daniele


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Getting comments from schema using SQL

2007-01-29 Thread google
check out the pg_description system catalog:

http://www.postgresql.org/docs/8.2/static/catalog-pg-description.html

-
http://www.elsasoft.org

On Jan 29, 2:40 pm, Timasmith [EMAIL PROTECTED] wrote:
 Hi,

 What query can I run to get the comments on my table columns using
 SQL?

 thanks

 Tim


---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] How to configure Postgres to make it not to use (load) crypto libraries.

2007-01-29 Thread Jim Buttafuoco
Rebuild from source and DO NOT specify --with-openssl

 

 

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Dong
Sent: Saturday, January 27, 2007 12:16 PM
To: pgsql-hackers@postgresql.org
Cc: Tom Dong
Subject: [HACKERS] How to configure Postgres to make it not to use (load)
crypto libraries.

 

Hi,

 

I am looking for a way via configuration to make Postgres not to
use the openssl lib libeay32.dll as I need to delete that library. I
basically need to remove any encryption (hash is fine) features from my
Postgres (8.x) installation.  This is quite urgent for me.  I would be very
grateful if someone in this communicate can reply to this email and help me.

 

Thanks!

Tom



Re: [HACKERS] Getting comments from schema using SQL

2007-01-29 Thread Tom Lane
[EMAIL PROTECTED] writes:
 On Jan 29, 2:40 pm, Timasmith [EMAIL PROTECTED] wrote:
 What query can I run to get the comments on my table columns using
 SQL?

 check out the pg_description system catalog:
 http://www.postgresql.org/docs/8.2/static/catalog-pg-description.html

Also see obj_description() and friends, which are basically wrappers
for queries on that catalog:
http://www.postgresql.org/docs/8.2/static/functions-info.html#FUNCTIONS-INFO-COMMENT-TABLE

regards, tom lane

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [HACKERS] Modifying and solidifying contrib

2007-01-29 Thread Andrew Dunstan

Tom Lane wrote:

I agree
with having an explicit representation of a package in some new system
catalog for that purpose.  That does not translate to needing to add
package hooks to every other catalog.  Indirect links through schemas
seem more than sufficient.




This seems like a good first step in growing a packaging infrastructure. 
I'd rather grow it organically than try to design it all up front.


cheers

andrew

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] [BUGS] Missing error message on missing ssl-key-files

2007-01-29 Thread Tom Lane
Magnus Hagander [EMAIL PROTECTED] writes:
 I'm thinking we need a check in elog.c on the:
   if ((!Redirect_stderr || am_syslogger)  pgwin32_is_service())
   write_eventlog(edata-elevel, buf.data);
 line, that checks if the syslogger process has been started yet.

[ shrug... ]  None of those other variables are guaranteed correct at
process start, either...

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] shared_preload_libraries support on Win32?

2007-01-29 Thread Tom Lane
[EMAIL PROTECTED] writes:
 I see that Korry's patch doesn't do that, but I'm wondering why exactly.
 In a Unix environment such libraries *would* be propagated into bgwriter
 and every other postmaster child; is there a reason for the setup on
 Windows to be different?  In particular, what about autovacuum, which
 ISTM should be as close to a standard backend as possible?

 I thought about that too...  does autovacuum ever need to re-index?  If
 so, it seems that it would need access to any index functions (for
 function-based indexes) that might reside in a shared_preload_library.

Any ordinary C-language function is not an issue, because its library
will get autoloaded upon use.  AFAICS what we have to think about here
is instrumentation or debugging plugins that someone might wish to have
running in the postmaster's special children.  Maybe there's no such
animal; I'm not sure.  But in the Unix environment they'd be active in
those processes.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] Modifying and solidifying contrib

2007-01-29 Thread Joshua D. Drake


This seems like a good first step in growing a packaging 
infrastructure. I'd rather grow it organically than try to design it 
all up front.




I am in Denver and have spotty inet access so forgive me. So where does 
this above leave us? What are we doing?


Joshua D. Drake


cheers

andrew




---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] Proposal: Snapshot cloning

2007-01-29 Thread Jim Nasby

On Jan 26, 2007, at 4:48 PM, Tom Lane wrote:

Simon Riggs [EMAIL PROTECTED] writes:

You got me. My description was too loose, but you also got the rough
picture. We'll save the detail for another day, but we all know its a
bridge we will have to cross one day, soon. I wasn't meaning to raise
this specific discussion now, just to say that publishing  
snapshots for

known LRTs is one way by which we can solve the LRT/VACUUMing issue.


I don't actually see that it buys you a darn thing ... you still won't
be able to delete dead updated tuples because of the possibility of  
the

LRT deciding to chase ctid chains up from the tuples it can see.   You
also seem to be assuming that a transaction can have only one  
snapshot,
which is not something we can enforce in enough cases to make it a  
very

useful restriction.


Well, Simon was talking about a serialized LRT, which ISTM shouldn't  
be hunting down ctid chains past the point it serialized at.


Even if that's not the case, there is also the possibility if a LRT  
publishing information about what tables it will hit. Any tables not  
being touched by a LRT could be vacuumed past the global minxid. It  
would be up to the user to do that in many cases, but that's likely  
to be well worth it if you have LRTs that are only hitting a few  
tables yet you have other tables that really, really need to stay  
vacuumed. Believe me, that is a very common use case in the real  
world (think queue table, or web session table).

--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)



---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org


Re: [HACKERS] No ~ operator for box, point

2007-01-29 Thread Jim Nasby

* Add missing operators for geometric data types and operators

There are geometric data types that do not have the full suite  
of geometric operators

defined; for example, box @ point does not exist.

On Jan 26, 2007, at 9:32 PM, Bruce Momjian wrote:



Can I get a TODO on this?

-- 
-


Jim Nasby wrote:

On Jan 25, 2007, at 6:26 PM, Tom Lane wrote:

Martijn van Oosterhout kleptog@svana.org writes:

On Thu, Jan 25, 2007 at 01:59:33PM -0500, Merlin Moncure wrote:

On 1/25/07, Jim C. Nasby [EMAIL PROTECTED] wrote:

decibel=# select box '((0,0),(2,2))' ~ point '(1,1)';
ERROR:  operator does not exist: box ~ point


I don't see a reason, although you can do it with polygon and not
box.


Seems like an old oversight.


Ok. If I ever get some time I'll submit a patch to bring everything
in-line (there's other missing operators as well).


Also, I can't find the ~ operator defined for polygon in the
documentation, am I missing something?


~ is deprecated, contains is preferentially spelled @ now.


Ok, I'll keep that in mind.
--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)



---(end of  
broadcast)---

TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


--
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +



--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] Modifying and solidifying contrib

2007-01-29 Thread Bruce Momjian
Joshua D. Drake wrote:
 
  This seems like a good first step in growing a packaging 
  infrastructure. I'd rather grow it organically than try to design it 
  all up front.
 
 
 I am in Denver and have spotty inet access so forgive me. So where does 
 this above leave us? What are we doing?

I was kind of unclear on that too.  It seems we are trying to address
several issues:  visibility of contrib, installation of contrib, etc.
We discussed whether we put the functions in public, a schema for all
contrib, or a schema for each contrib module, and then there was the
discussion of how to configure someone using ten /contrib modules, or at
least wanting them all to be accessible.  

And then there was the idea of allowing schema permissions to control
access, so perhaps we could install more of /contrib by default, and
allow the administrator to just enable/disable them via permissions. 
Personally, I think that might be the best approach because it allows us
to eliminate the install process, but doesn't make the database less
secure --- the administrator enables/disables them at runtime, or at
least could.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] BUG #2917: spi_prepare doesn't accept typename aliases

2007-01-29 Thread Jim Nasby

What about plpgsql variables, ie:

DECLARE
v varchar(42);
BEGIN
...

On Jan 26, 2007, at 9:48 PM, Andrew Dunstan wrote:


Bruce Momjian wrote:

OK, what is the TODO wording?cheers




Something like:

Enforce typmod for function inputs, function results and parameters  
for spi_prepare'd statements called from PLs.



cheers

andrew



--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-01-29 Thread Jim Nasby

On Jan 26, 2007, at 5:09 PM, Tom Lane wrote:

Jan Wieck [EMAIL PROTECTED] writes:

On 1/26/2007 4:40 PM, Jim Nasby wrote:

It would be nice if we had a separate role for replication services
so that we weren't exposing superuser so much.



So you think about another flag in pg_shadow? Would work for me.


Not really sure if that's necessary or not... there might be better  
ways to do it.



How exactly would such a role differ from a regular superuser?  It
would still need an awful lot of privilege bypassing ability.  I'm
pretty dubious that you could lock it down enough to make it worth the
trouble of supporting an additional concept.


There's two cases...

First is the role that actually sets up replication. It's going to  
need a decent amount of privileges... on the origin, it will need to  
add triggers to tables. Possibly create a schema as well (though, I'd  
argue that that should happen when you install replication, which is  
different than just adding a new table to a replication set, or  
adding a new node).


On the replica, it's going to need to be able to alter tables to  
disable triggers. If we want to be fancy and replicate DDL, it'd need  
to be able to do that as well.


But it's important to note that we could require the user to grant  
those abilities specifically to the replication admin role. Maybe not  
what we actually want, but it's something to consider.


The second case is the role that's actually replicating data. It will  
need to INSERT/UPDATE/DELETE on replica tables. Presumably it will  
need some rights on objects that actually implement the replication  
(think objects in the _cluster_name schema in slony), but when the  
node is added the replication admin role should be able to handle that.


Both of those are much more limited than a superuser is... they can't  
create databases, they can't run admin functions such as  
pg_cancel_backend, etc, etc.

--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)



---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


Re: [HACKERS] Proposal: Snapshot cloning

2007-01-29 Thread Tom Lane
Jim Nasby [EMAIL PROTECTED] writes:
 On Jan 26, 2007, at 4:48 PM, Tom Lane wrote:
 I don't actually see that it buys you a darn thing ... you still won't
 be able to delete dead updated tuples because of the possibility of  
 the LRT deciding to chase ctid chains up from the tuples it can see.

 Well, Simon was talking about a serialized LRT, which ISTM shouldn't  
 be hunting down ctid chains past the point it serialized at.

How you figure that?  If the LRT wants to update a tuple, it's got to
chase the ctid chain to see whether the head update committed or not.
It's not an error for a serializable transaction to update a tuple that
was tentatively updated by a transaction that rolled back.

 Even if that's not the case, there is also the possibility if a LRT  
 publishing information about what tables it will hit.

I think we already bought 99% of the possible win there by fixing
vacuum.  Most ordinary transactions aren't going to be able to predict
which other tables the user might try to touch.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


[HACKERS] V3 protocol; way to return table aliases?

2007-01-29 Thread Ken Johanson

Hi all,

I think I've heard the answer to this in another list, but I just want
to get the widest audience and set of opinions, to be sure..

Apparently right now the V3 protocol doesn't return table-aliases for
columns, like:

select employee.firstName, boss.firstName from contacts as employee,
contacts as boss where employee.bossId=boss.pk AND boss.role = .. AND
employee.role = ...

where on the client we could build a metadata descriptor for each
column, and the table alias for column 1 would return 'employee' and 2
would be 'boss'. (perhaps it should be a separate discussion as to which
the real table name or alias should be returned, if not both - as this
depends on the API/spec)

My question is, is it in *any way* possible to add extra data to V3
without breaking existing clients... so that we can stuff the column
alias into the response.. Or does this really, really need V4?

Since I've been told V3 is prob. not doable, this question certainly
seems to match the 'Hackers' challenge/namesake :)

Thanks in advance,
ken





---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings