[HACKERS] Repetition of warning message while REVOKE

2010-03-04 Thread Piyush Newe
Hi,

Description:
===
Repetition of warning message with revoke.

How to reproduce :
==

 create table tbl(col int);
 create user usr;
 grant select on tbl to usr;
 \c postgres usr;
 REVOKE SELECT on tbl from usr;

Actual output:

WARNING:  no privileges could be revoked for tbl
WARNING:  no privileges could be revoked for tbl
WARNING:  no privileges could be revoked for tbl
WARNING:  no privileges could be revoked for tbl
WARNING:  no privileges could be revoked for tbl
WARNING:  no privileges could be revoked for tbl
WARNING:  no privileges could be revoked for tbl
WARNING:  no privileges could be revoked for tbl
REVOKE

expected output:
===
Shouldn't print repetitive warnings.

-- 
Piyush S Newe
Principal Engineer
EnterpriseDB
office: +91 20 3058 9500
www.enterprisedb.com

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the
individual or entity to whom it is addressed. This message contains
information from EnterpriseDB Corporation that may be privileged,
confidential, or exempt from disclosure under applicable law. If you are not
the intended recipient or authorized to receive this for the intended
recipient, any use, dissemination, distribution, retention, archiving, or
copying of this communication is strictly prohibited. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete this message.


Re: [HACKERS] USE_LIBXSLT in MSVC builds

2010-03-04 Thread Dave Page
On Wed, Mar 3, 2010 at 12:18 PM, Andrew Dunstan and...@dunslane.net wrote:

  I think these
 might need to have c:\pgBuild\{libxslt,iconv}\bin added to the PATH in the
 buildfarm.conf file, right after where c:\pgBuild\libxml2\bin is added.

This is now done. Sorry for the delay.

-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
PG East Conference: http://www.enterprisedb.com/community/nav-pg-east-2010.do

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] problem about inet

2010-03-04 Thread fanng yuan
Hi Guys:
I just do some research on ip address storage and comparing. I found pgsql
already fixed that issue. I want to get some point from your guys about how
this work. Could you give me some data about that . Also I'm interesting in
pgsql . Could you give me some suggestion about how to hack pgsql.
Thank.


[HACKERS] Streaming replication and privilege

2010-03-04 Thread Fujii Masao
Hi,

Currently superuser privilege is required when the standby connects
to the primary. But there is the complaint that we should add new
privilege for replication and use it instead of superuser because
current approach is not good for security (*1). This has been listed
as one of TODO items of SR.

This TODO item really needs to be addressed for 9.0? Frankly I'm not
familiar with that area, so I've not work on it at all yet, but I'm
going to create the patch if many people want it for 9.0. What is
your opinion?

(*1)
http://archives.postgresql.org/pgsql-hackers/2010-01/msg01536.php

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] USE_LIBXSLT in MSVC builds

2010-03-04 Thread Andrew Dunstan



Dave Page wrote:

On Wed, Mar 3, 2010 at 12:18 PM, Andrew Dunstan and...@dunslane.net wrote:
  

 I think these
might need to have c:\pgBuild\{libxslt,iconv}\bin added to the PATH in the
buildfarm.conf file, right after where c:\pgBuild\libxml2\bin is added.



This is now done. Sorry for the delay.

  


... and mastodon is now green, so that was in fact the problem. Yay!

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Incrementally Updated Backups and restartpoints

2010-03-04 Thread Fujii Masao
Hi,

I thought of this issue again since the related question arrived.
http://archives.postgresql.org/pgsql-admin/2010-03/msg00036.php

On Thu, Jan 14, 2010 at 7:13 AM, Fujii Masao masao.fu...@gmail.com wrote:
 On Wed, Jan 13, 2010 at 9:34 PM, Heikki Linnakangas
 heikki.linnakan...@enterprisedb.com wrote:
 No, that's not an issue. We only wait for the backup-end record if we
 haven't seen yet since we started recovery from the base backup.
 Assuming the standby had reached that point already before the new
 backup from the standby started, backupStartLoc is zero in the control file.

 OK. That assumption should be documented?

This comment is meaningless. Sorry for noise.

 And, when we start an archive recovery from the backup from the standby,
 we seem to reach a safe starting point before database has actually become
 consistent. It's because backupStartLoc is zero. Isn't this an issue?

This issue seems to still happen. So should this be fixed for 9.0?
Or only writing a note in document is enough for 9.0? I'm leaning
towards the latter.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] HS/SR and smart shutdown

2010-03-04 Thread Fujii Masao
On Mon, Feb 1, 2010 at 11:49 AM, Fujii Masao masao.fu...@gmail.com wrote:
 On Sat, Jan 30, 2010 at 12:54 PM, Fujii Masao masao.fu...@gmail.com wrote:
 HOWEVER, I do believe this is an issue we could live with for 9.0 if
 it's going to lead to a whole lot of additional debugging of SR.  But if
 it's an easy fix, it'll avoid a lot of complaints on pgsql-general.

 I think that the latter statement is right.

 Though we've not reached consensus on smart shutdown during
 recovery yet, I wrote the patch that changes its behavior:
 shut down the server (including the startup process and the
 walreceiver) as soon as all read-only connections have died.
 The code is also available in the 'replication' branch in
 my git repository.

 And, let's discuss whether something like the attached patch
 is required for v9.0 or not.

There is no post about this for over a month. Can I remove this
from TODO item of SR for 9.0? Thought? Objection?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] problem about inet

2010-03-04 Thread Kevin Grittner
fanng yuan  wrote:
 
 I just do some research on ip address storage and comparing. I
 found pgsql already fixed that issue. I want to get some point from
 your guys about how this work.
 
I'm not sure what you're looking for, exactly.  Does this page help?:
 
http://www.postgresql.org/docs/8.4/interactive/datatype-net-types.html
 
 Also I'm interesting in pgsql . Could you give me some suggestion
 about how to hack pgsql.
 
http://www.postgresql.org/developer/
 
-Kevin



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Linux start script updates

2010-03-04 Thread Kevin Grittner
Bruce Momjian br...@momjian.us wrote:
 Tom Lane wrote:
 Kevin Grittner kevin.gritt...@wicourts.gov writes:
  Exactly.  With Fedora respecting the standard in this regard,
  I'm convinced we should, too.  In reviewing things based on
  Peter's question, I did start to have doubts about *not*
  special-casing status -- it has its own set of values and 5
  is not assigned, so using it seems wrong.  It seems like it
  should be 3 (program is not running).  Agreed?
 
 Probably.  I think that in practice most scripts are not very
 tense about this --- as long as the exit code is 0 or not-0 per
 spec, which not-0 value is reported is not so exciting to most
 people.
 
 So, do the startup scripts as they exist in CVS need any
 adjustment?
 
It would be trivial to make it a tiny bit more correct, but it's
probably not worth it.  Almost all init scripts I've seen don't
bother to make this more correct, and some in the community seem to
prefer brevity in this script over correctness -- we got a complaint
about having a few characters in there to take it this far.  I'm
inclined to say it's good enough.
 
If we want a more compliant Linux script, the community preference
seems to be that we do most of that work in pg_ctl, for which we now
have a TODO or two.
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] HS/SR and smart shutdown

2010-03-04 Thread Greg Stark
On Thu, Mar 4, 2010 at 12:11 PM, Fujii Masao masao.fu...@gmail.com wrote:
 There is no post about this for over a month. Can I remove this
 from TODO item of SR for 9.0? Thought? Objection?


Does smart shutdown still fail to shut down a slave?

-- 
greg

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] HS/SR and smart shutdown

2010-03-04 Thread Fujii Masao
On Thu, Mar 4, 2010 at 11:55 PM, Greg Stark gsst...@mit.edu wrote:
 On Thu, Mar 4, 2010 at 12:11 PM, Fujii Masao masao.fu...@gmail.com wrote:
 There is no post about this for over a month. Can I remove this
 from TODO item of SR for 9.0? Thought? Objection?


 Does smart shutdown still fail to shut down a slave?

Yes. More precisely, smart shutdown during recovery does not complete
until recovery ends.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Repetition of warning message while REVOKE

2010-03-04 Thread Tom Lane
Piyush Newe piyush.n...@enterprisedb.com writes:
 create table tbl(col int);
 create user usr;
 grant select on tbl to usr;
 \c postgres usr;
 REVOKE SELECT on tbl from usr;
 WARNING:  no privileges could be revoked for tbl
 WARNING:  no privileges could be revoked for tbl
 WARNING:  no privileges could be revoked for tbl
 WARNING:  no privileges could be revoked for tbl
 WARNING:  no privileges could be revoked for tbl
 WARNING:  no privileges could be revoked for tbl
 WARNING:  no privileges could be revoked for tbl
 WARNING:  no privileges could be revoked for tbl
 REVOKE

You really should mention what version you're testing, but for the
archives: I confirm this on 8.4.x and HEAD.  8.3 seems to behave sanely.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] one-off error in to_char formatting

2010-03-04 Thread Erik Rijkers
ISTM this is a bug, no?

(9.0devel, cvs 2010.03.04 01:30)

replicas=# select length( to_char(1, '0') );
 length

  2
(1 row)

There seems to be an erroneously prefixed space:

replicas=# select '' || to_char(1, repeat('0',8)) || '';
  ?column?
-
  0001
(1 row)


replicas=# select version();
 version
--
 PostgreSQL 9.0devel-standby on x86_64-unknown-linux-gnu, compiled by GCC gcc 
(GCC) 4.4.3, 64-bit
(1 row)




Erik Rijkers


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Streaming replication and privilege

2010-03-04 Thread Robert Haas
On Thu, Mar 4, 2010 at 5:47 AM, Fujii Masao masao.fu...@gmail.com wrote:
 Currently superuser privilege is required when the standby connects
 to the primary. But there is the complaint that we should add new
 privilege for replication and use it instead of superuser because
 current approach is not good for security (*1). This has been listed
 as one of TODO items of SR.

 This TODO item really needs to be addressed for 9.0? Frankly I'm not
 familiar with that area, so I've not work on it at all yet, but I'm
 going to create the patch if many people want it for 9.0. What is
 your opinion?

 (*1)
 http://archives.postgresql.org/pgsql-hackers/2010-01/msg01536.php

In my opinion, it is a 9.1 item.

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] one-off error in to_char formatting

2010-03-04 Thread Tom Lane
Erik Rijkers e...@xs4all.nl writes:
 There seems to be an erroneously prefixed space:

No, that's where the sign goes.  You can suppress it with FM,
if you don't want fixed-width output.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Linux start script updates

2010-03-04 Thread Robert Haas
On Thu, Mar 4, 2010 at 9:46 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
 Bruce Momjian br...@momjian.us wrote:
 Tom Lane wrote:
 Kevin Grittner kevin.gritt...@wicourts.gov writes:
  Exactly.  With Fedora respecting the standard in this regard,
  I'm convinced we should, too.  In reviewing things based on
  Peter's question, I did start to have doubts about *not*
  special-casing status -- it has its own set of values and 5
  is not assigned, so using it seems wrong.  It seems like it
  should be 3 (program is not running).  Agreed?

 Probably.  I think that in practice most scripts are not very
 tense about this --- as long as the exit code is 0 or not-0 per
 spec, which not-0 value is reported is not so exciting to most
 people.

 So, do the startup scripts as they exist in CVS need any
 adjustment?

 It would be trivial to make it a tiny bit more correct, but it's
 probably not worth it.  Almost all init scripts I've seen don't
 bother to make this more correct, and some in the community seem to
 prefer brevity in this script over correctness -- we got a complaint
 about having a few characters in there to take it this far.  I'm
 inclined to say it's good enough.

 If we want a more compliant Linux script, the community preference
 seems to be that we do most of that work in pg_ctl, for which we now
 have a TODO or two.

AFAIR Peter is the only one who has complained about the script being
longer, and I'm really not sure why that's a big deal.

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] HS/SR and smart shutdown

2010-03-04 Thread Robert Haas
On Thu, Mar 4, 2010 at 10:17 AM, Fujii Masao masao.fu...@gmail.com wrote:
 On Thu, Mar 4, 2010 at 11:55 PM, Greg Stark gsst...@mit.edu wrote:
 On Thu, Mar 4, 2010 at 12:11 PM, Fujii Masao masao.fu...@gmail.com wrote:
 There is no post about this for over a month. Can I remove this
 from TODO item of SR for 9.0? Thought? Objection?


 Does smart shutdown still fail to shut down a slave?

 Yes. More precisely, smart shutdown during recovery does not complete
 until recovery ends.

Well, I don't think we should let smart shutdown just never terminate
when standby_mode = on.  That's really a minefield for the unwary.  I
think we either need to make it work, or somehow give the user an
error that says try a different shutdown mode.

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Assertion failure twophase.c (2) (testing HS/SR)

2010-03-04 Thread Erik Rijkers
in a 9.0devel, primary+standby, cvs from 2010.03.04 01:30

With three patches:

  new_smart_shutdown_20100201.patch
  extend_format_of_recovery_info_funcs_v4.20100303.patch
  fix-KnownAssignedXidsRemoveMany-1.patch

  pg_dump -d $db8.4.2 | psql -d $db9.0devel-primary

FailedAssertion, File: twophase.c, Line: 1201.

The standby was restarted and seems to catch up OK again.


LOG:  database system was interrupted; last known up at 2010-03-04 01:35:23 CET
cp: cannot stat 
`/var/data1/pg_stuff/dump/hotslave/replication_archive/00010001':
No such file or directory
FATAL:  the database system is starting up
LOG:  entering standby mode
LOG:  redo starts at 0/120
LOG:  consistent recovery state reached at 0/200
LOG:  database system is ready to accept read only connections
ERROR:  cannot execute CREATE TABLE in a read-only transaction
STATEMENT:  create table t (c text);
ERROR:  cannot execute SELECT INTO in a read-only transaction
STATEMENT:  create table t as select 1;
ERROR:  cannot execute TRUNCATE TABLE in a read-only transaction
STATEMENT:  truncate wal;
ERROR:  cannot execute TRUNCATE TABLE in a read-only transaction
STATEMENT:  truncate wal;
ERROR:  cannot execute TRUNCATE TABLE in a read-only transaction
STATEMENT:  truncate wal;
ERROR:  cannot execute TRUNCATE TABLE in a read-only transaction
STATEMENT:  truncate wal;
ERROR:  cannot execute TRUNCATE TABLE in a read-only transaction
STATEMENT:  truncate wal;
ERROR:  cannot execute TRUNCATE TABLE in a read-only transaction
STATEMENT:  truncate wal;
ERROR:  cannot execute TRUNCATE TABLE in a read-only transaction
STATEMENT:  truncate wal;
FATAL:  database ms does not exist
TRAP: FailedAssertion(!(((xid) != ((TransactionId) 0))), File: twophase.c, 
Line: 1201)
LOG:  startup process (PID 18107) was terminated by signal 6: Aborted
LOG:  terminating any other active server processes
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the 
current transaction and
exit, because another server process exited abnormally and possibly corrupted 
shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat 
your command.
LOG:  database system was interrupted while in recovery at log time 2010-03-04 
05:00:24 CET
HINT:  If this has occurred more than once some data might be corrupted and you 
might need to
choose an earlier recovery target.
cp: cannot stat 
`/var/data1/pg_stuff/dump/hotslave/replication_archive/0001001C007F':
No such file or directory
LOG:  entering standby mode
LOG:  redo starts at 1C/7800F8E0
LOG:  consistent recovery state reached at 1C/ADB9C178
LOG:  database system is ready to accept read only connections

The ERRORs (and FATAL) were accidentally issued commands; I can't tell if they 
were causing the
assertion. (database 'ms' indeed was not present on this instance)

see also:
http://archives.postgresql.org/pgsql-hackers/2010-02/msg02221.php


thanks,

Erik Rijkers



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Repetition of warning message while REVOKE

2010-03-04 Thread Tom Lane
I wrote:
 Piyush Newe piyush.n...@enterprisedb.com writes:
 create table tbl(col int);
 create user usr;
 grant select on tbl to usr;
 \c postgres usr;
 REVOKE SELECT on tbl from usr;
 WARNING:  no privileges could be revoked for tbl
 WARNING:  no privileges could be revoked for tbl
 WARNING:  no privileges could be revoked for tbl
 WARNING:  no privileges could be revoked for tbl
 WARNING:  no privileges could be revoked for tbl
 WARNING:  no privileges could be revoked for tbl
 WARNING:  no privileges could be revoked for tbl
 WARNING:  no privileges could be revoked for tbl
 REVOKE

 You really should mention what version you're testing, but for the
 archives: I confirm this on 8.4.x and HEAD.  8.3 seems to behave sanely.

I traced through this and determined that the extra messages are a
consequence of the column-level-privileges patch.
restrict_and_check_grant is invoked both on the whole relation, and
on each column (since we have to get rid of any per-column SELECT
privilege that might have been granted).

I'm not sure offhand about a reasonable way to rearrange the code to
avoid duplicate messages.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Repetition of warning message while REVOKE

2010-03-04 Thread Joshua D. Drake
On Thu, 2010-03-04 at 11:23 -0500, Tom Lane wrote:
 I wrote:
  Piyush Newe piyush.n...@enterprisedb.com writes:
  create table tbl(col int);
  create user usr;
  grant select on tbl to usr;
  \c postgres usr;
  REVOKE SELECT on tbl from usr;
  WARNING:  no privileges could be revoked for tbl
  WARNING:  no privileges could be revoked for tbl
  WARNING:  no privileges could be revoked for tbl
  WARNING:  no privileges could be revoked for tbl
  WARNING:  no privileges could be revoked for tbl
  WARNING:  no privileges could be revoked for tbl
  WARNING:  no privileges could be revoked for tbl
  WARNING:  no privileges could be revoked for tbl
  REVOKE
 
  You really should mention what version you're testing, but for the
  archives: I confirm this on 8.4.x and HEAD.  8.3 seems to behave sanely.
 
 I traced through this and determined that the extra messages are a
 consequence of the column-level-privileges patch.
 restrict_and_check_grant is invoked both on the whole relation, and
 on each column (since we have to get rid of any per-column SELECT
 privilege that might have been granted).
 
 I'm not sure offhand about a reasonable way to rearrange the code to
 avoid duplicate messages.

Perhaps just add what can't be revoked? meaning:

WARNING:  no privileges could be revoked for tbl for column foo

Then they aren't actually duplicate.

Sincerely,

Joshau D. Drake



 
   regards, tom lane
 


-- 
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
Respect is earned, not gained through arbitrary and repetitive use or Mr. or 
Sir.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Linux start script updates

2010-03-04 Thread Kevin Grittner
Robert Haas robertmh...@gmail.com wrote:
 
 AFAIR Peter is the only one who has complained about the script
 being longer, and I'm really not sure why that's a big deal.
 
I'll take that under advisement for later.  I'm not inclined to
think there's anything here worth trying to squeeze into 9.0, and
I'm assuming that isn't what you were suggesting, either.
 
Personally, though, I don't understand his concern about length per
se, but recognize that some of the improvements could have value
outside of Linux environments; which makes a case for putting what
we can into pg_ctl.  That the script becomes shorter and easier to
read and understand may have some limited value, but I see that as
secondary.
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Linux start script updates

2010-03-04 Thread Robert Haas
On Thu, Mar 4, 2010 at 12:00 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
 Robert Haas robertmh...@gmail.com wrote:

 AFAIR Peter is the only one who has complained about the script
 being longer, and I'm really not sure why that's a big deal.

 I'll take that under advisement for later.  I'm not inclined to
 think there's anything here worth trying to squeeze into 9.0, and
 I'm assuming that isn't what you were suggesting, either.

I'm OK either way.  Changes to init scripts are unlikely to break
anything since many users won't use them.  And if the changes are
minor even moreso.  But postponing it is one less thing to deal with,
so I'm happy with that.

 Personally, though, I don't understand his concern about length per
 se, but recognize that some of the improvements could have value
 outside of Linux environments; which makes a case for putting what
 we can into pg_ctl.  That the script becomes shorter and easier to
 read and understand may have some limited value, but I see that as
 secondary.

That's a good point.

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] HS/SR and smart shutdown

2010-03-04 Thread Greg Stark
On Thu, Mar 4, 2010 at 3:56 PM, Robert Haas robertmh...@gmail.com wrote:
 On Thu, Mar 4, 2010 at 10:17 AM, Fujii Masao masao.fu...@gmail.com wrote:

 Yes. More precisely, smart shutdown during recovery does not complete
 until recovery ends.

 Well, I don't think we should let smart shutdown just never terminate
 when standby_mode = on.  That's really a minefield for the unwary.  I
 think we either need to make it work, or somehow give the user an
 error that says try a different shutdown mode.

It also seems dangerous to let someone think they have a standby
database ready to go and the minute they need it -- it shuts down


-- 
greg

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] HS/SR and smart shutdown

2010-03-04 Thread Robert Haas
On Thu, Mar 4, 2010 at 12:39 PM, Greg Stark gsst...@mit.edu wrote:
 On Thu, Mar 4, 2010 at 3:56 PM, Robert Haas robertmh...@gmail.com wrote:
 On Thu, Mar 4, 2010 at 10:17 AM, Fujii Masao masao.fu...@gmail.com wrote:

 Yes. More precisely, smart shutdown during recovery does not complete
 until recovery ends.

 Well, I don't think we should let smart shutdown just never terminate
 when standby_mode = on.  That's really a minefield for the unwary.  I
 think we either need to make it work, or somehow give the user an
 error that says try a different shutdown mode.

 It also seems dangerous to let someone think they have a standby
 database ready to go and the minute they need it -- it shuts down

LOL.

Yeah, that would not be cool.

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Streaming replication and privilege

2010-03-04 Thread Josh Berkus
On 3/4/10 2:47 AM, Fujii Masao wrote:
 This TODO item really needs to be addressed for 9.0? Frankly I'm not
 familiar with that area, so I've not work on it at all yet, but I'm
 going to create the patch if many people want it for 9.0. What is
 your opinion?

I think it falls under nice to have, but not essential for 9.0.

--Josh Berkus

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] machine-readable pg_controldata?

2010-03-04 Thread Josh Berkus
All,

Currently, the only way for admin scripts to get individual data items
out of pg_controldata (such as the next XID or the catalog version) is
via grep and regex. Given that people are going to be relying on some of
this data for replication admin in the future, it seems past time to
have a form of pg_controldata which either outputs machine-readable text
(XML or JSON), or (my preference) takes options to output just the
invididual items, e.g.

pg_controldata --catalog_version

Even better would be the ability to get everything which is in
pg_controldata currently as part of a system view in a running
PostgreSQL; I can get most of them, but certainly not all.

Thoughts?

--Josh Berkus

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] machine-readable pg_controldata?

2010-03-04 Thread Magnus Hagander
2010/3/4 Josh Berkus j...@agliodbs.com:
 All,

 Currently, the only way for admin scripts to get individual data items
 out of pg_controldata (such as the next XID or the catalog version) is
 via grep and regex. Given that people are going to be relying on some of
 this data for replication admin in the future, it seems past time to
 have a form of pg_controldata which either outputs machine-readable text
 (XML or JSON), or (my preference) takes options to output just the
 invididual items, e.g.

Huh? It's fixed with, you don't need regexps for that. Just split the
string apart.

Taking options for single fields might have a better usecase, of course :-)


 pg_controldata --catalog_version

 Even better would be the ability to get everything which is in
 pg_controldata currently as part of a system view in a running
 PostgreSQL; I can get most of them, but certainly not all.

+1 for having all the information available from inside the backend,
if that's technically possible (which I assume it should be)

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Explicit psqlrc

2010-03-04 Thread Magnus Hagander
I've now for the second time found myself wanting to specify an
explicit psqlrc file instead of just parsing ~/.psqlrc, so attached is
a patch that accepts the PSQLRC environment variable to control which
psqlrc file is used.

Any objections to this (obviously including documentation - this is
just the trivial code)

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


psqlrc.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] machine-readable pg_controldata?

2010-03-04 Thread Joshua Tolley
On Thu, Mar 04, 2010 at 10:54:15PM +0100, Magnus Hagander wrote:
 2010/3/4 Josh Berkus j...@agliodbs.com:
  pg_controldata --catalog_version
 
  Even better would be the ability to get everything which is in
  pg_controldata currently as part of a system view in a running
  PostgreSQL; I can get most of them, but certainly not all.
 
 +1 for having all the information available from inside the backend,
 if that's technically possible (which I assume it should be)

I'd love to see pg_config's various bits of information in there as well. I
just haven't gotten around to writing it. But +1 from me, FWIW.

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com


signature.asc
Description: Digital signature


Re: [HACKERS] machine-readable pg_controldata?

2010-03-04 Thread Joe Conway
On 03/04/2010 02:09 PM, Joshua Tolley wrote:
 On Thu, Mar 04, 2010 at 10:54:15PM +0100, Magnus Hagander wrote:
 2010/3/4 Josh Berkus j...@agliodbs.com:
 pg_controldata --catalog_version

 Even better would be the ability to get everything which is in
 pg_controldata currently as part of a system view in a running
 PostgreSQL; I can get most of them, but certainly not all.

 +1 for having all the information available from inside the backend,
 if that's technically possible (which I assume it should be)
 
 I'd love to see pg_config's various bits of information in there as well. I
 just haven't gotten around to writing it. But +1 from me, FWIW.

I agree something like this would be useful -- maybe I'll try to come up
with some round tuits...

Joe




signature.asc
Description: OpenPGP digital signature


Re: [HACKERS] Explicit psqlrc

2010-03-04 Thread David Christensen


On Mar 4, 2010, at 4:00 PM, Magnus Hagander wrote:


I've now for the second time found myself wanting to specify an
explicit psqlrc file instead of just parsing ~/.psqlrc, so attached is
a patch that accepts the PSQLRC environment variable to control which
psqlrc file is used.

Any objections to this (obviously including documentation - this is
just the trivial code)



My bikeshed has a --psqlrc path/to/file, but +1 on the idea.

Regards,

David
--
David Christensen
End Point Corporation
da...@endpoint.com





--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Streaming replication and pg_xlogfile_name()

2010-03-04 Thread Erik Rijkers
On Wed, March 3, 2010 15:03, Fujii Masao wrote:
 On Tue, Mar 2, 2010 at 10:52 PM, Fujii Masao masao.fu...@gmail.com wrote:

 Here is the revised patch. I used new local variable instead of lastPageTLI
 to track the tli of last applied record. It is updated with the tli of the
 log page header when reading the page, and with the tli of the checkpoint
 record when replaying the checkpoint shutdown record that changes the tli.
 So pg_last_xlog_replay_location() can return the accurate tli of the last
 applied record.

  extend_format_of_recovery_info_funcs_v4.patch

looks good: on the standby, the initial xlog file_name immediately after 
startup is now
00010001, as expected.

I'll do my further testing of HS/SR with this patch included.

thanks,

Erik Rijekrs







-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Visual Studio 2005, C-language function - avoiding hacks?

2010-03-04 Thread Kevin Flanagan
I have PostgreSQL 8.4 installed on Windows XP, and am using Visual Studio
2005 to write a C-Language function. I have the most basic hello-world type
example (just the 'add_one' function from
http://www.postgresql.org/docs/8.4/interactive/xfunc-c.html) in a DLL, set
to compile to C code rather than C++, and I can do CREATE FUNCTION on it
then use it successfully. However, I had to do some questionable hacks to
get it to build, so I'm guessing I've done something the wrong way. I've not
found anything categorical in the archives here, so would very much
appreciate anyone who can tell me if there's a key step I'm missing that
would make the hacks unnecessary. (For instance, I've come across a
requirement in previous versions to replace pg_config.h with
pg_config.h.win32, but that doesn't seem to apply to current versions -
maybe something else does.) I'm concerned the hacks might turn round and
bite me otherwise once I'm implementing something non-trivial.

 

Having added C:\Program Files\PostgreSQL\8.4\include\server to the include
directories to pick up postgres.h and fmgr.h, the compiler complained about
various missing include files, starting with 'libintl.h'. Having read the
post at http://archives.postgresql.org/pgsql-general/2009-03/msg00332.php I
created an empty libint.h in an include dir, along with a bunch of other
empty dummy files that were expected: netdb.h, pwd.h, netinet/in.h and
arpa/inet.h. 

 

The code then compiles ok, but gives 'inconsistent dll linkage' on the line
with PG_FUNCTION_INFO_V1 and the one with PG_MODULE_MAGIC.

 

So I'd like to ask:

* Is there some symbol I should be defining, or something, to avoid all
those dummy header files and make the corresponding Visual Studio headers
get picked up?

* Is there something I should be doing to avoid the 'inconsistent dll
linkage' warnings?

 

(The C-Language functions are going to end up using some in-proc
Windows-only components, so I'm hoping that building them using Visual
Studio will be the least painful way to get at those.)

 

Thanks in advance for any help

 

Kevin.

 

 

 



Re: [HACKERS] Repetition of warning message while REVOKE

2010-03-04 Thread Stephen Frost
All,

* Joshua D. Drake (j...@commandprompt.com) wrote:
 On Thu, 2010-03-04 at 11:23 -0500, Tom Lane wrote:
  I'm not sure offhand about a reasonable way to rearrange the code to
  avoid duplicate messages.
 
 Perhaps just add what can't be revoked? meaning:
 WARNING:  no privileges could be revoked for tbl for column foo
 Then they aren't actually duplicate.

Yeah, they really aren't, after all.  I don't know how we could
rearrange the code to prevent it- we're checking and trying to change
privileges on each of the columns in the table, after all.

Attached is a patch to add column name to the error message when it's a
column-level failure.  I'm not really thrilled with it, due to the
expansion of code and addition of a bunch of conditionals, but at least
this isn't a terribly complicated function..

In the process of trying to build/run regression tests, but having
some build issues w/ HEAD (probably my fault).

Thanks,

Stephen
Index: src/backend/catalog/aclchk.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/catalog/aclchk.c,v
retrieving revision 1.163
diff -c -r1.163 aclchk.c
*** src/backend/catalog/aclchk.c	26 Feb 2010 02:00:35 -	1.163
--- src/backend/catalog/aclchk.c	5 Mar 2010 01:18:42 -
***
*** 304,327 
  	if (is_grant)
  	{
  		if (this_privileges == 0)
! 			ereport(WARNING,
! 	(errcode(ERRCODE_WARNING_PRIVILEGE_NOT_GRANTED),
!   errmsg(no privileges were granted for \%s\, objname)));
! 		else if (!all_privs  this_privileges != privileges)
! 			ereport(WARNING,
! 	(errcode(ERRCODE_WARNING_PRIVILEGE_NOT_GRANTED),
! 			 errmsg(not all privileges were granted for \%s\, objname)));
  	}
  	else
  	{
  		if (this_privileges == 0)
! 			ereport(WARNING,
! 	(errcode(ERRCODE_WARNING_PRIVILEGE_NOT_REVOKED),
! 			  errmsg(no privileges could be revoked for \%s\, objname)));
! 		else if (!all_privs  this_privileges != privileges)
! 			ereport(WARNING,
! 	(errcode(ERRCODE_WARNING_PRIVILEGE_NOT_REVOKED),
! 	 errmsg(not all privileges could be revoked for \%s\, objname)));
  	}
  
  	return this_privileges;
--- 304,365 
  	if (is_grant)
  	{
  		if (this_privileges == 0)
! 	   	{
! 			if (objkind == ACL_KIND_COLUMN  colname)
! ereport(WARNING,
! 		(errcode(ERRCODE_WARNING_PRIVILEGE_NOT_GRANTED),
! 	  errmsg(no privileges were granted for \%s\, for column \%s\,
! 		  objname, colname)));
! 			else
! ereport(WARNING,
! 		(errcode(ERRCODE_WARNING_PRIVILEGE_NOT_GRANTED),
! 	  errmsg(no privileges were granted for \%s\, objname)));
! 		}
! 		else
! 		{	
! 			if (!all_privs  this_privileges != privileges)
! 			{
! if (objkind == ACL_KIND_COLUMN  colname)
! 	ereport(WARNING,
! 			(errcode(ERRCODE_WARNING_PRIVILEGE_NOT_GRANTED),
! 	 errmsg(not all privileges were granted for \%s\, for column \%s\,
! 		 objname, colname)));
! else
! 	ereport(WARNING,
! 			(errcode(ERRCODE_WARNING_PRIVILEGE_NOT_GRANTED),
! 	 errmsg(not all privileges were granted for \%s\, objname)));
! 			}
! 		}
  	}
  	else
  	{
  		if (this_privileges == 0)
! 		{
! 			if (objkind == ACL_KIND_COLUMN  colname)
! ereport(WARNING,
! 		(errcode(ERRCODE_WARNING_PRIVILEGE_NOT_REVOKED),
!   errmsg(no privileges could be revoked for \%s\, for column \%s\,
! 	  objname, colname)));
! 			else
! ereport(WARNING,
! 		(errcode(ERRCODE_WARNING_PRIVILEGE_NOT_REVOKED),
!   errmsg(no privileges could be revoked for \%s\, objname)));
! 		}
! 		else
! 		{
! 			if (!all_privs  this_privileges != privileges)
! 			{
! if (objkind == ACL_KIND_COLUMN  colname)
! 	ereport(WARNING,
! 		(errcode(ERRCODE_WARNING_PRIVILEGE_NOT_REVOKED),
! 		 errmsg(not all privileges could be revoked for \%s\, for column \%s\,
! 			 objname, colname)));
! else
! 	ereport(WARNING,
! 		(errcode(ERRCODE_WARNING_PRIVILEGE_NOT_REVOKED),
! 		 errmsg(not all privileges could be revoked for \%s\, objname)));
! 			}
! 		}
  	}
  
  	return this_privileges;


signature.asc
Description: Digital signature


Re: [HACKERS] Repetition of warning message while REVOKE

2010-03-04 Thread Tom Lane
Stephen Frost sfr...@snowman.net writes:
 * Joshua D. Drake (j...@commandprompt.com) wrote:
 Perhaps just add what can't be revoked? meaning:
 WARNING:  no privileges could be revoked for tbl for column foo
 Then they aren't actually duplicate.

 Yeah, they really aren't, after all.

Yeah, I agree JD's solution is probably the simplest reasonable answer.

 Attached is a patch to add column name to the error message when it's a
 column-level failure.  I'm not really thrilled with it, due to the
 expansion of code and addition of a bunch of conditionals, but at least
 this isn't a terribly complicated function..

It's a bit brute-force, but so was the original coding.  Anybody see
a way to make it cleaner/shorter?

One thought is that the column cases should be phrased more like
no privileges could be revoked for column foo of table bar
Check the messages associated with DROP cascading for the canonical
phrasing here, but I think that's what it is.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Visual Studio 2005, C-language function - avoiding hacks?

2010-03-04 Thread Craig Ringer
Kevin Flanagan wrote:

 the compiler
 complained about various missing include files, starting with
 ‘libintl.h’. Having read the post at
 http://archives.postgresql.org/pgsql-general/2009-03/msg00332.php I
 created an empty libint.h in an include dir

NFI why Pg for win32 doesn't bundle a copy of the libintl it was built
against. I should poke the EDB guys about it, actually.

 along with a bunch of other
 empty dummy files that were expected: netdb.h, pwd.h, netinet/in.h and
 arpa/inet.h.

Those I wouldn't expect to be included if you're building for win32.

Are you sure you're building with the win32 configuration?

 The code then compiles ok, but gives ‘inconsistent dll linkage’ on the
 line with PG_FUNCTION_INFO_V1 and the one with PG_MODULE_MAGIC.

This would suggest that the macros that insert appropriate
__declspec(dllimport) and __declspec(dllexport) attributes aren't being
triggered - so again, it makes me wonder if Pg knows it's building for
win32.

--
Craig Ringer

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers