On Thu, Oct 10, 2013 at 08:32:32PM -0400, Bruce Momjian wrote:
> > > How can the later entry not be MD5 hash?
> >
> > Because what you pass to the functions is 'md5', not 'md5 hash', which
> > is what the new text appears to indicate.
>
> So
On Thu, Oct 10, 2013 at 08:22:30PM -0400, Peter Eisentraut wrote:
> On Thu, 2013-10-10 at 19:14 -0400, Bruce Momjian wrote:
> > > The changes shown below are incorrect, I think.
> > >
> > >
> > > On 10/2/13 12:00 PM, Bruce Momjian wrote:
> > > &g
o prevent errors.
Well, we can't walk the function tree to know all called functions, and
those they call, so we don't even try.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Se
On Thu, Oct 10, 2013 at 04:05:50PM -0400, Peter Eisentraut wrote:
> The changes shown below are incorrect, I think.
>
>
> On 10/2/13 12:00 PM, Bruce Momjian wrote:
> > *** gen_salt(type text [, iter_count integer
> > *** 353,359 **
documentation, f() should be marked VOLATILE also, since
> calling f() produces side effects. PostgreSQL does not give a warning (or
> better yet, an error); I think it should.
I think the answer is that function authors are required to prevent
functions they mark as STAB
On Wed, Oct 2, 2013 at 12:00:44PM -0400, Bruce Momjian wrote:
> Based on your report, I have developed the attached doc patch which
> clarifies when MD5 hash is being referenced, and when MD5 crypt is. I
> have also added your other suggestions.
Patch applied, and backpatched to 9.3.X
.) ALTER DATABASE newdb RENAME TO testdb;
> 6.) At this point hopefully we should be upgraded from postgis 1.5.3 to
> postgis
> 2.1.1, with PostgreSQL 9.1.6
> 7.) then can we just use pg_upgrade with the hard links option, instead of
> copying files to the new cluster option to
w-0001oj...@wrigleys.postgresql.org
> >
> > Someone who knows XML needs to take leadership on this and propose a
> > patch.
Added to TODO.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible
not be failing.
I am surprised it got an oid that was one less than the desired one,
18803. Is there any mention of 18803 in the SQL file? If you create a
cluster with just your schema and no data, can you upgrade that cleanly?
--
Bruce Momjian http://momjian.us
EnterpriseDB
such.
>
>
> At least the reviewer at:
>
>
> http://www.postgresql.org/message-id/201106291934.23089.rsmog...@softperience.eu
There are two other similar bug reports on this from February and March
of this year:
http://www.postgresql.org/message-id/e1u1fkl-0002rd...@
t;
> version of md5.
>
> If so, it would be clearer to write that the last 2 lines ("md5" and
> "sha1") are for comparison only, and refer to the speed of doing an
> ordinary md5/sha1 sum, rather than the md5-variant of crypt().
>
>
> Anyway, thanks again for
handles that.
pg_upgrade is fine with that. The old/new tablespaces stay in the same
mount point as just per-version subdirectories.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to
on-existing file (perhaps only when
> ON_ERROR_STOP is set to 1?).
The problem is how would we decide what psql actions should trigger a
rollback, and how would we show the user we did that.
--
Bruce Momjian http://momjian.us
EnterpriseDB h
sts:
http://www.pgadmin.org/support/list.php
--
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)
T
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:
> >
&g
imum 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
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 functi
served
> 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 impos
time, or interval. (Expressions of type date are cast to timestamp and
--> can therefore be used as well.)
Where did you see that DATE is not supported for EXTRACT?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ I
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 b
Applied.
---
On Wed, Sep 4, 2013 at 03:01:50PM -0400, Bruce Momjian wrote:
> On Wed, Dec 5, 2012 at 12:44:39AM +, el...@varlena.com wrote:
> > The following bug has been logged on the website:
> >
&g
igureNamesInt[] =
> },
> {
> {"trace_lock_table", PGC_SUSET, DEVELOPER_OPTIONS,
> - gettext_noop("No description available."),
> + gettext_noop("Sets the OID of the table with
> uncondition
have invented a 'tough' environment :(
>
> Could you point me to an active postgresql discussion of this, so I can get
> up to speed (still pretty new to the pg community).
Sorry, I have not seen this discussed anywhere.
--
Bruce Momjian http://momjian.us
Enterp
to
be zero-dimensional empty arrays, rather than 1-dimensional empty
arrays. With this patch, a zero-dimensional empty array is returned:
SELECT array_dims('{1,2,3}'::integer[] - '{3,2,1}'::integer[]);
array_dims
(null)
--
Bru
ation of a function but don't know
> which module provides it (if any at all).
FYI, this will be corrected in 9.3.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
On Fri, Aug 9, 2013 at 11:06:15AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > The attached patch swaps the arguments in the parser, and allows your
> > expected behavior:
>
> This patch is completely unsafe. It will break stored rules, which may
> contain
ng of characters to remove.
You are right this is undocumented.
The attached patch swaps the arguments in the parser, and allows your
expected behavior:
SELECT trim('x', 'xfasdx');
btrim
---
fasd
Another option would be to change t
On Fri, Aug 2, 2013 at 11:20:37PM -0400, Jesse Denardo wrote:
> Alvaro,
>
> I applied the patch and tried upgrading again, and everything seemed to work
> as
> expected. We are now up and running the beta!
Yeah, great, thanks everyone!
--
Bruce Momjian ht
ld throw an error on input.
You can see this a little bit using 9.3 beta to pull values based on
keys:
SELECT json_extract_path('{"\"a": "b\"c"}'::json, '"a');
json_extract_path
---
"b\"c
On Wed, Jul 31, 2013 at 12:56:33PM -0400, Alvaro Herrera wrote:
> Bruce Momjian escribió:
> > On Tue, Jul 30, 2013 at 10:17:52AM -0400, Jesse Denardo wrote:
>
> > So, first, this is new in 9.3, and second, it seems the comment "we need
> > to reset pg_control s
to read
multis older than the cutoff value" is not working. Alvaro, can you
comment on this? I think you added this code with this commit:
commit 0ac5ad5134f2769ccbaefec73844f8504c4d6182
Author: Alvaro Herrera
Date: Wed Jan 23 12:04:59 2013 -0300
...
't have to worry about that.
I have added a C comment documenting this bug; patch attached.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/src/bin/psql/co
nd result, DROP TABLE
> IF EXISTS is pretty much unusable with schemas. It needs to act the same as
> DROP TABLE IF EXISTS does for the default schema.
FYI, this will be fixed in Postgres 9.3.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://
tion is aborted, commands ignored until end of
> transaction block
I think ON_ERROR_ROLLBACK only controls errors in user queries, not
errors in psql operations. Sorry.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It&#x
On Thu, Jan 24, 2013 at 06:45:02PM -0500, Bruce Momjian wrote:
> On Thu, Jan 24, 2013 at 08:43:37PM -0300, Alvaro Herrera wrote:
> > Bruce Momjian escribió:
> > >
> > > On Tue, Sep 4, 2012 at 02:01:54PM -0400, Bruce Momjian wrote:
> > > > On Tue, Sep 4, 2
the wrong thing.
>
> It's a bit surprising nobody's complained of this before.
>
> I propose the attached patch. I'm slightly worried though about whether
> this might break any existing applications that are (incorrectly)
> depending on a D format specifier be
> but I receive several errors.
>
> Does it exist another way ?
I recommend doing a schema dump, adjusting the output file until it
generates no errors, then restore that, and then restore the data.
--
Bruce Momjian http://momjian.us
EnterpriseDB ht
> Operating system: windows
> Description:
>
> how to disable toasting in postgresql 9.0 please guide
See ALTER TABLE SET STORAGE.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for
pg_ctl" -w -l
> "pg_upgrade_server.log" -D "/distrib/postgresql/data/chorus_formulaires/data"
> -o "-p 50432 -c autovacuum=off -c autovacuum_freeze_max_age=20
>
> -c listen_addresses='*' -c listen_addresses='' -c
> unix_soc
EXTRACT(epoch FROM
> $2)::INTEGER * INTERVAL '1 second';
> $BODY$ LANGUAGE SQL STABLE;
>
> is doing it better - returned time looks correct. So if you want you can
> update this page.
>
> Regards,
>
> --
> Jan Krajdl
>
>
>
> --
&
an be mv'd
Actually, hard linked, not moved.
--
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
On Fri, Feb 15, 2013 at 04:06:12PM -0600, Dave Rolsky wrote:
> On Fri, 15 Feb 2013, Bruce Momjian wrote:
>
> >On Wed, Feb 13, 2013 at 08:22:43PM +, auta...@urth.org wrote:
> >>The following bug has been logged on the website:
> >>
> >>Bug reference:
pg_catalog | date_trunc | timestamp with time zone| text,
timestamp with time zone| normal
This returns a timestamp without time zone:
test=> select date_trunc('month',timestamp '2013-2-15');
date_trunc
-
Queues
> keymsqid owner perms used-bytes messages
>
> Considering that it was able to allocate this memory before the panic
> occurred, it should remove them before exiting.
>
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bu
50...@archonet.com
http://www.postgresql.org/message-id/11646.1272814...@sss.pgh.pa.us
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs maili
se "ok" errors and real errors.
>
> It should be using "DROP TABLE IF EXISTS" and the equivalent for
> constraints.
Well, I think the question is whether you want error feedback for things
that don't exist. I don't really know the answer.
--
TeamPostgreSQL is a project of Webworks (webworks.dk), and is not
affiliated with the PostgreSQL Project.
The PostgreSQL trademark is used with permission.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It&#
On Thu, Jan 24, 2013 at 08:43:37PM -0300, Alvaro Herrera wrote:
> Bruce Momjian escribió:
> >
> > On Tue, Sep 4, 2012 at 02:01:54PM -0400, Bruce Momjian wrote:
> > > On Tue, Sep 4, 2012 at 12:49:40PM -0500, Kevin Grittner wrote:
> > > > Bruce Momjian wrote:
On Tue, Sep 4, 2012 at 02:01:54PM -0400, Bruce Momjian wrote:
> On Tue, Sep 4, 2012 at 12:49:40PM -0500, Kevin Grittner wrote:
> > Bruce Momjian wrote:
> > > On Tue, Sep 4, 2012 at 12:11:53PM -0500, Kevin Grittner wrote:
> >
> > >> What do you think would
On Thu, Jan 24, 2013 at 04:51:04PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Would someone make the doc change outlined above? Thanks.
>
> Sorry, I'd nearly forgotten about this issue. Will see about fixing the
> docs. (It looks like some of the comments in ex
On Wed, Aug 29, 2012 at 01:13:51PM +, Rajeev rastogi wrote:
>
> From: pgsql-bugs-ow...@postgresql.org [pgsql-bugs-ow...@postgresql.org] on
> behalf of Bruce Momjian [br...@momjian.us]
> Sent: Wednesday, August 29, 2012 8:46 AM
> To
On Sat, Jan 19, 2013 at 11:27:28AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Why is a clean shutdown important? If the server crashed, we would have
> > committed transactions in the WAL files which are not transfered to the
> > new server, and would be lost.
>
s done. That's all what we all want to know, right?
The pid check is done before pg_upgrade starts or stops any postmaster,
to make sure both servers are down before it starts. Tom wants that
testing improved.
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Sat, Jan 19, 2013 at 12:47:03AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Sat, Jan 19, 2013 at 12:02:31AM -0500, Tom Lane wrote:
> >> In the meantime, I was wondering a bit why pg_upgrade looks at the
> >> postmaster.pid file at all.
>
> > The r
On Sat, Jan 19, 2013 at 12:02:31AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, Jan 18, 2013 at 10:19:48PM +, gio...@gmail.com wrote:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=896161
> >> Upgrading PostgreSQL from 9.1 to 9.2 with pg_upgrade/post
down before
starting pg_upgrade. pg_upgrade is not going to do that waiting.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing li
On Tue, Dec 11, 2012 at 12:28:40PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Dec 10, 2012 at 06:41:29PM +, postg...@tbruce.com wrote:
> >> In line 238 of the rpm based init.d script, the pid file is called
> >> specifically with a qualified pat
"/var/run/postmaster-9.1.pid").
>
> This is with rpm version of postgres 9.1.4 and 9.1.6 (we haven't tested
> 9.1.7 at this time).
I think you need to report this to Red Hat; we didn't create that file.
--
Bruce Momjian http://momjian.us
EnterpriseD
current/static/functions-datetime.html
Wow, that is a weird case. In the first test, we count the number of
days because it is less than a full month. In the second case, we call
it a full month, but then forget how long it is. Not sure how we could
improve this.
--
Bruce Momjian http
upport create temp tables in the
> next version,that'll be great!!!
Well, because the slave is read-only, we have not figured out how to
enable creation of temporary tables on the slave. It isn't even on our
TODO list because we have no idea how we would do it.
-
tion to the server, e.g.
-d /real-data-directory -o '-D /configuration-directory'.
-o, --old-options=OPTIONS old cluster options to pass to the server
-O, --new-options=OPTIONS new cluster options to pass to the server
--
Bruce Momjian http://momjian
):
> - Is there anything in work or planned for the fuzzystrmatch module?
> - Does anybody know about adequate replacements or upgrades of the soundex,
> metaphone etc. algorithms from academia?
I have not heard of anyone working in this area. What usually happens
is some expert in the f
the doc patch is mentioned here:
http://archives.postgresql.org/pgsql-bugs/2012-08/msg00133.php
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing
if admin forget copy pg_hba.conf to the new
> cluster - these settings could be lost forever after delete_old_cluster.sh .
This all seems like a step backwards and adds complexity that will fail.
--
Bruce Momjian http://momjian.us
EnterpriseDB h
call into that script.
>
> However, it is Linux only feature.
>
> PS: Yes I know that keeping any foreign data inside PostgreSQL data
> directory is bad idea.
I don't see how adding --one-file-system would help us. They could have
place it under the old cluster in th
.
>
> Hmm... Petteri wants to solve the issue without changing anything
> on the standby, according to his original post. So in his case, a fresh
> backup is required.
>
> Of course my previous answer was confusing...
I assume you mean the slave needs an updated copy of the
we have some docs work to do. Thanks for pointing it out.
Is there any value to having * vs just not using ONLY? I am not sure
documenting this is helping us, and it would add more clutter. Isn't
this like how we don't document the old COPY syntax.
--
Bruce Momjian http://mo
On Tue, Sep 4, 2012 at 12:49:40PM -0500, Kevin Grittner wrote:
> Bruce Momjian wrote:
> > On Tue, Sep 4, 2012 at 12:11:53PM -0500, Kevin Grittner wrote:
>
> >> What do you think would be the right thing to do with it at this
> >> point?
> >
> > Well,
On Tue, Sep 4, 2012 at 12:11:53PM -0500, Kevin Grittner wrote:
> Bruce Momjian wrote:
> > On Mon, Apr 9, 2012 at 02:07:43PM -0500, Kevin Grittner wrote:
> >> Bruce Momjian wrote:
> >>> On Mon, Apr 09, 2012 at 03:37:09PM -0300, Alvaro Herrera wrote:
> >
pg_restore: [archiver (db)] connection to database "testserver" failed:
FATAL: role "yy" does not exist
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be tru
system: Windows XP
> Description:
>
> In main application directory, inside pg_env.bat script there is lack of
> quotation marks for PGDATA and PGLOCALEDIR variables.
Dave, has this been addressed? The community does not control
pg_env.bat.
--
Bruce Momjian
> "test_constraints_val1_val2_key" con->connoinherit is false,
> due to which it tries to drop the constrint from child table as well.
> I have checked that from function index_constraint_create() when it calls
> function CreateConstraintEntry(), th
lls
> AlterRelationNamespaceInternal and about four other things. I'm not
> sure if this was broken before the last round of refactoring in this
> area, but for sure it's broken now.
Uh, did this get fixed? I can't find a commit related to the fix.
-
oximately 5-7 days?
>
> Finally, when is it safe to remove the 8.4.3 objects/directory?
You can move the data directory containing the default tablespace by
just shutting down the server and moving the directory and restarting
it. For user-defined tablespaces, you have to shut down the server an
is untrue: changing a subset of columns on a relation does
> not force "all code" using that relation to be rewritten:
>
> SELECT procpid FROM pg_stat_activity WHERE procpid <> pg_backend_pid()
True. We were thinking more of tools that display all pg_stat_activity
colum
this? PDF, web version? An example?
--
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 you
On Mon, Apr 9, 2012 at 02:07:43PM -0500, Kevin Grittner wrote:
> Bruce Momjian wrote:
> > On Mon, Apr 09, 2012 at 03:37:09PM -0300, Alvaro Herrera wrote:
>
> >> (Another related tool is clearxlogtail which zeroes areas from
> >> WAL files when they are empty bec
rom
> non-RETURNING, so the consensus is to redefine the current behavior as
> correct. That means what we need is to go through the docs and see what
> places need to be updated (and, I guess, back-patch the changes to 9.0).
> I will get to this if nobody else does, but not right awa
TODO: alter table-type columns according to attribute type rules.
> Enforce only TYPE features and ignore TABLE features when altering composite
> table-types.
>
> While I'm making up TODO's, my favorite one: support recursive types.
Should we add this TODO? I am co
y ever imagined that limits of 100 bytes or more would pose an
> issue in practice. What's the use-case for passwords longer than
> that?
Thanks for all the feedback. I know it is a pain for me to re-ask these
questions, but it allows us to know that these issues have gotten
sufficien
return NULL;
>
> @@ -108,21 +115,34 @@ simple_prompt(const char *prompt, int maxlen, bool echo)
> fflush(termout);
> }
>
> - if (fgets(destination, maxlen + 1, termin) == NULL)
> - destination[0] = '\0';
> -
>
bclause 8.2 doesn't address the possibility that "X=Y" could mean
> something other than the common idea of equality).
>
> So on the whole, it might be better to just provide an operator named
> "=" for point, and not open up the can of worms about whet
' binaries rather
> than compiling from source, or link against the dynamic runtime.
>
> Is this something I could expect to be fixed in the near future, or is it
> enough of an edge case that I should come up with some solution or work-around
> on my own? Thanks,
Late reply, but
if (n_conn)
> + psql_error("\\connect: %s",
> PQerrorMessage(n_conn));
> +
> if (o_conn)
> {
> PQfinish(o_conn);
> --
> 1.7.7.4
>
>
> --
&
a transient/fixable error, then we'd
> want to report it. It's far from clear to me that there are any
> though. What it could mean in general is not at issue, because we
> know the target is a directory that we just created moments before.
I assume this never got resolved.
On Wed, Nov 30, 2011 at 03:36:11PM -0500, Robert Haas wrote:
> On Tue, Nov 29, 2011 at 9:32 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> "David Fetter" writes:
> >> > IF EXISTS (SELECT 1 INTO STRICT i) THEN
> >> > RAISE NOTICE
new) TO stdout;
> ^
> pg_dump: The command was: COPY public.new (f1, new) TO stdout;
>
> The least painful solution might be to always quote *every* identifier
> in commands sent to the source server, since we don't especially care
> how nic
ectory the user means when invoked here. Plus,
> these steps would work fine instead at that point:
>
> pg_ctl -D /tmp/foo/bar/baz/ stop
> pg_ctl -D /tmp/foo/bar/baz/ start
>
> and I was under the impression (supported by the pg_ctl doc page,
> which claims "restart
x27;),
'latin1')
-> = to_ascii(convert_to('nicetry', 'latin1'), 'latin1');
You are currently not connected to a database.
!> \c
All connection parameters must be supplied because no database
connection exists
no good way to do
this for intervals. I have applied the attached patch to PG 9.3 which
will explain why this is not supported. I saw this as better than a
documentation mention.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprised
t a few people saying that they do rely on it ...
I think the question is whether '=' is used enough that we have to
mention that it is a non-standard extension that might be removed
someday, or something.
--
Bruce Momjian http://momjian.us
EnterpriseDB
any change for this
> bug.
I have fixed the problem with the attached, applied patch, which will
appear in Postgres 9.3. The problem was that single-quotes in usernames
were not properly escaped by initdb.
Also, I have improved the pg_hba.conf documentation, and added an assert
to catch future brea
good reason. The problem is probably due to the shared buffers filling
up with lots of dirty data, and the kernel being unable to contain all
the data coming during a checkpoint. It is also possible that the
buffer management overhead is just too high for that many buffers.
It is also poss
On Tue, Aug 14, 2012 at 05:26:39PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Opps, turns out the units are microseconds (as pointed out to me by
> > Magnus), and we don't have a microsecond designation in that file, so I
> > reverted that and just added a C c
ss you were somehow using the NAS in a way that
didn't allow hard links, but I am unclear how that would happen, and
pg_upgrade checks for that.
I guess the big question is how is production different from testing,
and how does the new server identify itself as 8.4 if you can't connect
On Tue, Aug 14, 2012 at 04:18:40PM -0400, Bruce Momjian wrote:
> On Thu, Aug 4, 2011 at 09:30:35PM +, Christoph Anton Mitterer wrote:
> >
> > The following bug has been logged online:
> >
> > Bug reference: 6150
> > Logged by: Christoph
display units. I checked all the other variables and they all
had proper units.
I also removed an unnecessary units designation in
postgresql.conf.sample for a zero value --- if we want to put units on
zero values, we should do it consistently in a separate patch.
--
Bruce Momjian http://mom
On Mon, Aug 6, 2012 at 03:20:18PM -0400, Bruce Momjian wrote:
> On Sat, Aug 4, 2012 at 10:34:14AM -0400, Bruce Momjian wrote:
> > > 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
On Sat, Aug 4, 2012 at 10:34:14AM -0400, Bruce Momjian wrote:
> > 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?
>
> There is never just one bug
On Fri, Aug 3, 2012 at 06:51:45PM -0400, Bruce Momjian wrote:
> 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
> -
>
1 - 100 of 1582 matches
Mail list logo
