that would be. We probably should at least put in
a range check so that you get a clean failure instead of a crash though.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ExecInsertIndexTuples() in execUtils.c.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
not when it's
this complicated.
http://www.postgresql.org/docs/9.1/static/bug-reporting.html
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
not.)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
than expected.
If you can declare the function STABLE then the view should continue to
work as before.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ru_RU.ISO8859-5 (with the matching encoding)
would behave sanely on OS X, if that's an acceptable fix for you.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
too helpful. But your text editor and your mailer didn't
do you any favors either, if they hid that BOM from you.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
anyway, still
less with branches that are long out of support.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
probably think.
See under The System Catalog Schema in
http://www.postgresql.org/docs/9.2/static/ddl-schemas.html
Other relevant documentation is in
http://www.postgresql.org/docs/9.2/static/typeconv-oper.html
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-22 16:11:47 -0500, Tom Lane wrote:
BTW, it sure looks to me like transformXmlExpr will get an Assert
failure on an already-transformed expression ...
Yep. I am pretty sure there are others :(
Eyeball inspection doesn't find any: either
an Assert
failure on an already-transformed expression ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
this to pgsql-jdbc list. FWIW, guys, the backend currently
thinks that execution counts are unsigned ints. So I surmise that the
problematic update count was actually between 2^31 and 2^32. We might
get around to changing it to unsigned long someday ...
regards, tom lane
--
Sent
widen the value from int to
long on the Java side, that should be sufficient.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
versions.) Pending such a fix, you might be able to make
more space available for COPY workspace by reducing shared_buffers and
other settings that control consumption of shared memory space.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
not see a problem with this example on 9.1.7. Can you
extract a self-contained example that does fail with 9.1.7?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
to write the
script in this style, put all the DROPs first and then create the
operators.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
I wrote:
I believe we've looked at this in the past, and not found any cure
that wasn't worse than the disease.
BTW, the previous discussion that I was vaguely remembering is here:
http://archives.postgresql.org/pgsql-hackers/2010-09/msg02035.php
regards, tom lane
planner bugs fixed in between.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
with a filter condition)
and (2) for some reason the repeated updates are adding, not replacing,
entries for the table in these columns.
If that's the story it would be easy to verify by watching the
extension's pg_extension entry as you repeatedly upgrade it.
regards, tom lane
the steps of the install
and upgrade scripts that reference this configuration table?
I can see how we might get to this if you were dropping and re-adding
the config table in each cycle, but perhaps that's not what you're doing.
regards, tom lane
--
Sent via pgsql-bugs
Jeff Davis pg...@j-davis.com writes:
On Sun, 2012-12-16 at 21:17 -0500, Tom Lane wrote:
One thing I noticed that maybe needs more work is that tablecmds.c in
general seems mighty willing to hack upon temp tables belonging to other
sessions. I added tests for that in the places where
coding.
The other case I was considering is that ALTER EXTENSION DROP should
probably remove any extconfig entry for a table that you disassociate
from the extension.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
Jeff Davis pg...@j-davis.com writes:
On Fri, 2012-12-14 at 17:56 -0500, Tom Lane wrote:
Perhaps a better idea is to not overload rd_backend to serve both
the physical name of file purpose and the is it my temp table
purpose. We could add an additional relcache field with the
three possible
for that in the places where there already were
checks on relpersistence, but I wonder whether we ought not simply
forbid all forms of ALTER on nonlocal temp rels, right up at the top.
regards, tom lane
diff --git a/src/backend/catalog/toasting.c b/src/backend/catalog/toasting.c
index
can fix this
by not allowing rd_backend to acquire a valid value unless we've begun
using the temp namespace.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
there's
a chance collision like this. Or resurrect the old rd_istemp and
rd_islocaltemp flags.
Thoughts?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
RPMs.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Jeff Davis pg...@j-davis.com writes:
On Mon, 2012-12-10 at 21:19 -0500, Tom Lane wrote:
I hadn't gone any further than to code and test the functions I listed.
If you are working on a complete patch, please press on.
Attached. This fixes my test case[1] and uses the functions that you
wrote
Jeff Davis pg...@j-davis.com writes:
On Sun, 2012-12-09 at 17:45 -0500, Tom Lane wrote:
Alternatively, maybe we should hack my_log2 to do that bounding.
As-is, it seems like trouble waiting to happen. This won't protect
init_htab, which needs the shift result to fit in int not long
/ 2)
num = INT_MAX / 2;
return 1 my_log2(num);
}
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Jeff Davis pg...@j-davis.com writes:
On Mon, 2012-12-10 at 20:27 -0500, Tom Lane wrote:
That does seem like a good idea. We need one for an int-sized result
too, to fix the original problem in init_htab. So I propose these
functions:
Looks good to me. One other corner case in the version
, the role's
ownership of the database is silently ignored, which I think was the
design intention. I doubt that we want DROP OWNED dropping whole
databases. At most maybe we should raise a NOTICE?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
, maybe we should hack my_log2 to do that bounding.
As-is, it seems like trouble waiting to happen. This won't protect
init_htab, which needs the shift result to fit in int not long.
But my_log2 is just plain broken for inputs larger than LONG_MAX/2,
anyway.
regards, tom lane
it on the pgadmin mailing list. pgsql-bugs generally
just deals with bugs in the core Postgres distribution.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
the ability to apply patches locally, please apply that one and
keep testing. If not, I'd recommend staying away from datatype
privileges until 9.2.3 is out ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-05 19:06:55 +0900, Tatsuo Ishii wrote:
So what status are we on? Are we going to release 9.2.2 as it is?
Or withdraw current 9.2.2?
Releasing as-is sounds good. As Tom wrote upthread:
On 2012-12-04 21:27:34 -0500, Tom Lane wrote
that's unrelated to
pausing. If you think all these changes are in fact necessary, could
you break it down a little more?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
, shouldn't the code re-evaluate
recoveryStopsHere() after that?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
before we are consistent:
I agree. Silently ignoring the user's specification is not good.
(I'm not totally sure about ignoring the pause spec, either, but
there is no good reason to change the established behavior for
the recovery target spec.)
regards, tom lane
--
Sent
;
but it seems to me to have mighty limited usefulness, considering the
speed of WAL replay versus human reaction time.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
things up for too little benefit.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Simon Riggs si...@2ndquadrant.com writes:
On 5 December 2012 18:48, Tom Lane t...@sss.pgh.pa.us wrote:
On further thought, it seems like recovery_pause_at_target is rather
misdesigned anyway, and taking recovery target parameters from
recovery.conf is an obsolete API that was designed
Simon Riggs si...@2ndquadrant.com writes:
Yep, thats fine.
Are you doing this or do you want me to? Don't mind either way.
I've got a patch for most of it already, so happy to do it.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 5, 2012 at 4:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The argument for this is that although we might fetch a slightly stale
value of the shared variable, it can't be very stale --- certainly no
older than the spinlock acquisition near
Andres Freund and...@anarazel.de writes:
On 2012-12-05 16:15:38 -0500, Tom Lane wrote:
That's fine, but the immediate question is what are we doing to fix
the back branches. I think everyone is clear that we should be testing
LocalHotStandbyActive rather than precursor conditions to see
like that since the pause feature was created, and
we've not heard complaints (which TBH makes me wonder how much use the
feature has actually seen). I'm hesitant to change the semantics in the
back branches more than necessary to avoid clear-showstopper cases.
regards, tom
thoughts? Also, I am still not seeing what the connection
is to the original report against 9.1.6.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
we now have to consider whether to withdraw
9.2.2 and issue a hasty 9.2.3. Do we have a regression here since
9.2.1, and if so how bad is it?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
.
regards, tom lane
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 50e2b22..593dcee 100644
*** a/src/backend/access/transam/xlog.c
--- b/src/backend/access/transam/xlog.c
*** recoveryStopsHere(XLogRecord *record, bo
*** 5923,5928
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-04 21:27:34 -0500, Tom Lane wrote:
So the upshot is that I propose a patch more like the attached.
Without having run anything so far it looks good to me.
BTW, while on the theme of the pause feature being several bricks shy of
a load
. Something
just wrong. Some statements are broken.
This is going to be the fault of your terminal program, not psql.
psql doesn't even know that you're pasting something rather than just
typing it manually.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql
.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Simon Riggs si...@2ndquadrant.com writes:
On 2 December 2012 15:25, Tom Lane t...@sss.pgh.pa.us wrote:
This coding was ill-considered from the word go.
Agreed, but then I don't have a clear reason why it is that way and
yet I'm sure I did it for some reason.
I think you just did it because
Simon Riggs si...@2ndquadrant.com writes:
On 2 December 2012 16:44, Tom Lane t...@sss.pgh.pa.us wrote:
As far as the concern about new bugs is concerned: if we start replay
from this checkpoint, we will certainly not consider that the DB is
consistent until we reach the checkpoint's physical
Jeff Janes jeff.ja...@gmail.com writes:
On Sat, Dec 1, 2012 at 1:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm confused. Are you now saying that this problem only exists in
9.1.x? I tested current HEAD because you indicated the problem was
still there.
No, I'm saying the problem exists
the control file into the extension
subdirectory which hasn't been made by installdirs. But that seems not
connected to VPATH builds.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Jeff Janes jeff.ja...@gmail.com writes:
On Wed, Nov 28, 2012 at 7:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Is this related at all to the problem discussed over at
http://archives.postgresql.org/pgsql-general/2012-11/msg00709.php
? The conclusion-so-far in that thread seems
=?iso-8859-15?q?C=E9dric_Villemain?= ced...@2ndquadrant.com writes:
Le samedi 1 décembre 2012 18:44:12, Tom Lane a écrit :
[ scratches head ... ] What's this have to do with VPATH?
I see the point that if EXTENSION is set, and a nondefault MODULEDIR is
selected, the install target puts
Jeff Janes jeff.ja...@gmail.com writes:
On Sat, Dec 1, 2012 at 12:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com writes:
In the newly fixed 9_2_STABLE, that problem still shows up the same as
it does in 9.1.6.
I tried to reproduce this as per your directions
, it'll probably cause them in the future.
So barring objections, I'm going to remove LogStandbySnapshot's behavior
of returning the updated nextXid.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
verbose already.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
, but one is not getting thrown.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
, CSV mode seems a bit
broken in any case; there's no concept of a terminator in CSV, AFAIK.
So maybe we don't have to worry about that.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
) INHERITS (test);
NOTICE: merging column id with inherited definition
CREATE TABLE
test=# explain analyze select distinct min(id) from test;
ERROR: failed to re-find MinMaxAggInfo record
Fixed, thanks for the report.
regards, tom lane
--
Sent via pgsql-bugs mailing list
structures onto catalog rows.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 23.11.2012 17:53, Tom Lane wrote:
We could avoid this problem if we were prepared to make type name
be varlena, ...
It would actually be nice to do that because it would *reduce* the
amount of space and memory used for the catalogs
is okay: it transitions to
PM_WAIT_READONLY state, and then PostmasterStateMachine issues SIGTERM
to the startup process and goes to PM_WAIT_BACKENDS state. Perhaps this
could be done more clearly but I'm disinclined to mess with it.
regards, tom lane
--
Sent via pgsql
that the
application is waiting for a response from the server. If there's
a bug there, you'd need to provide more or different information to
prove it. I think more likely you need to be consulting
http://wiki.postgresql.org/wiki/Slow_Query_Questions
regards, tom lane
--
Sent via pgsql
.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
:-()
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
.
regards, tom lane
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index b223feefbab0645667449f643c6c8adee3747ef0..6f93d93fa3f7577fb9157f0bea805c427e3605dd 100644
*** a/src/backend/postmaster/postmaster.c
--- b/src/backend/postmaster
is it's been done already. Try the archives.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
for the report and fix!
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
details about how to reproduce this.
I speculate it might have something to do with the specific
restore_command you're using.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Igor igorya.inscrip...@gmail.com writes:
2012/11/18 Tom Lane t...@sss.pgh.pa.us
I was just about to ask what you have log_rotation_age set to ...
Was:
log_rotation_age = 30d
That's the problem then. Internally that gets converted to
milliseconds, which'll overflow at 24-something days. Use
.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Andres Freund and...@2ndquadrant.com writes:
On 2012-11-18 12:44:55 -0500, Tom Lane wrote:
I'm inclined to propose limiting both of these to the equivalent of 15
days. Alternatively we could try to rejigger things to prevent asking
WaitLatch to wait for more than 2^31 msec, but it's not real
Andres Freund and...@2ndquadrant.com writes:
On 2012-11-18 13:18:42 -0500, Tom Lane wrote:
Well, we have two reports of people trying such values (assuming that
#7545 actually is the same thing), and it didn't work for either of
them. I don't think it's a problem to restrict the value
. on Linux i386 vs. Linux amd64?
sizeof(int) is most definitely 4 on all platforms that we support.
I've lost count of how many places would fall over if that weren't the
case, but for sure the tuple packing code would have problems.
regards, tom lane
--
Sent via pgsql-bugs
Andres Freund and...@2ndquadrant.com writes:
On 2012-11-18 14:07:37 -0500, Tom Lane wrote:
Anyway, even if Linux for some reason doesn't reject negative values,
I think we need to limit the GUC's range so we don't try to use them.
Maybe you'd get sane behavior and maybe you wouldn't. I notice
excited about changing the behavior here. I think
we're more likely to annoy users than accomplish anything useful.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
this.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
. It was a concatenation of tables
in the query.
Just to be clear here ... does this ORM expect that it can concatenate
*any* two legal identifiers into another one? If so, it's going to be
broken no matter what the specific length limit is.
regards, tom lane
--
Sent via pgsql-bugs
from a user's
standpoint for different sub-parts of a program to be operating in
different locales. Even if I agreed with the concept, your idea of
switching locale constantly is likely to be horrid from a performance
standpoint.
regards, tom lane
--
Sent via pgsql-bugs
rules are defined to work. You might have better luck
with a BEFORE INSERT trigger.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
way.Can libpq and ecpglib do it for users?
No, it would most certainly be inappropriate for a library to do that.
setlocale could completely break a program that wasn't expecting it.
The effects would be global across the whole process, not confined to
the library.
regards, tom
to correspond to any real-world use case
(the original query is surely a mistake no?).
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
got search_path set to? Try
\dt *.test
to see if there's more than one table named test.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
of its column.
There is no such restriction in the SQL standard.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
if the type can't be resolved from fairly-local context.
(The same applies to NULL, btw.)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Bernhard Reutner-Fischer rep.dot@gmail.com writes:
Fair enough but what about the failure for the case with the Result
that fails to merge? There I do have a cast
No you don't:
select * from (select 'string two' bug ) s2
regards, tom lane
--
Sent via
data structure, so the DropStmt is
corrupted for next time. Will fix, thanks for the report!
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
to install training wheels, that doesn't seem sufficient.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Thomas Eckestad thomas.eckes...@gmail.com writes:
2012/11/1 Tom Lane t...@sss.pgh.pa.us
That is extremely peculiar --- AFAICS, 9.1 should never assign a
relfilenode of 12693.
I am afraid that I can not guarantee that the example that I posted
(global/12693) was triggered with version 9.1.6
these tests?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
anything and still maintain the expectation of a
single transaction.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
201 - 300 of 6572 matches
Mail list logo
