[BUGS] BUG #7479: SERVICE NOT START
The following bug has been logged on the website: Bug reference: 7479 Logged by: DIEGO DE OLIVEIRA CORDEIRO Email address: diego.olive...@bentonisa.com PostgreSQL version: 8.3.0 Operating system: FEDORA LINUX Description: DO NOT START THE SERVICE, DATABASE IS OK, WHAT CAN WE DO? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7478: Error when using pg_restore
The following bug has been logged on the website: Bug reference: 7478 Logged by: jeferson Email address: jefersonbl...@gmail.com PostgreSQL version: 9.1.4 Operating system: Windows 7 Description: pg_dump -Fc -U usuario -d banco -f d:\arquivo.backup However the restourar pg_restore with tables that are large give the error: [compres_io] invalid block type, already checked on some other forums people have had the same problem when using and enjoying the dump format with custom, I tried restourar the contents into a file. sql but when you get 14 gigs of the entity for it. I would like to give me a light to this problem. thank you -- 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 #7479: SERVICE NOT START
On 08/03/2012 08:04 PM, diego.olive...@bentonisa.com wrote: The following bug has been logged on the website: Bug reference: 7479 Logged by: DIEGO DE OLIVEIRA CORDEIRO Email address: diego.olive...@bentonisa.com PostgreSQL version: 8.3.0 Operating system: FEDORA LINUX Description: DO NOT START THE SERVICE, DATABASE IS OK, WHAT CAN WE DO? You need to post a lot more detail for anybody to be able to help you. http://wiki.postgresql.org/wiki/Guide_to_reporting_problems There's no sign this is a bug, so I recommend you post a question to the pgsql-general mailing list, where there are many more people. Make sure you explain: - What went wrong, ie what caused it to go from working to non-working - What, if anything ,you have tried to do to fix it already - Any recent changes or events and include: - The full PostgreSQL version. (You really can't be running 8.3.0, right? It should be 8.3.something.) - The full Fedora version - information about your hardware - Your PostgreSQL server logs - Your kernel "dmesg" -- Craig Ringer
Re: [BUGS] BUG #6117: psql -c does not work as expected. a documentation bug? a program bug?
On Thu, Jul 14, 2011 at 10:10:28AM +0800, Craig Ringer wrote: > On 14/07/2011 4:53 AM, Aleksey Tsalolikhin wrote: > >The following bug has been logged online: > > > >Bug reference: 6117 > >Logged by: Aleksey Tsalolikhin > >Email address: atsaloli.t...@gmail.com > >PostgreSQL version: 8.4.8 > >Operating system: CentOS 5.5 (64-bit) > >Description:psql -c does not work as expected. a documentation bug? > > a program bug? > >Details: > > > >The psql man page says, in the section for the -c option: > > > > If the command string contains multiple SQL > > commands, they are processed in a single > > transaction > > > >However when I run a command string with multiple > >SQL commands, apparently only the last one is > >processed. > > > What's happening is that all of them are processed, but only the > output for the last one is emitted. I agree that the documentation > isn't clear about that, and I'm not sure whether or not that was the > intended result. > > psql -c "CREATE TABLE test(x integer); INSERT INTO test(x) VALUES > (1),(2),(3); SELECT version(); SELECT * FROM test;" > x > --- > 1 > 2 > 3 > (3 rows) > > > Comments anybody? Just fix the docs, or is this a behaviour issue? I have added documentation for this behavior. Patch attached, and backpatched to 9.2 and 9.1. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml new file mode 100644 index b6bf6a3..1ba5ea8 *** a/doc/src/sgml/ref/psql-ref.sgml --- b/doc/src/sgml/ref/psql-ref.sgml *** PostgreSQL documentation *** 99,105 BEGIN/COMMIT commands included in the string to divide it into multiple transactions. This is different from the behavior when the same string is fed to !psql's standard input. --- 99,106 BEGIN/COMMIT commands included in the string to divide it into multiple transactions. This is different from the behavior when the same string is fed to !psql's standard input. Also, only !the result of the last SQL command is returned. -- 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 #6126: CC parameter in to_char() behaves incorrectly
On Thu, Jul 21, 2011 at 08:40:11AM +, Artem Andreev wrote:
>
> The following bug has been logged online:
>
> Bug reference: 6126
> Logged by: Artem Andreev
> Email address: ar...@oktetlabs.ru
> PostgreSQL version: 9.0.4
> Operating system: Debian 6.0
> Description:CC parameter in to_char() behaves incorrectly
> Details:
>
> CC parameter in to_char() behaves incorrectly with BC dates:
>
> 1st century BC:
>
> select to_char('0002-01-01 00:00:00 BC' :: timestamp, 'CC');
> >
> to_char
> -
> 01
>
> 2nd century BC:
>
> select to_char('0101-01-01 00:00:00 BC' :: timestamp, 'CC');
> =>
> to_char
> -
> 00
>
> 3rd century BC:
> iliran=> select to_char('0301-01-01 00:00:00 BC' :: timestamp, 'CC');
> to_char
> -
> -2
>
> In all these cases EXTRACT(CENTURY FROM ...) yields the expected result
I have developed the attached patch which fixes this bug:
test=> select to_char('0002-01-01 00:00:00 BC' :: timestamp, 'CC');
to_char
-
-1
(1 row)
test=> select to_char('0101-01-01 00:00:00 BC' :: timestamp, 'CC');
to_char
-
-2
(1 row)
test=> select to_char('0301-01-01 00:00:00 BC' :: timestamp, 'CC');
to_char
-
-4
(1 row)
I also tested boundry values, e.g. 6th Century BC is 600-501:
test=> select to_char('0600-01-01 00:00:00 BC' :: timestamp, 'CC');
to_char
-
-6
(1 row)
test=> select to_char('0599-01-01 00:00:00 BC' :: timestamp, 'CC');
to_char
-
-6
(1 row)
test=> select to_char('0501-01-01 00:00:00 BC' :: timestamp, 'CC');
to_char
-
-6
(1 row)
test=> select to_char('0500-01-01 00:00:00 BC' :: timestamp, 'CC');
to_char
-
-5
(1 row)
I am thinking it is too late to apply this for 9.2 because users might
have already tested their applications, though I doubt many are using BC
dates. Feedback?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/src/backend/utils/adt/formatting.c b/src/backend/utils/adt/formatting.c
new file mode 100644
index 4347ad3..6550296
*** a/src/backend/utils/adt/formatting.c
--- b/src/backend/utils/adt/formatting.c
*** DCH_to_char(FormatNode *node, bool is_in
*** 2640,2647
case DCH_CC:
if (is_interval) /* straight calculation */
i = tm->tm_year / 100;
! else /* century 21 starts in 2001 */
! i = (tm->tm_year - 1) / 100 + 1;
if (i <= 99 && i >= -99)
sprintf(s, "%0*d", S_FM(n->suffix) ? 0 : 2, i);
else
--- 2640,2654
case DCH_CC:
if (is_interval) /* straight calculation */
i = tm->tm_year / 100;
! else
! {
! if (tm->tm_year > 0)
! /* Century 20 == 1901 - 2000 */
! i = (tm->tm_year - 1) / 100 + 1;
! else
! /* Century 6BC == 600BC - 501BC */
! i = tm->tm_year / 100 - 1;
! }
if (i <= 99 && i >= -99)
sprintf(s, "%0*d", S_FM(n->suffix) ? 0 : 2, i);
else
diff --git a/src/test/regress/expected/timestamp.out b/src/test/regress/expected/timestamp.out
new file mode 100644
index ab8faab..db2cfe6
*** a/src/test/regress/expected/timestamp.out
--- b/src/test/regress/expected/timestamp.out
*** SELECT '' AS to_char_3, to_char(d1, 'Y,Y
*** 992,998
| 1,997 1997 997 97 7 20 1 02 07 045 14 6 2450494
| 1,997 1997 997 97 7 20 1 02 07 046 15 7 2450495
| 1,997 1997 997 97 7 20 1 02 07 047 16 1 2450496
!| 0,097 0097 097 97 7 01 1 02 07 047 16 3 1686042
| 0,097 0097 097 97 7 01 1 02 07 047 16 7 1756536
| 0,597 0597 597 97 7 06 1 02 07 047 16 5 1939157
| 1,097 1097 097 97 7 11 1 02 07 047 16 3 2121778
--- 992,998
| 1,997 1997 997 97 7 20 1 02 07 045 14 6 2450494
| 1,997 1997 997 97 7 20 1 02 07 046 15 7 2450495
| 1,997 1997 997 97 7 20 1 02 07 047 16 1 2450496
!| 0,097 0097 097 97 7 -1 1 02 07 047 16 3 1686042
| 0,097 0097 097 97 7 01 1 02 07 047 16 7 1756536
| 0,597 0597 597 97 7 06 1 02 07 047 16 5 1939157
| 1,097 1097 097 97 7 11 1 02 07 047 16 3 2121778
*** SELECT '' AS to_char_4, to_char(d1, 'FMY
*** 1063,1069
| 1,997 1997 997 97 7 20 1 2 7 45 14 6 2450494
| 1,997 1997 997 97 7 20 1 2 7 46 15 7 2450495
| 1,997 1997 997 97 7 20 1 2 7 47 16 1 2450496
!| 0,097 97 97 97 7 1 1 2 7 47 16 3 1686042
| 0,097 97 97 97 7 1 1 2 7 47 16 7 1756536
| 0,597 597 597 97 7 6 1 2 7 47 16 5 1939157
