we need is for pg_dumpall to _not_ output those handlers.
Or pick it up in the check stage and make the user resolve the
problem. If I shot myself in the foot in some particularly obtuse way,
it might not be sane to bend over backwards making pg_upgrade repair
things.
--
Stuart Bishop
http://
1 PDT LOG: record with zero length at 1C5/95D2FE00
Now I'm running Ubuntu 12.04 LTS (Precise) with openssl 1.0.1, and I
think all the known renegotiation issues have been dealt with. I still
get failures, but they are less informative:
2013-03-15 03:55:12 UTC LOG: SSL
renegotiation f
hose keys being reused by accounts that
shouldn't be reusing them. Please don't deprecate it unless there is
an alternative. And if you are a pg_pool or pgbouncer maintainer,
please consider adding support :)
--
Stuart Bishop
http://www.stuartbishop.net/
--
Sent via pgsql-hackers mai
pm or 7pm depending on the policical edicts.
If you are only storing past events, its not normally an issue but
timezone information does occasionally get changed retroactively if
errors are discovered.
--
Stuart Bishop
http://www.stuartbishop.net/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Mark Shuttleworth wrote:
> Tom Lane wrote:
>> (1) something (still not sure what --- Martin and Mark, I'd really like
>> to know) was issuing random SIGTERMs to various postgres processes
>> including autovacuum.
>>
>
> This may be a misfeature in our te
Tom Lane wrote:
> Stuart Bishop <[EMAIL PROTECTED]> writes:
>> After a test is run, the test harness kills any outstanding connections so
>> we can drop the test database. Without this, a failing test could leave open
>> connections dangling causing the drop database to
t;
> There is a pg_backend_pid() function, even if it's not documented with
> the other functions (it's in the stats function stuff for some reason).
eh. No worries - my safeguard is just a comment saying 'don't connect to the
same database you are
might end up to a similar process to GNU
Bazaar except with yearly major releases and 2 month development
releases, documented at
http://doc.bazaar-vcs.org/latest/developers/cycle.html. This is a
smaller project, but had to address a number of similar concerns that
PostgreSQL would have to so may b
s). There was some flak but
we are still here.
I personally suspect PostgreSQL would want a 1 year cycle for major
releases while a full dump/reload is required for upgrades. When this
changes, 6 or even 4 months might actually be a good fit.
--
Stuart Bishop
http://www.stuartbishop.net/
rary tables belonging to other
sessions where fed to pgstattuple.
--
Stuart Bishop
http://www.stuartbishop.net/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ption to be raised personally.
> I'm ok with returning NULLs as well, but returning zeroes doesn't feel
> right.
--
Stuart Bishop
http://www.stuartbishop.net/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ain(pg, i):
return i
$python$;
Thoughts? [...it still has a *long* ways to go =]
I tend to dislike magic function names, but perhaps it is the most usable
solution.
--
Stuart Bishop
http://www.stuartbishop.net/
signature.asc
Description: OpenPGP digital signature
12 matches
Mail list logo
