On Saturday 15 April 2006 22:33, Benjamin Arai wrote:
Hi,
Myself and a friend are PhD students at the University of California,
Riverside. We would be interested in such a project if it were available.
We are both experienced developers previously interning at EA Games and
current system
OK! I'll create a shell script to verify it.
If you change your mind latter I apply for developing the patch.
Best Regards,
Bruno
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 13, 2006 1:57 AM
To: Bruce Momjian
Cc: Bruno Almeida do Lago;
Tom,
With the new tablespace scenario in mind, how do you see this check feature
being implemented: as a script or inside the code?
As I said before, I apply for the creation of this patch. We just need to
decide the best way to implement it.
Regards,
Bruno Almeida do Lago
-Original
Hi
Anyone interested in plpython, please check out/review
http://archives.postgresql.org/pgsql-patches/2006-04/msg00087.php
It fixes the most obvious shortcomings of plpython by making it possible
to return both sets and records (and setof records) and to use named
input parameters in addition
OpenMFG has done some work on getting PostgreSQL working with the Drupal CMS
and the Mantis bugtracker (and also integrating those two, btw). We're in
contact with the respective projects about getting our patches worked in, but
if anyone's keeping a tally, just wanted you to be aware.
Bruno Almeida do Lago [EMAIL PROTECTED] writes:
With the new tablespace scenario in mind, how do you see this check feature
being implemented: as a script or inside the code?
I'd put it in the code, and share code somehow with the current check on
$PGDATA/PG_VERSION (maybe factor that into a
On Sun, Apr 16, 2006 at 05:29:04PM -0400, Tom Lane wrote:
No, failing to provide that is the bad idea, because then you're buying
into the notion that libpq will provide a universal API that will
incorporate anything anyone could possibly want to do with the
underlying SSL library. The above
Bruce Momjian pgman ( at ) candle ( dot ) pha ( dot ) pa ( dot ) us writes:
I am thinking we should throw an error on pg_start_backup() and
pg_stop_backup if full_page_writes is off.
No, we'll just change the test in xlog.c so that fullPageWrites is
ignored if XLogArchivingActive.
* Jonah H. Harris ([EMAIL PROTECTED]) wrote:
I know we started a discussion a month or so ago regarding ideas for
SoC projects. However, after reading through the thread, I didn't see
us nail down any actual items.
I got an email already for a good idea, actually, which is to work on
having
Martijn van Oosterhout kleptog@svana.org writes:
On Sun, Apr 16, 2006 at 05:29:04PM -0400, Tom Lane wrote:
No, failing to provide that is the bad idea, because then you're buying
into the notion that libpq will provide a universal API that will
incorporate anything anyone could possibly want
* Martijn van Oosterhout (kleptog@svana.org) wrote:
The intention is not to provide access to everything. If people want to
know more about the certificate, we simply export the certificate to
them and they can do with it what they like, including sending it to
another program. I wasn't
Stephen Frost [EMAIL PROTECTED] writes:
I have to agree with Martijn here too. It's not all that expensive to
provide read/write calls to abstract away the specific library being
used (since psqlODBC, at least, couldn't care less which library is
being used, really)
You're failing to
On Sun, Apr 16, 2006 at 04:44:50PM -0400, Tom Lane wrote:
It seems that we should write an API to allow a backup device to ask for
blocks from the database.
I don't think we have the manpower or interest to develop and maintain
our own backup tool --- or tools, actually, as you'd at least
Bruce Momjian pgman@candle.pha.pa.us writes:
Think harder: we are only safe if the first write to a given page after
it's mis-copied by the archiver is a full page write. The requirement
therefore continues after pg_stop_backup. Unless you want to add
infrastructure to keep track for *every
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Think harder: we are only safe if the first write to a given page after
it's mis-copied by the archiver is a full page write. The requirement
therefore continues after pg_stop_backup. Unless you want to add
infrastructure to
On Mon, Apr 17, 2006 at 11:07:26AM -0400, Stephen Frost wrote:
I didn't really understand Tom's point here either... In order to not
break psqlODBC when libpq is compiled with GnuTLS we'd have to code up
support for returning an SSL* from the GnuTLS library that would work
for all the OpenSSL
Come to think of it, someone not too long ago was proposing an API to
allow a 'PITR slave' to subscribe to a master for WAL segments/changes;
it seems logical to me for that API to also provide the ability to send
relation data as well.
Is that what replication is for?
Joshua D. Drake
--
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
I have to agree with Martijn here too. It's not all that expensive to
provide read/write calls to abstract away the specific library being
used (since psqlODBC, at least, couldn't care less which library is
On Mon, Apr 17, 2006 at 11:25:26AM -0400, Tom Lane wrote:
You're failing to consider async applications. AFAICS, the *minimum*
API would be
read
write
read ready?
write ready?
get socket so I can use it in select()
Actually, you only need two functions:
read
* Martijn van Oosterhout (kleptog@svana.org) wrote:
Seriously, if people want to do really sophisticated things with the
SSL library, they should setup s_tunnel instead. If we wanted to let
I certainly agree with all the rest but I'm just not sure I can agree
with you here. While s_tunnel is
Bruce Momjian pgman@candle.pha.pa.us writes:
This is a much simpler fix than people talking about writing their own
backup programs.
Well, it's still not exactly trivial. The hack that was being proposed
involved having the admin manually do
full_page_writes = ON (ie, edit config file
Hi
I was workin on the parser version 8.1.2 but wheneva simply update the
date the compilation fails not even ne changes. but the same thing when
done in 8.0.3 it works nicely.
Pls help.
---(end of broadcast)---
TIP 9: In versions below 8.0, the
On Mon, Apr 17, 2006 at 12:24:40PM -0400, Stephen Frost wrote:
* Martijn van Oosterhout (kleptog@svana.org) wrote:
Seriously, if people want to do really sophisticated things with the
SSL library, they should setup s_tunnel instead. If we wanted to let
I certainly agree with all the rest
On Mon, Apr 17, 2006 at 08:07:23AM -0700, [EMAIL PROTECTED] wrote:
Hi
I was workin on the parser version 8.1.2 but wheneva simply update the
date the compilation fails not even ne changes. but the same thing when
done in 8.0.3 it works nicely.
What are you talking about? Please provide exact
[EMAIL PROTECTED] wrote:
I was workin on the parser version 8.1.2 but wheneva simply update
the date the compilation fails not even ne changes.
parse error
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
This is a much simpler fix than people talking about writing their own
backup programs.
Well, it's still not exactly trivial. The hack that was being proposed
involved having the admin manually do
full_page_writes = ON
* Martijn van Oosterhout (kleptog@svana.org) wrote:
On Mon, Apr 17, 2006 at 12:24:40PM -0400, Stephen Frost wrote:
I certainly agree with all the rest but I'm just not sure I can agree
with you here. While s_tunnel is nice it's not always an option and I
think it *would* be nice to have
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
If we were to do this, I'd want some more-bulletproof mechanism for
forcing full_page_writes on during the backup. We could probably
keep a backup in progress flag in shared memory, and examine that
along with the GUC variable
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
If we were to do this, I'd want some more-bulletproof mechanism for
forcing full_page_writes on during the backup. We could probably
keep a backup in progress flag in shared memory, and examine that
along with
I finally got around to looking at adding $PostgreSQL$ tags to all files
in the repository. To see what I was looking at, I ran the following on
a clean checkout:
find . -type f ! -path \*/CVS\* ! -exec grep -q '$PostgreSQL: pgsql' {} \;
-print
The results are at
Jim C. Nasby [EMAIL PROTECTED] writes:
I finally got around to looking at adding $PostgreSQL$ tags to all files
in the repository.
Um, surely most of the ones that should have such tags already do.
(contrib might be a glaring weak spot.) We have explicitly decided
*not* to have tags in places
Tom Lane wrote:
You should at least show the page you think is corrupt.
I attempted to send this additional info to the list but I think the
message got dropped on the floor by the mailing list software or by
the spam filter.
I'll put the files on a web server and post links to them here.
--
On Mon, Apr 17, 2006 at 03:00:58PM -0400, Tom Lane wrote:
I've applied a patch for this. On reflection, the CHECKPOINT during
pg_start_backup was actually necessary for torn-page safety even without
full_page_writes off. The reason is that the torn-page risk occurs when
we write a page from
I wrote:
I attempted to send this additional info to the list but I think the
message got dropped on the floor by the mailing list software or by
the spam filter.
I'll put the files on a web server and post links to them here.
You can find them here:
On Sat, Apr 15, 2006 at 03:05:20PM -0400, Jonah H. Harris wrote:
All ideas welcome!
I know it's not directly PostgreSQL related, but I'd love to see the
dbt* code improved. Items on my wish-list:
- make it easy to run the test framework and clients on a seperate
machine from the database
Jim C. Nasby wrote:
On Mon, Apr 17, 2006 at 03:00:58PM -0400, Tom Lane wrote:
I've applied a patch for this. On reflection, the CHECKPOINT during
pg_start_backup was actually necessary for torn-page safety even without
full_page_writes off. The reason is that the torn-page risk occurs
Bruce Momjian wrote:
Jim C. Nasby wrote:
On Mon, Apr 17, 2006 at 03:00:58PM -0400, Tom Lane wrote:
I've applied a patch for this. On reflection, the CHECKPOINT during
pg_start_backup was actually necessary for torn-page safety even without
full_page_writes off. The reason is that the
Hello again :)
It doesn't seem particularly complicated: inside the connection-startup
transaction done by InitPostgres, you could check to make sure the
selected user has the CONNECT privilege on the selected database.
[ looks at code... ] Actually ReverifyMyDatabase is the right place,
Hello all,
Could someone explain the numbering logic in naming the relations? Why
#define DatabaseRelationId 1262.
I guess not being involved from the beginning has its disadvantages. but
it is very exiting and fun trying to learn the internals by gdb and
asking lots of questions :)
Regards,
Gevik Babakhani wrote:
Could someone explain the numbering logic in naming the relations?
There is none. The numbers are presumably assigned in some
lowest-available manner, but over the years it has become pretty
random.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Sun, 2006-04-16 at 16:44 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
It seems that we should write an API to allow a backup device to ask for
blocks from the database.
I don't think we have the manpower or interest to develop and maintain
our own backup tool --- or
Qingqing Zhou [EMAIL PROTECTED] wrote
As I reviewed the win32/sema.c, there is some code that I am not clear,
can
anybody explain please?
There is another problem related to concurrent operations on win32 sema. Say
two processes are doing semop(+1) concurrently. Look at this code:
/* Don't
Hello:
I find that the real timestamp format(got from the file which is produced by
copying binary to ) is different from what i find in timestamp_send func.
i do think that the binary format of a timestamp 2006-04-18 11:20:20 should
be 44 2B B0 6A 00 00 00 00 standing for secs:1143713898,
43 matches
Mail list logo
