Thanks !
Jeff.
Michael Fuhr wrote:
On Tue, Oct 04, 2005 at 08:29:23PM +0100, Jeff MacDonald wrote:
I did a backup from 7.3.2 using pg_dumpall.
When I did a restore all of my timestamps that were defaulted to now(); were
now defaulted to the time that I piped my dump back into postgres
The following bug has been logged online:
Bug reference: 1985
Logged by: Jeff Tong
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1beta3
Operating system: Windows XP
Description:cannot insert Chinese character into a table encoded
with UTF8
Details:
I am a
:
http://www.tong.cc/pgsql8.1beta3_2.png
Tell me more if I can help.
Jeff Tong wrote:
The following bug has been logged online:
Bug reference: 1985
Logged by: Jeff Tong
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1beta3
Operating system: Windows XP
Description
The following bug has been logged online:
Bug reference: 2047
Logged by: Jeff Challender
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: Windows XP
Description:Can't get to mirrors
Details:
Would like to download 8.1 can't acc
The following bug has been logged online:
Bug reference: 5535
Logged by: Jeff Benjamin
Email address: j...@ivertex.com
PostgreSQL version: 8.3.8
Operating system: MacOSX, Linux
Description:Backslash in condition for LIKE statement is not seen
Details:
Seems one
Thanks, that works!
On Jul 1, 2010, at 1:34 PM, Kevin Grittner wrote:
> "Jeff Benjamin" wrote:
>
>> Seems one cannot use a backslash character in a LIKE condition.
>
> By default that has special meaning as an escape character.
>
> Try this:
>
> sel
_data call
PageInit() if it's a new page. Are there other areas where a similar
problem might exist?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Thu, 2010-07-22 at 23:50 -0700, Jeff Davis wrote:
> I think the simple fix would be to have copy_relation_data call
> PageInit() if it's a new page.
On second thought, why are PageSetLSN and PageSetTLI being called from
log_newpage(), anyway? It says that all of the callers use sm
On Thu, 2010-07-22 at 23:50 -0700, Jeff Davis wrote:
> I was investigating some strange page corruption today in which the page
> was completely zeroed except for the LSN and TLI.
>
I see that this was added to the 9.0 open items list, but it affects
versions 8.3 and later.
I sh
g-point value, and then reload it, it may be
different than the one you started with. That can cause a problem with
either UNIQUE or EXCLUDE constraints.
If you are not using floating point values, please try to make a
self-contained test case that includes data that can reproduce the
problem.
R
t4)) =
(1::numeric + 1e-7::numeric)::float4;
?column?
--
f
(1 row)
> My own WAG is that we're talking about a GiST bug that causes it to
> recognize or not recognize duplicates depending on order of insertion.
> But that's theorizing far in advance of the data.
Seems
On Mon, 2010-08-30 at 20:06 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > On Mon, 2010-08-30 at 19:40 -0400, Tom Lane wrote:
> >> That's really *not* supposed to happen, assuming that both machines have
> >> IEEE float arithmetic and competently written float
On Tue, 2010-08-31 at 14:13 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > On Mon, 2010-08-30 at 20:06 -0400, Tom Lane wrote:
> >> You need extra_float_digits cranked up. Which pg_dump knows about.
>
> > I can't reproduce the problem with float4/8, but I still
a feature
to make the optimizer smarter.
The optimizer will never be so good that it always picks the best path.
Consider a 100-table join: would it be a "bug" if it didn't find the
perfect join order?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@pos
can't be planned this way, there are particular properties of MAX that
allow the optimization:
1. MAX(x) can be rewritten as: ORDER BY x DESC LIMIT 1
2. The MAX of set S is the MAX of the MAXes of each partition of S
The optimizer knows about the former, but not the latter.
Regards,
On Fri, 2010-09-10 at 16:53 -0400, Mladen Gogala wrote:
> Jeff, that's the problem. Functions like "MAX" are rather ordinary and
> frequently used.
I agree that it could be improved. The best way to move such improvement
forward is to advance the discussion on -hackers. S
ecause I wasn't sure if it's safe to do that
before DisableCatchupInterrupt().
Regards,
Jeff Davis
[1] http://www.mail-archive.com/pgsql-bugs@postgresql.org/msg00225.html
Note: I couldn't even find that in our email archive, but thanks to our
new git repo, I
nestly, and openly; even though it seemed like the
most trivial bug that I could imagine at the time.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
x is ROW(1,NULL),
then the former will evaluate to TRUE, and the latter will evaluate to
FALSE. Enjoy."
=> select ROW(1, NULL) IS NOT NULL;
?column?
--
f
(1 row)
=> select NOT ROW(1, NULL) IS NULL;
?column?
--
t
(1 row)
Regards,
Jeff Davis
--
nt and prior checkpoint are the same, and
redo is before both), a crash, a PANIC, a backup_label.old, and not much
else.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Fri, 2010-10-15 at 15:58 -0700, Jeff Davis wrote:
> I don't have a fix yet, because I think it requires a little discussion.
> For instance, it seems to be dangerous to assume that we're starting up
> from a backup with access to the archive when it might have been a cra
> simpler than your proposed patch (i.e., check whether REDO location exists).
>
Either is fine with me.
Do users have any expectation that they can restore a backup without
using recovery.conf by merely having the WAL segments in pg_xlog?
Regards,
Jeff Davis
--
Sent via pgsql-bu
On Mon, 2010-10-18 at 17:51 -0400, Robert Haas wrote:
> On Mon, Oct 18, 2010 at 2:07 PM, Jeff Davis wrote:
> > On Mon, 2010-10-18 at 17:02 +0900, Fujii Masao wrote:
> >> Yep, to automatically delete backup_label and continue recovery seems to be
> >> dangerous. How abou
y entry and then silently ignores the fact that it
couldn't copy the contents. Another concern is: what if they are using
some kind of filesystem mirroring tool that doesn't take consistent
snapshots (do such tools exist?)? Are there other system-level tools
that people might be using th
On Tue, 2010-10-19 at 09:51 -0700, Jeff Davis wrote:
> On Tue, 2010-10-19 at 12:26 +0300, Heikki Linnakangas wrote:
> > Excluding pg_xlog is just a recommendation at the moment, though, so we
> > would need a big warning in the docs. And some way to enforce that
> > just_ki
kpoint. I haven't tested your
patch yet, but it looks like some of the following code depends on
ReadRecord(NULL,...) fetching the record right after the checkpoint
record; so I think something else is required if you want to use
ReadRecord.
Regards,
Jeff Davis
--
Sent via p
inology issue, however).
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
istent to raise syntax errors in all these
> cases.
I don't really see a "bug" here. Is this causing you some kind of
problem?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 5746
Logged by: Jeff Mace
Email address: jeff.m...@continuent.com
PostgreSQL version: 9.0.1
Operating system: CentOS
Description:/etc/init.d/postgresql-9.0 status returns the wrong
value
Details:
The
he backup, and you'll get a PANIC.
This seems like a pretty serious issue to me (backups could appear
unrecoverable), so please consider this before the next patch-level
release so that the bad fix doesn't go out to the world. Also, you might
want to double-check that there ar
On Thu, 2010-11-11 at 18:20 +0200, Heikki Linnakangas wrote:
> On 11.11.2010 02:20, Jeff Davis wrote:
> > There is a problem with this patch. ReadRecord() not only modifies
> > global variables, it also modifies the location pointed to by "record",
> > which is later
y "reset", I do not mean "overflow". I mean that the
sequence might have been recreated somehow.
Try to provide more detail in your bug report. See:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (p
broot.glob->paramlist, and uses it in
subsequent iterations; but that isn't copied before the context is
reset. It looks like there are other things that need copying as well,
but it wasn't immediately clear to me what the best fix is.
Regards,
Jeff Davis
begin;
create table
The following bug has been logged online:
Bug reference: 5841
Logged by: Jeff Turner
Email address: j...@biccard.com
PostgreSQL version: 9.0.1
Operating system: Ubuntu 10.10
Description:rank()+1 fails, 1+rank() succeeds
Details:
Given a table:
create table t (foo
mining which files should be removed at recovery time is
challenging?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
s worth the
bookkeeping effort though.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
stall yesterday, but in a ridiculously stupid brain
lapse, I didn't document it.
I'm nor trying to recreate the postgresql-9.0.2 install from scratch and get
stuck here.
Help?
Respectfully,
Jeff.
Jeff Hamann, PhD
PO Box 1421
Corvallis, Oregon 97339-1421
541-754-2457
jeff.haman
The following bug has been logged online:
Bug reference: 5974
Logged by: Jeff Wu
Email address: j...@atlassian.com
PostgreSQL version: 9.0
Operating system: Mac OS X
Description:UNION construct type cast gives poor error message
Details:
The UNION construct (as
>
> If the implementation details for the other databases are that hard
> to discern, how much do we care *how* they do it? It seems to me
> that the important point here is that they don't throw an error on
> that query and we do.
>
> What am I missing?
>
> -Kevin
>
--
Jeff Wu
Marketing Quant, Atlassian
(714) 319-7604
The following bug has been logged online:
Bug reference: 6068
Logged by: Jeff Janes
Email address: jeff.ja...@gmail.com
PostgreSQL version: 9.1beta1
Operating system: Linux
Description:automatic analyze runs endlessly
Details:
Starting with commit
On Sat, 2011-06-18 at 13:20 -0700, Jeff Davis wrote:
> Interesting problem... the bug is in get_op_btree_interpretation() which
> has code like this:
>
> /*
>
>* If we can&#
On 6/19/11, Tom Lane wrote:
> "Jeff Janes" writes:
>> Starting with commit b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8,
>> "Fix VACUUM so that it always updates pg_class.reltuples/relpages."
>
>> After running make installcheck, the
ll.
PostgreSQL is a SQL DBMS, and in SQL, NULL affects everything. I'm sure
there are places in the documentation that could be improved, but
warnings on every page would be counterproductive.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
http://archives.postgresql.org/pgsql-bugs/2011-06/msg00167.php
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
pclasses.
I suppose this is another argument for type interfaces.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Sat, 2011-07-02 at 18:38 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > On Sat, 2011-06-18 at 13:20 -0700, Jeff Davis wrote:
> >> Interesting problem... the bug is in get_op_btree_interpretation() which
> >> has code like this:
> >> ...
> >> How
The following bug has been logged online:
Bug reference: 6092
Logged by: Jeff Frost
Email address: j...@pgexperts.com
PostgreSQL version: 9.0.4
Operating system: CentOS 5.5
Description:specific casting required for gist indexing of bigint
Details:
Ran into a
e complex, and I
don't think we have a lot of test coverage in this area (and I didn't
see an easy way to add many tests), so this will need some review.
Regards,
Jeff Davis
rowcmp2.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-bugs mailing list (pgsql-bugs
On 07/05/11 17:06, Tom Lane wrote:
> "Jeff Frost" writes:
>> Ran into a situation with a customer who is using the btree_gist contrib
>> module to allow combined index of some tsearch data and two other columns.
>> One of these other columns is a bigint fiel
terpretation() so it can return amoplefttype
> and amoprighttype too, but given the small number of callers, an API
> change for it doesn't seem like a problem.
Sounds good to me.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
In branch postgresql/master:
SELECT SUM(SUM(a)) OVER ()
FROM (SELECT NULL::int4 AS a WHERE FALSE) R;
ERROR: XX000: cannot extract attribute from empty tuple slot
Honestly, I'm not sure what the semantics of that are supposed to be. Is
it even allowed by the standard?
Regards,
row. That seems pretty
> useless, so I'm thinking it's not worth back-patching a fix for.
> Comments?
Agreed. I'm not worried about backpatching it.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your s
e of those results is correct?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
a bug", though it appears to work in 8.3.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
t operation. When you execute the query, it displays the date
> constant using the now-current datestyle.
Another thought: why does it execute the type input function (which is
dependent on a GUC), but not the cast?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgr
key item to
sort"), but it's fixed sometime later in the 9.1 series.
If you get rid of the CASE statement, then it still fails in 8.4 and
9.0, but it succeeds in 9.1.0 and beyond.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To ma
On Thu, 2012-01-26 at 20:43 -0500, Tom Lane wrote:
> Jeff Davis writes:
> > => select ntile(3) OVER ( ORDER BY CASE WHEN count(i) = 0 THEN NULL ELSE
> > count(i) END asc ) from ( SELECT NULL::integer as i limit 0 ) s ;
> > ERROR: cannot extract attribute from empty tuple
rely we don't want it to be set from the environment, right?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Sun, 2012-03-11 at 11:20 -0700, Jeff Davis wrote:
> The problem seems to be in check_locale(), which just checks for a
> non-NULL return value from setlocale(). However, the manual for
> setlocale() says:
>
> If locale is "", each part of the locale that shou
On Sat, 2012-03-24 at 19:07 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > Surely we don't want it to be set from the environment, right?
>
> Why not?
I agree that we shouldn't change the documented behavior of those GUCs.
But a SQL command like CREATE DATABASE be
$ cat /tmp/a.copy
1
\0
COPY TO seems to follow the documentation, inserting the null string
without modification into the output file. COPY FROM seems to de-escape
the input before trying to match it against the null string, leading to
the invalid byte sequence.
standard_conforming_strings is o
A few times today, we've seen postgresql 9.1.3 backends on Ubuntu 11.10 x86_64
get stuck in 'startup' mode. By that I mean the set_ps_output mode. Postgres
is installed via Martin Pitt's packages.
It manifests like this:
Server has been humming along fine, then suddenly many backends get stuck i
On 04/27/12 09:07, Jeff Frost wrote:
> A few times today, we've seen postgresql 9.1.3 backends on Ubuntu 11.10 x86_64
> get stuck in 'startup' mode. By that I mean the set_ps_output mode. Postgres
> is installed via Martin Pitt's packages.
quick followup on this..whe
On 04/27/12 10:14, Tom Lane wrote:
> Jeff Frost writes:
>> A few times today, we've seen postgresql 9.1.3 backends on Ubuntu 11.10
>> x86_64
>> get stuck in 'startup' mode.
> Well, the one you backtraced seems to be waiting for somebody else to
> release
On 04/27/12 11:54, Jeff Frost wrote:
> On 04/27/12 10:14, Tom Lane wrote:
>> Jeff Frost writes:
>>> A few times today, we've seen postgresql 9.1.3 backends on Ubuntu 11.10
>>> x86_64
>>> get stuck in 'startup' mode.
>> Well, the on
On 04/27/12 12:17, Tom Lane wrote:
> Jeff Frost writes:
>> Alright, found one that's a little different (at least it wasn't in
>> InitPostgres):
> It's still blocking at bufmgr.c:531 though ... so AFAICS this is another
> victim of somebody monopolizing a buff
On 04/27/12 12:27, Tom Lane wrote:
> Jeff Frost writes:
>> Any idea what I should be looking for in the backtraces?
>> I would imagine I can ignore any that are in InitPostgres, but that still
>> leaves quite a few to look through.
> I think you can probably skip
> I think you can probably skip all that are blocked in LWLockAcquire
> called from bufmgr.c:531, at least for a first pass. Calls from
> elsewhere in bufmgr.c might be more interesting, and anything that's not
> blocked at an LWLockAcquire at all might be even more interesting.
A few more that i
resql-9.1-9.1.3/build/../src/backend/postmaster/postmaster.c:1116
#23 0x7f62b8102ec3 in main (argc=5, argv=0x7f62b9471170) at
/build/buildd/postgresql-9.1-9.1.3/build/../src/backend/main/main.c:199
--
Jeff Frost
CTO, PostgreSQL Experts, Inc.
Phone: 1-888-PG-EXPRT x506
FAX: 415-762-5122
http://
On 04/27/12 17:30, Tom Lane wrote:
> Jeff Frost writes:
>> and I've got 81 more that do not contain bufmgr.c and are also not block on
>> LWLockAcquire.
> Hm ... no smoking gun in what you showed so far. I also took another
> look through 9.1 bufmgr.c, and I'm da
On 04/27/12 17:45, Jeff Frost wrote:
> Oh, good idea! Looks like pg_buffercache is installed in this DB. Customer
> reports that it has been installed since the server has existed (and on the
> previous server) but is not currently being used, though the issue with the
> hanging star
we just saw the issue recur with pg_buffercache uninstalled. :-/
--
Jeff Frost
CTO, PostgreSQL Experts, Inc.
Phone: 1-888-PG-EXPRT x506
FAX: 415-762-5122
http://www.pgexperts.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 04/27/12 18:27, Jeff Frost wrote:
> To make it more interesting, today is a
> slow day.
And since it's a slow day..one more question..any further logging we could do
to help find the culprit?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your s
On Apr 27, 2012, at 6:34 PM, Jeff Frost wrote:
> On 04/27/12 18:27, Jeff Frost wrote:
>> To make it more interesting, today is a
>> slow day.
>
> And since it's a slow day..one more question..any further logging we could do
> to help find the culprit?
FYI, re
On Apr 27, 2012, at 6:15 PM, Tom Lane wrote:
> Jeff Frost writes:
>> Oh, good idea! Looks like pg_buffercache is installed in this DB. Customer
>> reports that it has been installed since the server has existed (and on the
>> previous server) but is not currently being u
On 04/28/12 17:17, Jeff Frost wrote:
> Since I had a theory that it's probably stalling on pg_catalog access, one of
> the guys wrote a test harness that makes several connections and creates and
> drops lots of temp tables. That does seem to allow us to reproduce the issue
>
On 05/24/12 12:21, Tom Lane wrote:
> Jeff Frost writes:
>> A few times today, we've seen postgresql 9.1.3 backends on Ubuntu 11.10
>> x86_64
>> get stuck in 'startup' mode. By that I mean the set_ps_output mode. Postgres
>> is installed via Martin Pitt
On May 24, 2012, at 3:13 PM, Tom Lane wrote:
> Jeff Frost writes:
>> On 05/24/12 12:21, Tom Lane wrote:
>
> Huh. A bit bigger, but not by that much. It doesn't seem like this
> would be enough to make seqscan performance fall off a cliff, as it
> apparently did.
On May 24, 2012, at 3:35 PM, Tom Lane wrote:
> Jeff Frost writes:
>> On May 24, 2012, at 3:13 PM, Tom Lane wrote:
>>> Huh. A bit bigger, but not by that much. It doesn't seem like this
>>> would be enough to make seqscan performance fall off a cliff, as it
&
idea:
http://thoughts.davisjeff.com/2009/08/02/what-is-the-deal-with-nulls/
Jose was not wrong about the inconsistency between UNIQUE and GROUP BY.
But the answer is that "we do it that way because the standard says so".
And that's a good reason.
Regards,
Jeff Davis
--
Sent via pgsq
On Jun 22, 2012, at 7:37 PM, Tom Lane wrote:
> j...@pgexperts.com writes:
>> DROP and CREATE extension appear to work fine, but if you ALTER EXTENSION
>> postgis SET SCHEMA foo, it leaves a few relations behind.
>
> What it seems to be leaving behind is indexes ... also relation rowtypes.
>
> A
If you'd like private, personalized support, it is available from these
companies:
http://www.postgresql.org/support/professional_support/
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
context is passed to
hash_create(), and no hash_destroy() is called. Unless I'm missing
something, that's a leak in TopMemoryContext.
Regards,
Jeff Davis
#0 0x004683a2 in extractRelOptions (tuple=0x11cd528,
tupdesc=0x7fc9e499b420, amoptions=0) at reloptions.c
constraint, null values are not considered
equal."
-- http://www.postgresql.org/docs/9.2/static/sql-createtable.html
NULLs can be confusing, I know.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your su
ed 8.1.4, rpm'd 9.1.5 (server, devel, contrib, libs)
STILL getting the blasted error !!
so whats the fix ???
or do I need to just delete, forget and reuse MySQL ???
--
-Jeff Lake
MichiganWxSystem.com
AllisonHouse.com
TheWeatherCenter.net
GRLevelXStuff.com
--
Sent via pgsql-bug
t say to you???
PostgreSQL is the failing point !!
9.1.5
8.1.23
8.4
all give the same EXACT Error ...
oh yes .. libpq.so.5 is in the ldd for pgsql.so
-Jeff Lake
MichiganWxSystem.com
AllisonHouse.com
TheWeatherCenter.net
GRLevelXStuff.com
On 8/30/2012 16:09, Peter Geoghegan wrote:
On 30 August
ce set.
One of the consequences is that you can get buffers with the wrong flags
set; in particular, missing BM_PERMANENT, which seems like it could be a
serious problem.
Are there other areas where we might have similar problems?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing l
ec6df9d4, because that bug was hiding
this one.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Thu, 2012-09-13 at 12:39 -0400, Robert Haas wrote:
> On Wed, Sep 12, 2012 at 7:19 PM, Jeff Davis wrote:
> > This bug seems particularly troublesome because the right fix would be
> > to include the relpersistence in the WAL records that need it. But that
> > can&#
predicate. In order to
do that, you need to use an exclusion constraint:
http://www.postgresql.org/docs/9.2/static/sql-createtable.html#SQL-CREATETABLE-EXCLUDE
To make it equivalent to UNIQUE, set all operators to "=", e.g.:
CREATE TABLE xyz(i int, exclude (i WITH =) where (i > 10) defer
191Gb ?? wow .. what do you have in there ??
PostGreSQL .. is another database system
-Jeff Lake
MichiganWxSystem.com
AllisonHouse.com
TheWeatherCenter.net
GRLevelXStuff.com
On 11/2/2012 13:22, gryphons...@gmail.com wrote:
The following bug has been logged on the website:
Bug reference
th
> failure.
Or a lack of failure, I presume.
> This is reading from a 9.0.8 Postgres.
Any indication whether it's present on other versions or does it appear
to be isolated to 9.0.X?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To m
ainly not rely on an IMMUTABLE function to be called a
specific number of times.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
7 09:49:17.932 PST LOG: startup process (PID 22110)
exited with exit code 1
22109 2012-11-27 09:49:17.932 PST LOG: terminating any other active
server processes
Cheers,
Jeff
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
een replayed. In 9.2.0 and 9.2.1, it
instead opened for read only connections at the point that the
end-of-checkpoint record (the checkpoint associated with the
pg_start_backup) has replayed, which I think is too early.
Cheers,
Jeff
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
er the end of the
pg_start_backup checkpoint, rather than just before it, and turn on
hot_standby
Cheers,
Jeff
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
own the table?
My guess is that it's to prevent someone from dropping a trigger created
by someone else.
I agree that it's inconsistent. I'm not sure why they added the separate
"TRIGGER" privilege in the first place, but it was done more than 10
years ago.
Regards
ink of (aside from
dropping the separate TRIGGER privilege) is to track the owner of the
trigger separately from the owner of the table, but that would be
strange, too.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscr
On Sat, Dec 1, 2012 at 12:47 PM, Tom Lane wrote:
> Jeff Janes writes:
>> On Wed, Nov 28, 2012 at 7:51 AM, Tom Lane wrote:
>>> Is this related at all to the problem discussed over at
>>> http://archives.postgresql.org/pgsql-general/2012-11/msg00709.php
>>> ?
On Sat, Dec 1, 2012 at 1:56 PM, Tom Lane wrote:
> Jeff Janes writes:
>> On Sat, Dec 1, 2012 at 12:47 PM, Tom Lane wrote:
>>> Jeff Janes writes:
>>>> In the newly fixed 9_2_STABLE, that problem still shows up the same as
>>>> it does in 9.1.6.
&
101 - 200 of 255 matches
Mail list logo
