As an exercise, I've written the following query to implement [FizzBuzz][1].
SELECT COALESCE(fizz || buzz, fizz, buzz, '' || n) AS fizzbuzz
FROM (
SELECT n0 + 3 * n3 + 9 * n9 + 27 * n27 + 81 * n81 AS n
FROM
(SELECT 0 AS n0 UN
psql in version 9.1 connect to server 9.3 get the same error as above.
=>
dpkg -l | grep libpq
ii libpq5 9.1.13-0wheezy1
amd64PostgreSQL C client library
the other I cant say, now thats
ii libpq5:amd64 9.4~beta1-2.pgdg70+1
amd64
What's really strange is that the function is returning the code like this:
FUNCTION public."PRUEBA_FUNCION2"(p_1 integer, OUT p_2 integer, INOUT p_3
integer, VARIADIC p_4 integer[])
RETURNS SETOF record
LANGUAGE plpgsql
IMMUTABLE STRICT SECURITY DEFINER ROWS 200
AS $function$begin
null;
end;
On Wed, Jul 16, 2014 at 1:21 PM, Thomas Kellerer wrote:
> Hi,
>
> I was reading trough the ToDo list in the Postgres Wiki and noticed that
> one item for Fsync[1] seems to be obsolete:
>
>Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options and whether
> fsync does anything
>Idea
Hi,
I was reading trough the ToDo list in the Postgres Wiki and noticed that one
item for Fsync[1] seems to be obsolete:
Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options and whether fsync
does anything
Ideally this requires a separate test program like
/contrib/pg_test_fsyn
Hi,
PostgreSQL version: 9.1.16. Linux: RHEL6.
After a heavy traffic run, a huge pg_toast table is seen. Its size is ~3G.
There also exist other pg_toast tables in a much smaller size, for example,
~100M. The problem is that that huge pg_toast table never gets auto vacuumed
while other small pg_t
Shaun Thomas wrote:
>
> > It's an autovacuum worker, which is expected. Just get rid of the
> > file and all should be well.
>
> That's what I figured, but I didn't want to make assumptions. Does
> removing the file require a restart?
Don't think so, but TBH I didn't try.
--
Álvaro
> BTW if you do a hexdump of the file, it should be all zeroes.
Yep, that's what I get. :)
__
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to
this email
--
Sent via pgsql-general mailing list (pgsql-general@post
Alvaro Herrera wrote:
> Shaun Thomas wrote:
> > This:
> >
> > 23334|429396427453c68b69.5b26|2014-07-16 09:25:45 CDT|ERROR: could not
> > access status of transaction 7150346
> > 23334|429396427453c68b69.5b26|2014-07-16 09:25:45 CDT|DETAIL: Could
> > not open file "pg_multixact/offsets/
> It's an autovacuum worker, which is expected. Just get rid of the
> file and all should be well.
That's what I figured, but I didn't want to make assumptions. Does removing the
file require a restart?
__
See http://www.peak6.com/email_di
Shaun Thomas wrote:
> This:
>
> 23334|429396427453c68b69.5b26|2014-07-16 09:25:45 CDT|ERROR: could not
> access status of transaction 7150346
> 23334|429396427453c68b69.5b26|2014-07-16 09:25:45 CDT|DETAIL: Could not
> open file "pg_multixact/offsets/006D": No such file or directory.
>
This:
23334|429396427453c68b69.5b26|2014-07-16 09:25:45 CDT|ERROR: could not
access status of transaction 7150346
23334|429396427453c68b69.5b26|2014-07-16 09:25:45 CDT|DETAIL: Could not
open file "pg_multixact/offsets/006D": No such file or directory.
Been doing it every ten seconds s
On 2014-07-16 14:24:12 +, Shaun Thomas wrote:
>
> > See here:
> >
> > https://wiki.postgresql.org/wiki/20140702pg_upgrade_fix
>
> Thank $Deity! We'll schedule this ASAP. Our cluster is whining about this
> about every 10 seconds, which is kind of a PITA.
What exactly is it whining about?
G
On 07/16/2014 01:13 AM, basti wrote:
Yes all clusters, run on the same machine.
All packages are from pgdg.
libpq5 is version 9.3.4-1.pgdg70+1
That is not what a previous post indicated:
"dpkg -l | grep libpq
ii libpq5 9.1.13-0wheezy1
amd64PostgreSQL C cli
> See here:
>
> https://wiki.postgresql.org/wiki/20140702pg_upgrade_fix
Thank $Deity! We'll schedule this ASAP. Our cluster is whining about this about
every 10 seconds, which is kind of a PITA.
Thanks again!
__
See http://www.peak6.com/email_discla
On 07/16/2014 07:08 AM, Shaun Thomas wrote:
Hey,
We performed an upgrade via pg_upgrade from 9.1 to 9.3 a while back, and I'm
almost certain we were bitten by this bug:
http://www.postgresql.org/message-id/20140530121631.ge25...@alap3.anarazel.de
Finding the discussion is nice... but what do
Hey,
We performed an upgrade via pg_upgrade from 9.1 to 9.3 a while back, and I'm
almost certain we were bitten by this bug:
http://www.postgresql.org/message-id/20140530121631.ge25...@alap3.anarazel.de
Finding the discussion is nice... but what do we do to fix this? I read through
the discuss
> -Original Message-
> From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
> ow...@postgresql.org] On Behalf Of basti
> Sent: Mittwoch, 16. Juli 2014 10:14
> To: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] php password authentication failed for user ...
>
> Yes all
Yes all clusters, run on the same machine.
All packages are from pgdg.
libpq5 is version 9.3.4-1.pgdg70+1
the problem is still the same,
The relevant database is only for testing and development,
I will downgrade to 9.1.
Thanks for helping.
Regards,
basti
Am 15.07.2014 16:46, schrieb Adrian Kla
Hey,
I guess you know all about PL/R,
the R language extension for postgres .
It is very convenient, though be carefull as sometime it crashed my server.
Cheers,
Rémi-C
2014-07-16 3:42 GMT+02:00 John McKown :
> On Tue, Jul 15, 2014 at 8:46 AM, David G Johnston <
> david.g.johns...@gmail.com> wr
20 matches
Mail list logo
