Re: [HACKERS] Visual Studio 2005, C-language function - avoiding hacks?
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
Re: [HACKERS] Repetition of warning message while REVOKE
Stephen Frost 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] Repetition of warning message while REVOKE
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
[HACKERS] Visual Studio 2005, C-language function - avoiding hacks?
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] Streaming replication and pg_xlogfile_name()
On Wed, March 3, 2010 15:03, Fujii Masao wrote: > On Tue, Mar 2, 2010 at 10:52 PM, Fujii Masao 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
Re: [HACKERS] Explicit psqlrc
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] machine-readable pg_controldata?
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 : >>> 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] machine-readable pg_controldata?
On Thu, Mar 04, 2010 at 10:54:15PM +0100, Magnus Hagander wrote: > 2010/3/4 Josh Berkus : > > 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
[HACKERS] Explicit psqlrc
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/3/4 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. 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] machine-readable pg_controldata?
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] Streaming replication and privilege
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
Re: [HACKERS] HS/SR and smart shutdown
On Thu, Mar 4, 2010 at 12:39 PM, Greg Stark wrote: > On Thu, Mar 4, 2010 at 3:56 PM, Robert Haas wrote: >> On Thu, Mar 4, 2010 at 10:17 AM, Fujii Masao 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] HS/SR and smart shutdown
On Thu, Mar 4, 2010 at 3:56 PM, Robert Haas wrote: > On Thu, Mar 4, 2010 at 10:17 AM, Fujii Masao 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] Linux start script updates
On Thu, Mar 4, 2010 at 12:00 PM, Kevin Grittner wrote: > Robert Haas 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] Linux start script updates
Robert Haas 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] Repetition of warning message while REVOKE
On Thu, 2010-03-04 at 11:23 -0500, Tom Lane wrote: > I wrote: > > Piyush Newe 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] Repetition of warning message while REVOKE
I wrote: > Piyush Newe 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
[HACKERS] Assertion failure twophase.c (2) (testing HS/SR)
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] HS/SR and smart shutdown
On Thu, Mar 4, 2010 at 10:17 AM, Fujii Masao wrote: > On Thu, Mar 4, 2010 at 11:55 PM, Greg Stark wrote: >> On Thu, Mar 4, 2010 at 12:11 PM, Fujii Masao 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
Re: [HACKERS] Linux start script updates
On Thu, Mar 4, 2010 at 9:46 AM, Kevin Grittner
wrote:
> Bruce Momjian wrote:
>> Tom Lane wrote:
>>> "Kevin Grittner" 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] one-off error in to_char formatting
"Erik Rijkers" 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] Streaming replication and privilege
On Thu, Mar 4, 2010 at 5:47 AM, Fujii Masao 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
[HACKERS] one-off error in to_char formatting
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] Repetition of warning message while REVOKE
Piyush Newe 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
Re: [HACKERS] HS/SR and smart shutdown
On Thu, Mar 4, 2010 at 11:55 PM, Greg Stark wrote: > On Thu, Mar 4, 2010 at 12:11 PM, Fujii Masao 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] HS/SR and smart shutdown
On Thu, Mar 4, 2010 at 12:11 PM, Fujii Masao 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] Linux start script updates
Bruce Momjian wrote:
> Tom Lane wrote:
>> "Kevin Grittner" 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] problem about inet
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] HS/SR and smart shutdown
On Mon, Feb 1, 2010 at 11:49 AM, Fujii Masao wrote: > On Sat, Jan 30, 2010 at 12:54 PM, Fujii Masao 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] Incrementally Updated Backups and restartpoints
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 wrote: > On Wed, Jan 13, 2010 at 9:34 PM, Heikki Linnakangas > 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] USE_LIBXSLT in MSVC builds
Dave Page wrote:
On Wed, Mar 3, 2010 at 12:18 PM, Andrew Dunstan 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
[HACKERS] Streaming replication and privilege
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
[HACKERS] problem about inet
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.
Re: [HACKERS] USE_LIBXSLT in MSVC builds
On Wed, Mar 3, 2010 at 12:18 PM, Andrew Dunstan 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] Repetition of warning message while REVOKE
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.
