On Sun, 07 Sep 2008 10:39:25 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> > I assume that you are talking about conflicts. In fact, that's one of
> > the main reasons for wanting a quiet update so that I can catch those
> > right away when I am working on some files. I do an automatic update
> > d
On Fri, Sep 5, 2008 at 7:32 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> Would you mind if I asked you to be the official reviewer of this patch
> for the latest CommitFest? It would help greatly, since you understand
> the issue and clearly the code also. Thanks, if possible.
OK. I'll try to re
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
> (I can't help but think that the USAGE privilege is a bit unfortunate.
> If granting SELECT rights allowed currval(), INSERT allowed nextval(),
> and UPDATE allowed nextval() and setval(), then has_table_privilege()
> would have been sufficient and th
At 2008-09-06 19:59:55 -0400, [EMAIL PROTECTED] wrote:
>
> So I'm thinking it would be better to invent a has_sequence_privilege
> family of functions.
Perhaps.
I certainly wouldn't object to that approach. If there had been such a
function, I would have used it; and, since has_table_privilege do
Alvaro Herrera wrote:
> So I just noticed that we have a description of the Pg innards in the
> sourcecode, complete with a flowchart and all, at src/tools/backend.
> I had already seen this graph years ago; what shocked me the most was
> finding out that there's a pointer to it in the Developer's
> Applied with really pretty minor revisions --- this was a nice clean
> patch. Changes I can recall making:
Woo-hoo, my first patch. Thanks for the cleanup.
...Robert
> * You missed one or two documentation references to DELETE privilege.
>
> * You modified the privileges test to create anoth
"Robert Haas" <[EMAIL PROTECTED]> writes:
> Updated patch attached, based on comments from Ryan Bradetich and Tom
> Lane, and sync'd to latest CVS version.
Applied with really pretty minor revisions --- this was a nice clean
patch. Changes I can recall making:
* You missed one or two documentati
>> Maybe we want a new function has_sequence_privilege() instead?
+1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* Gregory Stark ([EMAIL PROTECTED]) wrote:
> The other reason to think NOTICE might be better is that it's something which,
> if it occurs once, will always occur for that database. So a sysadmin will
> become inured to seeing WARNING on his backups. Are there any other warning
> conditions which c
Gregory Stark <[EMAIL PROTECTED]> writes:
> The other reason to think NOTICE might be better is that it's something which,
> if it occurs once, will always occur for that database. So a sysadmin will
> become inured to seeing WARNING on his backups. Are there any other warning
> conditions which co
Tom Lane <[EMAIL PROTECTED]> writes:
> I doubt that very many people will ever see it at all, actually --- how
> common are circular FK relationships? And it does seem appropriate to
> me for pg_dump to be noisy about the possibility of trouble at restore
> time. (Maybe the message should also
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The use case for adding things to the next commitfest while a commitfest is
> currently happening much less convincing. Why would you submit a patch now
> when you still have two months to work on on it and you should be reviewing
> other patches
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > What I'm wondering right now is what's the value of having this stuff
> > in the source code at all.
>
> So it will be in sync with the version of the source it's with?
> If we move it to the wiki it'll be impractical to maintain the
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What I'm wondering right now is what's the value of having this stuff
> in the source code at all.
So it will be in sync with the version of the source it's with?
If we move it to the wiki it'll be impractical to maintain the info
for anything except HE
Whilst going through the pending patch to add TRUNCATE as a separate
permission, I noticed that it neglected to add TRUNCATE to the various
columns in information_schema that display privileges. I wonder whether
we should do so, or whether we should restrict information_schema to
only show SQL-spe
So I just noticed that we have a description of the Pg innards in the
sourcecode, complete with a flowchart and all, at src/tools/backend.
I had already seen this graph years ago; what shocked me the most was
finding out that there's a pointer to it in the Developer's FAQ, in a
question that's abso
Tom Lane wrote:
> So according to
> http://wiki.postgresql.org/index.php?title=CommitFest&action=history
> there's been rather a lot of confusion about where the CommitFest
> redirect page should point when.
>
> I think the problem is that we need two redirect pages: one for "the
> place where you
Martin Pihlak <[EMAIL PROTECTED]> writes:
> I had also previously experimented with stat() based polling but ran into
> the same issues - no portable high resolution timestamp on files. I guess
> stat() is unusable unless we can live with 1 second update interval for the
> stats (eg. backend reads
Magnus Hagander wrote:
> I wrote a patch for this some time back, that was actually applied.
> Turns out it didn't work, and I ran out of time to fix it, so it was
> backed out again. And then I forgot about it :-) If you look through the
> cvs history of pgstat you should be able to find it - mayb
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas wrote:
>> How about printing that notice at the top of the dump file as well?
> I assume that this trick will only work at restore time only for custom
> or tar dumps. A text-only dump would produce the warning to stderr at
> dump ti
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> pg_dump: WARNING: circular foreign-key constraints among these table(s):
>> pg_dump: master
>> pg_dump: child
>> pg_dump: You may not be able to restore the dump without using
>> --disable-triggers or temporarily dropping the
David Fetter <[EMAIL PROTECTED]> writes:
> On Sun, Sep 07, 2008 at 02:06:40PM -0400, Tom Lane wrote:
>> Okay, I got tired of seeing people complain about foreign-key
>> constraint violations in data-only dumps.
> Isn't this something solved in the more general case by having
> pre-data, data, and
Heikki Linnakangas wrote:
> Tom Lane wrote:
>> pg_dump: WARNING: circular foreign-key constraints among these table(s):
>> pg_dump: master
>> pg_dump: child
>> pg_dump: You may not be able to restore the dump without using
>> --disable-triggers or temporarily dropping the constraints.
>
> WAR
On Sun, Sep 07, 2008 at 02:06:40PM -0400, Tom Lane wrote:
> Okay, I got tired of seeing people complain about foreign-key
> constraint violations in data-only dumps.
Isn't this something solved in the more general case by having
pre-data, data, and post-data dump options?
Cheers,
David.
--
David
M2Y wrote:
Hello,
Could you plz answer the following questions of a newbie:
What is a good way to start understanding backend(postgres) code? Is
there any documentation available especially for developers?
Most of the developer info is within comments in the code itself.
Another place to sta
Tom Lane wrote:
Okay, I got tired of seeing people complain about foreign-key constraint
violations in data-only dumps. While it's true that the problem can't
be solved in the general case (because of potentially circular
references), we could certainly make pg_dump at least *try* to order the
t
Okay, I got tired of seeing people complain about foreign-key constraint
violations in data-only dumps. While it's true that the problem can't
be solved in the general case (because of potentially circular
references), we could certainly make pg_dump at least *try* to order the
tables according to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 7 sept. 08 à 00:45, Tom Lane a écrit :
I dislike the alternative of communicating through shared memory,
though. Right now the stats collector isn't even connected to shared
memory.
Maybe Markus Wanner work for Postgres-R internal messagin
D'Arcy J.M. Cain wrote:
> On Sun, 07 Sep 2008 03:39:39 -0400
> Tom Lane <[EMAIL PROTECTED]> wrote:
> > "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > > ...etc. Would it be OK if I went in and added .cvsignore files to keep
> > > the noise level down?
> >
> > Uh, no, at least not before you've
Gregory Stark wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Relation forks didn't change anything inside relation files, so no scanning of
relations is required because of that. Neither will the FSM rewrite. Not sure
about DSM yet.
And just to confirm -- they don't change the name of t
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I didn't see anything that looked like an immediate change in user table
>> contents, unless they used the "name" type; but what of relation forks?
>
> Relation forks didn't change anything inside relation files, so no scanning of
Joshua D. Drake wrote:
Andrew Dunstan wrote:
Hasn't integer-datetimes been the default for a while? Of course, a
catversion bump will force a dump/reload regardless of that.
Unfortunately not. It is the default on some versions of linux such as
Debian/Ubuntu.
The point I was making
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <[EMAIL PROTECTED]> writes:
> On Sun, 2008-09-07 at 11:01 -0400, Andrew Dunstan wrote:
>> Hasn't integer-datetimes been the default for a while?
> No. I added it as a macro to 8.3, but did not enable it by default,
> because I am trying to be binary compatible w
Andrew Dunstan wrote:
Hasn't integer-datetimes been the default for a while? Of course, a
catversion bump will force a dump/reload regardless of that.
Unfortunately not. It is the default on some versions of linux such as
Debian/Ubuntu.
Sincerely,
Joshua D. Drake
--
Sent via pgsql-hac
Tom Lane wrote:
I didn't see anything that looked like an immediate change in user table
contents, unless they used the "name" type; but what of relation forks?
Relation forks didn't change anything inside relation files, so no
scanning of relations is required because of that. Neither will th
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> In fact, I don't think there's any low-level data format changes yet
> between 8.3 and 8.4, so this would be a comparatively easy release to
> implement upgrade-in-place. There's just the catalog changes, but AFAICS
> nothing that would require sc
Hi,
Dmitry Koterov wrote:
I'll correct everything and send a patch in a couple of days.
Cool, thank you.
Are you
completely sure that this patch will be included?
Uh.. I'm not a committer, but I'm pretty sure your patch has good chances.
I can help with SGML documentation, if you want.
B
Hello,
Could you plz answer the following questions of a newbie:
What is a good way to start understanding backend(postgres) code? Is
there any documentation available especially for developers?
What is commit log and why it is needed?
Why does a replication solution need log shipping and why c
Hello,
On Sun, 2008-09-07 at 11:01 -0400, Andrew Dunstan wrote:
> Hasn't integer-datetimes been the default for a while?
No. I added it as a macro to 8.3, but did not enable it by default,
because I am trying to be binary compatible with Red Hat / Fedora RPMs.
I believe Tom will also add it to
Devrim GÜNDÜZ wrote:
Hi,
I just released new RPM sets, which is based on today's CVS snapshot
(Sep 7, 12:00AM PDT).
These packages *do* require a dump/reload, even from previous 8.4
packages, since I now enabled --enable-integer-datetimes in PGDG RPMs by
default (and IIRC there is a catversio
I was just searching though the TODO list to try and find a quick one that
could be ticked off.
Under functions there is "Allow substring/replace() to get/set bit values".
Does anyone have any more information about this?
On Sun, 2008-09-07 at 08:44 -0400, D'Arcy J.M. Cain wrote:
> > Uh, no, at least not before you've explained why you get those
> messages
> > and others don't.
>
> I didn't know that I am the only one. Am I?
You are not. I got more or less the same this morning while preparing my
new packages.
B
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> (Personally, I never do "cvs update" without "make distclean" first;
>> there are too many other ways to get screwed by updating a live build
>> tree.)
> I assume that you are talking about conflicts. In fact,
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > As far as the page not fitting after conversion, what about some user
> > command that will convert an entire table to the new format if page
> > expansion fails.
>
> VACUUM?
>
> Having to run a manual command defeats the purpose somewhat, thou
Bruce Momjian wrote:
As far as the page not fitting after conversion, what about some user
command that will convert an entire table to the new format if page
expansion fails.
VACUUM?
Having to run a manual command defeats the purpose somewhat, though.
Especially if you have no way of knowing
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> As for signalling, maybe we could implement something like we do for the
>> postmaster signal stuff: the requestor stores a dbid in shared memory
>> and sends a SIGUSR2 to pgstat or some such.
>
> No, no, no. Martin already had a per
Martin Pihlak wrote:
>>> Attached is a WIP patch, which basically implements this:
>> This patch breaks deadlock checking and statement_timeout, because
>> backends already use SIGALRM. You can't just take over that signal.
>> It's possible that you could get things to work by treating this as an
On Sun, 07 Sep 2008 03:39:39 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > ...etc. Would it be OK if I went in and added .cvsignore files to keep
> > the noise level down?
>
> Uh, no, at least not before you've explained why you get those messages
OK, thank you for your review.
I'll correct everything and send a patch in a couple of days. Are you
completely sure that this patch will be included? If not, seems the work of
the patch standartization has much lower priority, and I will not hurry so
much.
But, what about intarray patch? Does so
On Sat, 2008-09-06 at 22:09 -0400, Bruce Momjian wrote:
> > I'm unclear on what you want hooks for. If additional processes get
> > integrated into Postgres, those certainly need to get integrated very
> > much like we integrated other auxiliary processes. I wouldn't call that
> > 'hooking', b
Hi,
I just released new RPM sets, which is based on today's CVS snapshot
(Sep 7, 12:00AM PDT).
These packages *do* require a dump/reload, even from previous 8.4
packages, since I now enabled --enable-integer-datetimes in PGDG RPMs by
default (and IIRC there is a catversion update in recent commit
On Fri, 2008-09-05 at 23:21 +0900, Fujii Masao wrote:
> b) Use new background process as WALSender
>
>This idea needs background-process hook which enables users
>to define new background processes. I think the design of this
>hook resembles that of rmgr hook proposed by Simon. I def
On Sat, 2008-09-06 at 22:09 -0400, Bruce Momjian wrote:
> Markus Wanner wrote:
> > > Hook for WALSender
> > > --
> > > This hook is for introducing WALSender. There are the following
> > > three ideas of how to introduce WALSender. A required hook
> > > differs by which idea is ado
On Fri, 2008-09-05 at 15:39 +0300, Marko Kreen wrote:
> There was a attempt to paint the .pgpass based password handling
> insecure because dblink makes the file world-readable. I still
> fail to see how this any way points to flaws of the scheme...
Hot Standby will probably need to conne
On Fri, 2008-09-05 at 19:37 +0300, Heikki Linnakangas wrote:
> So, you'll implement the part of SQL-MED that deals with specifying
> remote connections, e.g something like "CREATE CONNECTION" (no, I
> haven't looked at what the syntax actually is)?
Why have you started top-posting in your repli
Tom Lane Wrote:
> "David Rowley" <[EMAIL PROTECTED]> writes:
> > I've made the discussed changes. Also updated the benchmark results.
> > http://www.unixbeast.com/~fat/8.3_test_v1.3.xls
> Applied with revisions; mostly cosmetic except for one point. I
> realized after studying the code a bit more
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> When I build from CVS I wind up with this in my CVS update email in the
> morning:
> ? GNUmakefile
> ? config.log
> ? config.status
> ? src/Makefile.global
> ? src/backend/postgres
> ? src/backend/bootstrap/bootstrap_tokens.h
> ? src/backend/catalog
57 matches
Mail list logo
