[BUGS] BUG #8442: Postgresql Crash Frequently and It is installed on m68k platorm
The following bug has been logged on the website: Bug reference: 8442 Logged by: RajaPraveen Email address: rajaprave...@gmail.com PostgreSQL version: 9.2.3 Operating system: Embedded Linux 2.6.29 Description: Sometimes It gives below message and some times without any error, it will be killed. Appreciate your help for solving the issue and please share recommended configuration settings for embedded platform. Hardware: Nand Flash DataBase Size: 50MB (Max) Load: Less Shared Memory Allocated: 24MB (Default) 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. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Error by restore a database
On 9/9/2013 11:38 PM, Sbis-Partner wrote: When you restore a database error occurs «Pg_restore: creating TABLE dbschema pg_restore: [archiver (db)] Error from TOC entry 1428; 1259 83487 TABLE dbschema User pg_restore: [archiver (db)] could not execute query: ERROR: role "User" does not exist Command was: ALTER TABLE public.dbschema OWNER TO "User" ». Please help me to solve this problem. users are not stored as part of a single database, they are global to the database cluster. you need to create any users required by a given database before you can restore it. CREATE USER "User" WITH PASSWORD 'somekindapassword'; Note the same is true for tablespaces, if you use those. -- john r pierce 37N 122W somewhere on the middle of the left coast
[BUGS] Error by restore a database
Hello! When you restore a database error occurs . Please help me to solve this problem.
Re: [BUGS] BUG #7836: COPY command does not honor 'FORMAT' option
On Tue, Jan 29, 2013 at 05:52:16PM -0500, Tom Lane wrote: > Jeff Janes writes: > > I figured out the need for the parenthesis by reading the docs. The > > need to also quote 'binary' really took me by surprise, especially as > > the other two formats don't need to be quoted. I assume the reason > > for this is the level of reservedness of the various words in bison. > > Yeah, BINARY is a type_func_name_keyword and hence not covered by the > copy_generic_opt_arg production. > > > But is this a doc bug? Should binary be shown > > quoted if it needs to be used quote? Or at least maybe the Example > > section could include an example of the use of FORMAT. > > Probably better to see if we can fix the grammar instead of documenting > a klugy workaround. I'm not sure we can easily allow fully-reserved > words there, but type_func_name_keyword might work. FYI, the need for single-quotes around 'binary' was removed with a patch and backpatched. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Spaces before newlines in view definitions in 9.3
Example test code: $ psql pyrseas_testdb psql (9.3.0) Type "help" for help. pyrseas_testdb=# create table t1 (c1 int, c2 text); CREATE TABLE pyrseas_testdb=# create view v1 as select * from t1; CREATE VIEW pyrseas_testdb=# \d+ v1 View "public.v1" Column | Type | Modifiers | Storage | Description +-+---+--+- c1 | integer | | plain| c2 | text| | extended | View definition: SELECT t1.c1, t1.c2 FROM t1; It may not be immediately obvious but there is a space after the "t1.c1," and before the first newline. In 9.2 and previous releases, the view definition is: SELECT t1.c1, t1.c2 FROM t1; If there are more columns, there's an extra space for each except the last one, e.g., (with _ denoting a trailing space): SELECT t2.c1,_ t2.c2,_ t2.c3,_ t2.c4 FROM t2; The problem is that the string comes back, e.g., from pg_get_viewdef() with those extra spaces before the newlines, e.g., " SELECT t1.c1, \nt1.c3 * 2 AS mc3\n FROM t1; and YAML has a way displaying a text string nicely so that it can be recovered when it's read back, but it *doesn't* work if there are invisible characters such as tabs or spaces before a newline because obviously one can't tell how many or of what kind they are. Note: This applies to both views and materialized views. I believe the reformatting of view text (breaking each column on a separate line) was done to improve readability but it has the side effect of making the text unreadable if processed via a YAML utility such as Pyrseas dbtoyaml (since YAML then quotes the entire string and even breaks it down further with extra backslashes). Regards, Joe -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8442: Postgresql Crash Frequently and It is installed on m68k platorm
On 10-09-2013 07:53, rajaprave...@gmail.com wrote: > Sometimes It gives below message and some times without any error, it will > be killed. Appreciate your help for solving the issue and please share > recommended configuration settings for embedded platform. > You don't provide sufficient information to classify it as a bug. > 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. > What about showing us the crash cause. I mean, before it gives those messages, it should have emitted a relevant message like LOG: server process (PID 14141) was terminated by signal 9: Killed 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. that show us the root of the problem. Also, it could be the kernel trying to free up resources (aka OOM killer), a corrupted datafile or .. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7844: xpath missing entity decoding - bug or feature
On Fri, Feb 1, 2013 at 12:02:41PM +, i...@fduerr.de wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7844
> Logged by: fduerr
> Email address: i...@fduerr.de
> PostgreSQL version: 9.2.2
> Operating system: Debian
> Description:
>
> Up until 9.1
>
> select (xpath('/z/text()', ('' || 'AT&T' || '')::xml))[1];
>
> returned 'AT&T'
> 9.2 returns 'AT&T'
>
> Is it a bug or a feature?
> Is there a function to decode xml-entities?
Does anyone have a comment on this?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7858: Inaccurate Log Message
On Fri, Feb 8, 2013 at 06:46:29AM +, jackie.qq.zh...@gmail.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7858
> Logged by: Jackie Zhang
> Email address: jackie.qq.zh...@gmail.com
> PostgreSQL version: 9.1.4
> Operating system: Ubuntu
> Description:
>
> Hi,
>
> The log message of the sanity check for "superuser_reserved_connections" in
> PostmasterMain() is not accurate. See the following code snippet:
>
> /*src/backend/postmaster/postmaster.c*/
> 730 /*
> 731 * Check for invalid combinations of GUC settings.
> 732 */
> 733 if (ReservedBackends >= MaxBackends)
> 734 {
> 735 write_stderr("%s: superuser_reserved_connections must
> be less than max_connections\n", progname);
> 736 ExitPostmaster(1);
> 737 }
>
> The problem is that "MaxBackends" is calculated by both
> "autovacuum_max_workers" and "max_connections". See assign_maxconnections()
> and assign_autovacuum_max_workers() in src/backend/utils/misc/guc.c.
>
> The log message should inform both the two configuration parameters instead
> of only one -- the root cause could be the oversized
> "autovacuum_max_workers".
The calculation, ReservedBackends >= MaxBackends, was corrected in
Postgres 9.3 with this commit:
commit b3055ab4fb5839a872bfe354b2b5ac31e6903ed6
Author: Magnus Hagander
Date: Fri Aug 10 14:49:03 2012 +0200
Fix upper limit of superuser_reserved_connections, add limit for
wal_senders
Should be limited to the maximum number of connections excluding
autovacuum workers, not including.
Add similar check for max_wal_senders, which should never be higher
than
max_connections.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7817: psql does not relate to footer settings in extended mode
Applied.
---
On Mon, Sep 9, 2013 at 09:16:05PM -0400, Bruce Momjian wrote:
> On Sun, Jan 20, 2013 at 10:33:37AM +, emes...@redhat.com wrote:
> > The following bug has been logged on the website:
> >
> > Bug reference: 7817
> > Logged by: Eli Mesika
> > Email address: emes...@redhat.com
> > PostgreSQL version: 9.1.7
> > Operating system: Fedora 16
> > Description:
> >
> > psql does not relate to footer settings in extended mode
> > Sometimes we need to run a sql command withot generating header and footer.
> > This can be done using the -t flag and --pset=footer=off
> > The problem is that the footer is still diaplyed even if it was set to off
> > if we use the extended mode for the query (-x flag)
> >
> > Steps to Reproduce:
> > 1) create a table without any data
> > for example
> > create table text(i int);
> > 2) run
> > psql -U -t --pset=footer=off
> > 3) No output is generated
> > 4) run
> > psql -U -t --pset=footer=off -x
> > 5) Output generated : "(No Rows)"
> >
> > Actual results:
> > psql does not honour the footer settings when output is defined to be in
> > Extended Mode
> >
> > Expected results:
> > psql should not generate any output is query has no results and -t and
> > --pset=footer=off were given
>
> This has been fixed in PG 9.3 (released today) for the specific options
> you supplied:
>
> $ psql -t --pset=footer=off test
> Default footer is off.
> psql (9.4devel)
> Type "help" for help.
>
> CREATE TABLE test (x INT);
> CREATE TABLE
> SELECT * FROM test;
>
> \x
> Expanded display is on.
> SELECT * FROM test;
>
> Unfortunately, this did not fix the more simple case where
> --pset=footer=off is specified, but not -t:
>
> $ psql --pset=footer=off test
> Default footer is off.
> psql (9.4devel)
> Type "help" for help.
>
> CREATE TABLE test (x INT);
> CREATE TABLE
> SELECT * FROM test;
>x
> ---
>
> \x
> Expanded display is on.
> SELECT * FROM test;
> --> (No rows)
>
> The attached patch fixes this, and makes it match the rest of the output
> formats, which do honor --pset=footer=off alone for footers.
>
> --
> Bruce Momjian http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + It's impossible for everything to be true. +
> diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
> new file mode 100644
> index 5589cea..736225c
> *** a/src/bin/psql/print.c
> --- b/src/bin/psql/print.c
> *** print_aligned_vertical(const printTableC
> *** 1171,1177
> if (cont->cells[0] == NULL && cont->opt->start_table &&
> cont->opt->stop_table)
> {
> ! if (!opt_tuples_only)
> fprintf(fout, _("(No rows)\n"));
> return;
> }
> --- 1171,1177
> if (cont->cells[0] == NULL && cont->opt->start_table &&
> cont->opt->stop_table)
> {
> ! if (!opt_tuples_only && cont->opt->default_footer)
> fprintf(fout, _("(No rows)\n"));
> return;
> }
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
