[HACKERS] message clarifications
The following messages from the postgres catalog either appear to be internal errors that should be marked differently, or they are in my estimation unintelligible to users and should be rephrased. #: commands/async.c:1424 msgid pg_notify queue is %.0f%% full #: storage/ipc/procarray.c:2224 msgid record known xact %u latestObservedXid %u #: storage/ipc/procarray.c:2257 msgid recording unobserved xid %u (latestObservedXid %u) #: storage/ipc/procarray.c:2379 msgid too many KnownAssignedXids #: storage/ipc/standby.c:861 msgid snapshot of %u running transactions overflowed (lsn %X/%X oldest xid %u next xid %u) #: storage/ipc/standby.c:868 msgid snapshot of %u running transaction ids (lsn %X/%X oldest xid %u next xid %u) Help please. -- 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] message clarifications
On Sat, 2010-04-03 at 11:00 +0300, Peter Eisentraut wrote: The following messages from the postgres catalog either appear to be internal errors that should be marked differently, or they are in my estimation unintelligible to users and should be rephrased. OK, will look. -- Simon Riggs www.2ndQuadrant.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] Proposal: Add JSON support
I've been wondering whether the JSON datatype should be strict or conservative. For one, there's strict JSON (following the exact specification). Then there's more conservative JSON variants. Some JSON parsers support comments, some support invalid number formats (e.g. '3.' or '+5'), etc.. The consensus seems to be that JSON content should be stored verbatim (it should store the exact string the client sent to it), as is done with XML. However, this notion is somewhat incompatible with Be conservative in what you do; be liberal in what you accept from others because we can't accept loose JSON, then spit out conservative JSON without messing with the content. Here's my idea: the datatype should only allow strict JSON, but there should be a function that accepts a liberal format, cleans it up to make it strict JSON, and converts it to JSON. I think making strict JSON the default makes the most sense because: * Inputs to the database will most likely be coming from programs, not humans. * Output is expected to be valid JSON and work anywhere JSON should work. * Strict JSON is what more people would expect, I'd think. -- 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] [RFC] nodeToString format and exporting the SQL parser
Hi, Michael Tharp wrote: I have been spending a little time making the internal SQL parser available to clients via a C-language SQL function. This sounds very much like one of the Cluster Features: http://wiki.postgresql.org/wiki/ClusterFeatures#API_into_the_Parser_.2F_Parser_as_an_independent_module Is this what you (or David) have in mind? Regards Markus Wanner -- 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] Proposal: Add JSON support
On Sat, Apr 3, 2010 at 8:59 AM, Joseph Adams joeyadams3.14...@gmail.com wrote: I've been wondering whether the JSON datatype should be strict or conservative. For one, there's strict JSON (following the exact specification). Then there's more conservative JSON variants. Some JSON parsers support comments, some support invalid number formats (e.g. '3.' or '+5'), etc.. The consensus seems to be that JSON content should be stored verbatim (it should store the exact string the client sent to it), as is done with XML. However, this notion is somewhat incompatible with Be conservative in what you do; be liberal in what you accept from others because we can't accept loose JSON, then spit out conservative JSON without messing with the content. Here's my idea: the datatype should only allow strict JSON, but there should be a function that accepts a liberal format, cleans it up to make it strict JSON, and converts it to JSON. I think making strict JSON the default makes the most sense because: * Inputs to the database will most likely be coming from programs, not humans. * Output is expected to be valid JSON and work anywhere JSON should work. * Strict JSON is what more people would expect, I'd think. +1 -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.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] message clarifications
Peter Eisentraut pete...@gmx.net writes: The following messages from the postgres catalog either appear to be internal errors that should be marked differently, or they are in my estimation unintelligible to users and should be rephrased. #: commands/async.c:1424 msgid pg_notify queue is %.0f%% full This one is probably my responsibility (the others all look like Simon's code). What do you not like about it, exactly? Perhaps it should be NOTIFY queue is x% full? 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] Proposal: Add JSON support
Mike Rylander wrote: Here's my idea: the datatype should only allow strict JSON, but there should be a function that accepts a liberal format, cleans it up to make it strict JSON, and converts it to JSON. I think making strict JSON the default makes the most sense because: * Inputs to the database will most likely be coming from programs, not humans. * Output is expected to be valid JSON and work anywhere JSON should work. * Strict JSON is what more people would expect, I'd think. +1 Yeah. That's the only thing that makes sense to me. We don't allow badly formed XML, for example, although we do allow document fragments (as required by the standard, IIRC). But we could sensibly have some function like 'cleanup_json(almost_json text) returns json'. 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] pgindent cleanup
Following up Tom's complaint about behaviour of pgindent, I have been
wrestling with it a bit. I noticed several things.
First awk on my box spits out fairly useless warnings about regular
expressions containing a literal '\*'. These warnings are silenced by
replacing those with '[*]', which should have the same effect.
Second, the script issues warnings about how somebody hopes that I
installed indent.bsd.patch. Yes I did, and the messages are just
annoying noise, so I propose to get rid of them. The usual rule of unix
utilities is to be silent on success, and I think we should follow it.
Third, as mentioned in that other thread I think we should put the
exclusion of certain typedef symbols into the pgindent script.
The attached patch does all three of these things.
I'm not done yet - I am seeing issues with at least two files:
contrib/fuzzystrmatch/dmetaphone.c and
src/backend/tsearch/wparser_def.c, that I need to chase down.
Ideally, this hodegpodge of awk and sed pipes would be replaced by a
perl script that would do all that inline much more efficiently, along
with some more features. But that's a longer term project.
cheers
andrew
*** src/tools/pgindent/pgindent 2009-06-15 18:09:49.0 -0400
--- /usr/local/bin/pgindent 2010-04-03 11:46:29.0 -0400
***
*** 39,45
then echo You appear to have GNU indent rather than BSD indent. 2
echo See the pgindent/README file for a description of its problems. 2
EXTRA_OPTS=-cdb -bli0 -npcs -cli4 -sc
! else echo Hope you installed /src/tools/pgindent/indent.bsd.patch. 2
EXTRA_OPTS=-cli1
fi
--- 39,45
then echo You appear to have GNU indent rather than BSD indent. 2
echo See the pgindent/README file for a description of its problems. 2
EXTRA_OPTS=-cdb -bli0 -npcs -cli4 -sc
! else
EXTRA_OPTS=-cli1
fi
***
*** 138,144
# We get the list of typedef's from /src/tools/find_typedef
indent -bad -bap -bc -bl -d0 -cdb -nce -nfc1 -di12 -i4 -l79 \
-lp -nip -npro -bbb $EXTRA_OPTS \
! `cat $TYPEDEFS | sed -e '/^$/d' -e 's/.*/-T /'` \
/tmp/$$a /tmp/$$ 21
if [ $? -ne 0 -o -s /tmp/$$ ]
--- 138,144
# We get the list of typedef's from /src/tools/find_typedef
indent -bad -bap -bc -bl -d0 -cdb -nce -nfc1 -di12 -i4 -l79 \
-lp -nip -npro -bbb $EXTRA_OPTS \
! `egrep -v '^(FD_SET|date|interval|timestamp|ANY)$' $TYPEDEFS | sed -e '/^$/d' -e 's/.*/-T /'` \
/tmp/$$a /tmp/$$ 21
if [ $? -ne 0 -o -s /tmp/$$ ]
***
*** 226,232
skips--;
if (line1 ~ / *{$/
line2 ~ /^$/
! line3 ~ / *\/\*$/)
{
print line1;
print line3;
--- 226,232
skips--;
if (line1 ~ / *{$/
line2 ~ /^$/
! line3 ~ / *\/[*]$/)
{
print line1;
print line3;
***
*** 252,258
{
if (NR != 1)
{
! if ($0 ~ /\* _PGMV)
{
# remove tag
sub( _PGMV, , $0);
--- 252,258
{
if (NR != 1)
{
! if ($0 ~ /[*] _PGMV)
{
# remove tag
sub( _PGMV, , $0);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] ECPG doesn't delete its output file in case of an error
Hi,
I saw you changed my warn about hidden vars patch
to ET_ERROR instead of ET_FATAL. My thinking in using
ET_FATAL was that this is an error level that immedately
quits processing and deletes its output file. However,
you are right that we might want to report all such errors
in one run of ECPG.
But if ET_ERROR is used, the output file stays there as if
there was no error. Think about a project that uses Makefile
with say:
.PRECIOUS: %.c
to keep the generated C sources by ECPG. However, the implicit
thinking is that the files were correctly generated.
In such a case, GNU make won't delete the generated file,
and ECPG won't be called the next time make is run as
the *.c file already exists (make won't know that ECPG reported
an error code last time) and the C compiler will be called.
directly. GCC on the other hand, deletes its object file
in case of an error (it also reports as many errors as it can),
so running make next time won't attempt linking to a bad
object file.
Attached is the patch to delete the output file if an error
happened. Comments?
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil. (Matthew 5:37) - basics of digital technology.
May your kingdom come - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig Schönig GmbH
http://www.postgresql.at/
*** pgsql/src/interfaces/ecpg/preproc/ecpg.c~ 2010-04-03 18:15:53.0 +0200
--- pgsql/src/interfaces/ecpg/preproc/ecpg.c 2010-04-03 18:15:53.0 +0200
***
*** 469,474
--- 469,482
fclose(yyin);
if (out_option == 0 yyout != stdout)
fclose(yyout);
+ /*
+ * If there was an error, delete the output file.
+ */
+ if (ret_value != 0)
+ {
+ if (strcmp(output_filename, -) != 0 unlink(output_filename) != 0)
+ fprintf(stderr, _(could not remove output file \%s\\n), output_filename);
+ }
}
if (output_filename out_option == 0)
--
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] message clarifications
On Apr 3, 2010, at 11:13 AM, Tom Lane t...@sss.pgh.pa.us wrote: Peter Eisentraut pete...@gmx.net writes: The following messages from the postgres catalog either appear to be internal errors that should be marked differently, or they are in my estimation unintelligible to users and should be rephrased. #: commands/async.c:1424 msgid pg_notify queue is %.0f%% full This one is probably my responsibility (the others all look like Simon's code). What do you not like about it, exactly? Perhaps it should be NOTIFY queue is x% full? I think maybe the question is why the user should care, or what they are expected to do about it? ...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] message clarifications
On Sat, Apr 3, 2010 at 9:02 PM, Robert Haas robertmh...@gmail.com wrote: On Apr 3, 2010, at 11:13 AM, Tom Lane t...@sss.pgh.pa.us wrote: Peter Eisentraut pete...@gmx.net writes: The following messages from the postgres catalog either appear to be internal errors that should be marked differently, or they are in my estimation unintelligible to users and should be rephrased. #: commands/async.c:1424 msgid pg_notify queue is %.0f%% full This one is probably my responsibility (the others all look like Simon's code). What do you not like about it, exactly? Perhaps it should be NOTIFY queue is x% full? I think maybe the question is why the user should care, or what they are expected to do about it? The user/administrator should make sure that all backends work through the list of pending notifications. He does it by making sure that there are no long-running or idle-in-transaction backends. Actually there is more information given via errdetail and errhint: ereport(WARNING, (errmsg(pg_notify queue is %.0f%% full, fillDegree * 100), (minPid != InvalidPid ? errdetail(PID %d is among the slowest backends., minPid) : 0), (minPid != InvalidPid ? errhint(Cleanup can only proceed if this backend ends its current transaction.) : 0))); Peter, if you consider the additional information given here, do you still see an issue? Joachim -- 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] message clarifications
Robert Haas robertmh...@gmail.com writes: On Apr 3, 2010, at 11:13 AM, Tom Lane t...@sss.pgh.pa.us wrote: What do you not like about it, exactly? Perhaps it should be NOTIFY queue is x% full? I think maybe the question is why the user should care, or what they are expected to do about it? The errdetail and errhint that go along with it will perhaps help to answer that. 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] fallback_application_name and pgbench
Hi, By default, the application_name of pgbench is [unknown]. But I think that pgbench should use fallback_application_name as psql, pg_dump, etc does. Is it worth creating the patch? 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] \d commands in psql 9.0
Hi, Seems like \dd and \ddp+ gives the same answer... The reason this is misleading is that \ddp is a command and i was trying to get extra info with \ddp+ (which doesn't exist) are we requiring a space between the command and it's first parameter? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- 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] \d commands in psql 9.0
Jaime Casanova jcasa...@systemguards.com.ec writes: are we requiring a space between the command and it's first parameter? Yes. 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] default privileges
Hi, I create some default privileges, now i'm trying to drop those roles but i get this error: mic=# drop role jcm; ERROR: role jcm cannot be dropped because some objects depend on it DETAIL: owner of default privileges on new relations belonging to role jcm in schema public So i look for default privileges and try to REVOKE privileges for all roles i found here mic=# \ddp Default access privileges Owner | Schema | Type | Access privileges --++---+--- jcm | public | table | jcm1 | public | table | postgres | public | table | rup | public | table | (4 rows) but i still have the same error when trying to drop the role, so the questions are: what is the role that owned the default the one in FOR ROLE target or the one in the simplified grant, i guess it's the first one... but i try REVOKE in all combinations and nothing works... maybe the \ddp needs to show more info? or we need a CASCADE clause in the DROP ROLE? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- 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] \d commands in psql 9.0
On Sat, Apr 3, 2010 at 4:46 PM, Tom Lane t...@sss.pgh.pa.us wrote: Jaime Casanova jcasa...@systemguards.com.ec writes: are we requiring a space between the command and it's first parameter? Yes. then, something is wrong because \ddp+ should be giving an error (because that command doesn't exist and \dd seems to be accepting the p+ as a parameter) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- 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] \d commands in psql 9.0
Jaime Casanova jcasa...@systemguards.com.ec writes: then, something is wrong because \ddp+ should be giving an error (because that command doesn't exist and \dd seems to be accepting the p+ as a parameter) No, it's just ignoring the p+, not treating it as a parameter. I agree this is bogus --- patch committed. 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] default privileges
Jaime Casanova jcasa...@systemguards.com.ec writes: I create some default privileges, now i'm trying to drop those roles but i get this error: mic=# drop role jcm; ERROR: role jcm cannot be dropped because some objects depend on it DETAIL: owner of default privileges on new relations belonging to role jcm in schema public So i look for default privileges and try to REVOKE privileges for all roles i found here mic=# \ddp Default access privileges Owner | Schema | Type | Access privileges --++---+--- jcm | public | table | jcm1 | public | table | postgres | public | table | rup | public | table | (4 rows) Yeah. The problem here is that once you've created an entry in pg_default_acl, there is no way to make it go away. You can reduce it to an empty ACL list, as Jaime evidently did, but the entry is still there and still has a dependency on the owner. This clearly wasn't thought out well enough :-(. I suggest that what we should do is arrange for the entry to be deleted by an ALTER DEFAULT PRIVILEGES command that restores it to the default state --- that is, empty for a schema-local default ACL, or equal to the built-in privilege defaults for a global default ACL. Then, the way to get rid of it is just to reverse whatever ALTER DEFAULT PRIVILEGES commands you gave originally. Anything else will require inventing special commands or special rules. 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] default privileges
I wrote: Yeah. The problem here is that once you've created an entry in pg_default_acl, there is no way to make it go away. Actually that's not true: you can get rid of it with DROP OWNED BY. This fact is even documented in the ALTER DEFAULT PRIVILEGES manual page: If you wish to drop a role that has had its global default privileges altered, it is necessary to use DROP OWNED BY first, to get rid of the default privileges entry for the role. Not sure if this is good enough or we need to provide some more-obvious way of dealing with it. 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] default privileges
On Sat, Apr 3, 2010 at 5:27 PM, Tom Lane t...@sss.pgh.pa.us wrote: I wrote: Yeah. The problem here is that once you've created an entry in pg_default_acl, there is no way to make it go away. Actually that's not true: you can get rid of it with DROP OWNED BY. This fact is even documented in the ALTER DEFAULT PRIVILEGES manual page: If you wish to drop a role that has had its global default privileges altered, it is necessary to use DROP OWNED BY first, to get rid of the default privileges entry for the role. ah! i obviously didn't read the manual in detail :) Not sure if this is good enough or we need to provide some more-obvious way of dealing with it. it's strange that a REVOKE doesn't clean what a GRANT did, and DROP OWNED BY seems very dangerous (at least if i forgot to make REASSIGN OWNED first). we can let it as it is, but at least we can add a HINT for use DROP OWNED BY having execute REASSIGN OWNED first... or we can make what seems more reasonable, make the REVOKE clean the mess :) if you prefer the second way i can try to prepare a patch -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_stat_tmp/pgstat.stat: Stale NFS file handle
Hi, i was running installcheck on a 9.0 installation and get 6 failed tests, but when reading the regression.diff i found a lot of this messages: + WARNING: could not open statistics file pg_stat_tmp/pgstat.stat: Stale NFS file handle and when listing the file i get this: postg...@casanova1:/usr/local/pgsql/9.0$ ls -lh data/pg_stat_tmp/ ls: no se puede acceder a data/pg_stat_tmp/pgstat.stat: `handle' de fichero NFS en desuso total 0 -? ? ? ? ?? pgstat.stat this is an ext2 filesystem in an external hard drive, could be fs corruption? any ideas? anything i could do to fix this without dropping my 90Gb test env? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
