& 255::int8) || ''.'' ||
(($1>>16) & 255::int8) || ''.'' ||
(($1>>8) & 255::int8) || ''.'' ||
($1 & 255::int8) as result
'
LANGUAGE 'SQL';
You can create the cast yourself if you want to, see CREATE CAST.
ER BY popularity" doesn't force any particular
order. This is effectively the same as if there was no ORDER BY at all;
the database is free to return the rows in any random order it wishes.
You can use ORDER BY popularity, name DESC for the order you were
expecting..
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
systems, in PostgreSQL "ORDER BY 1" means order by the
constant value "1", not the first column. Try "ORDER BY name".
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make chan
Heikki Linnakangas wrote:
Unlike on some systems, in PostgreSQL "ORDER BY 1" means order by the
constant value "1", not the first column. Try "ORDER BY name".
Oh, that's of course not correct at all. "ORDER BY 1" does indeed mean
order by f
As Tom pointed out, the order depends on the locale.
Blanco, Jose wrote:
So is there no way to make oder by work with names?
-Original Message-
From: Heikki Linnakangas [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 07, 2008 3:00 AM
To: Blanco, Jose
Cc: pgsql-bugs@postgresql.org
and
higher, 8.1 seems to work. I'll dig deeper tomorrow, unless someone else
beats me to it.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
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 wrote:
Brendan O'Shea wrote:
There appears to be a bug in the way that permissions are determined for
views that contain "UNION ALL" in their definition.
There is a simple test case to reproduce the bug.
1) As a superuser create the following object
er not possible or we don't care, because that
can happen without the patch just as well.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/optimizer/prep/prepjointree.c
===
RCS file: /home
the rest of the logic to pull up UNION ALL subqueries, in
8.2, and has been broken ever since.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
mean like pull_up_simple_subquery() does? Yeah, I can try that. This
isn't really something I'm familiar with, but it's great exercise :-).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To
Heikki Linnakangas wrote:
Tom Lane wrote:
Seriously, I think what this shows is that piecemeal pullup is wrong in
principle, and that the right approach is always to concat the
subquery's rtable in toto to the upper level, and then go from there on
adjusting varnos. Do you want to look
I didn't notice because I was testing without assertions.
Hmm, do we need the copyObject() call for non-subquery RTEs? I'm
guessing no, because they're not modified.
--
Heikki Linnakangas
EnterpriseDB http://www.ente
ut I'm
not sure they couldn't either.
Hmm. Maybe through a rewrite or something?
We should use range_table_walker, which knows how to descend into all
kinds of RTEs...
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/optimizer
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
We should use range_table_walker, which knows how to descend into all
kinds of RTEs...
Yeah, I had been thinking of that but didn't see an easy way to apply
it; of course the answer is to use Increment
[EMAIL PROTECTED] wrote:
Is there guide to compile PG?
http://www.postgresql.org/docs/8.3/interactive/install-win32.html
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
as client_encoding if you need to,
even if the server uses UTF-8.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
kely a bug. Please use the pgsql-general mailing list
next time.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
prepared transactions, aka two-phase commit, or did you mean prepared
statements?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
You can change the way a conversion is done with CREATE/DROP CONVERSION.
That's why it can't be IMMUTABLE.
(I doubt any sane person would actually do that, but that's another debate)
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mail
_BINARY 0
#define PG_BINARY_A "a"
#define PG_BINARY_R "r"
#define PG_BINARY_W "w"
#endif
I don't see anything wrong with the patch, but I wonder if there's more
open() calls that need the same treatment? Like the one in
pg_resetxlog.c/ReadControlFile().
--
k to query */
+ context->inserted_sublink = true;
+ /* fall through to copy the expr normally */
+ }
return expression_tree_mutator(node, ResolveNew_mutator,
(void *)
context);
}
--
in evince, please report to the Evince team.
It's possible that there's something wrong in the PDF that triggers that
bug in evince, but an assertion failure shouldn't nevertheless happen.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs m
FSMs when I
added the FSM vacuum code. Index FSMs need to be vacuumed just like the
heap FSM. Fixed, thanks for the report.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
ds on what language's collation rules you want to
follow. "locale -a" in a shell should list the available options.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to you
e you sure you didn't
have a long-running transaction open that prevented vacuum from working?
Did the heap bloat as well, or just the index?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make chang
anonymous wrote:
CLUSTER still does a full page scan although there are 0 dead rows on table.
That's not a bug. Keep in mind that the main purpose of CLUSTER is not
to remove dead tuples, but to reorder the rows.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
n't think so. pd_special is the offset to the start of the
special area, so (BLCKSZ - pd_special) is the size of the special area.
However, that max_avail field actually looks like dead code, anyway.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs ma
s the constant
AutoVacNumSignals is not defined correctly. It should be (AutoVacRebalance +
1).
Yeah, that's clearly a bug. Fixed, thanks.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your su
x27;2008-11-14 16:00:00','-MM-DD
HH24:MM:SS'),'day');
ERROR: conflicting values for "MM" field in formatting string
DETAIL: This value contradicts a previous setting for the same field type.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprise
experienced sudden power
loss, or operating system crash on these machines? Have you done "kill
-9 postmaster", "pg_ctl stop -m immediate", or similar? PostgreSQL
should recover with no data corruption, of course, but if there's a bug
somewhere, it would help to know wh
ave solved this, but he didn't get around to finish it for 8.4.
Maybe 8.5...
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
tgres code?
There's no named individuals, just the community in general.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
PostgreSQL error codes are not as unique as the error messages.
If you don't like translated error messages, you could just set
lc_messages to en_US in your postgresql.conf.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@po
at's wrong with bytea?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Y);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"foo_pkey" for table "foo"
CREATE TABLE
postgres=# CREATE INDEX i_foo ON foo (id);
CREATE INDEX
postgres=#
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing l
t assuming some overhead that's completely insignificant
in the big scheme of things.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
age header error also appeared under its version 8.3.1
with OS FreeBSD 7.0 :
That sounds very random. I suspect bad hardware, bad RAM perhaps. On how
many computers does the error occur?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (
d could yield unexpected results. In the context of an ISO year, the concept of a 'month' or 'day of month' has no meaning. In the context of a Gregorian year, the ISO week has no meaning. Users should take care to keep Gregorian and ISO date specifications separate.
--
Heikki
Pavel Stehule wrote:
My first patch expected so RETURN QUERY is final statement, so I don't
solve FOUND variable, but Heikki changed this behave.
Me? I don't recall doing anything related to this.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via
think that we should
also backport.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
[ Attachment, skipping... ]
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mai
ithin the
just-completed transaction log file.
If there has been no transaction log activity since the last
transaction log switch,
pg_switch_xlog does nothing and returns the *start*
location
of the transaction log file *currently in use*.
--
Heikki Linnakangas
EnterpriseDB http
Fujii Masao wrote:
On Thu, Jan 15, 2009 at 9:09 PM, Heikki Linnakangas
wrote:
1. The proposed patch would remove the "+ 1". Seems like an unnecessary API
change, and I don't recall any reason why the new definition would be
better.
My patch doesn't change the return val
nce it doesn't cause any
actual problems. We'd just risk breaking people's scripts that use
-999 to mean "no limit". (they will be broken when they upgrade to 8.4
anyway, of course, but that's fine)
--
Heikki Linnakangas
EnterpriseDB http://www.en
to...@tuxteam.de wrote:
On Mon, Jan 26, 2009 at 02:26:05PM +0200, Heikki Linnakangas wrote:
Dave Page wrote:
It's possible to set a per-database connection limit of < -1, which seems
bogus:
Yeah. That's simple to fix, but I'm having trouble wordsmithing the error
message. T
Tom Lane wrote:
Heikki Linnakangas writes:
Dave Page wrote:
It's possible to set a per-database connection limit of < -1, which seems bogus:
Yeah. That's simple to fix, but I'm having trouble wordsmithing the
error message. This is what I came up with:
Why does it n
86-redhat-linux-gnu, compiled by GCC gcc (GCC) 3.4.6
20060404 (Red Hat 3.4.6-9)
I can reproduce this on CVS HEAD too. I'll try to figure out what's
going on..
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresq
Konstantin wrote:
* Heikki Linnakangas [Thu, 12 Feb
2009 13:54:11 +0200]:
Hmm, the first UPDATE should've blocked already. It should've fired a
RI
trigger to lock the parent tuple in shared mode, but it looks like
that's not happening for some reason.
To tell the truth I e
Konstantin wrote:
* Tom Lane [Thu, 12 Feb 2009 10:54:34 -0500]:
Heikki Linnakangas writes:
> Hmm, the first UPDATE should've blocked already. It should've fired
a
RI
> trigger to lock the parent tuple in shared mode, but it looks like
> that's not happening fo
RT TRANSACTION command.
You could use -t, or add a COMMIT after the "set search_path".
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
a ?.
Or you can create a wrapper function around currval that's marked as
stable instead of volatile, to hide currval's volatility. However, that
would amount to lying to the optimizer and you might get some surprising
results with more complex queries, so I wouldn't recommend i
toruvinn wrote:
On Mon, 16 Feb 2009 10:37:27 +0100, Heikki Linnakangas
wrote:
You can read the value returned by currval into a host language
variable and send it back as a ?.
Wouldn't it be possible to do UPDATE booking_entries SET date = ? where
id = (SELECT currval('booking_entr
. I appreciate
your help.
Umm, yes: the user manual.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
errors when both server and pgAdmin 8.3.6.
On a my opinion, pgAdmin must deny vacuum/analyze on inconsistent version.
That should work just fine. What errors are you getting?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs
ries. Since you upgraded to 8.3.6,
have you restarted PostgreSQL? What does "SELECT version()" say?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.post
gly.
Thanks, committed.
But I wonder, why does plpgsql debugger even try to display those
variables after the exception block? I'm not familiar with the tool; I'm
guessing that it just displays all variables, regardless of scope.
--
Heikki Linnakangas
EnterpriseDB http://www.enterp
conversion function with a empty string, to
check that it is in fact capable of doing the conversion. See 2nd
attached patch. This is a usability improvement too, as you
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
diff --git a/src/backend/utils/error/elog.c b/src/backend/ut
dump from one encoding to
another.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Tom Lane wrote:
Heikki Linnakangas writes:
I think we should instead try to break the PANIC cycle. If we exceed
ERRORDATA_STACK_SIZE, and we're already PANICing, we should just die
immediately instead of throwing another PANIC about exceeding the stack
size. The attached patch does that
Tom Lane wrote:
Heikki Linnakangas writes:
When the conversion function doesn't work, any attempt to send any text
to the client will fail.
Ah, now I remember: we arranged to short-circuit translation of the
error message when we were in this situation. But it will still get
passed th
Tom Lane wrote:
Heikki Linnakangas writes:
Tom Lane wrote:
I wonder how ugly it would be to try to suppress encoding
conversion as well?
The error message might contain user data, which might contain non-ASCII
characters. Or maybe not, but it seems like a shaky assumption to make.
The
an insertstatement
is called after the functioncalls.
Well, others might expect the opposite, like existing applications. Want
to suggest wording for the documentation?
To get the id of the row inserted, use INSERT RETURNING. Or currval('bla2').
--
Heikki Linnakangas
Enterpris
composite type in
the records.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Tom Lane wrote:
Heikki Linnakangas writes:
Oleg wrote:
CREATE CAST (tmp_table AS composite_ad_texts)
WITHOUT FUNCTION AS ASSIGNMENT;
"WITHOUT FUNCTION" can only be used when both types are binary
compatible. You might think that two composite types with the same
fields are, b
Tom Lane wrote:
Heikki Linnakangas writes:
Tom Lane wrote:
Although this qualifies as pilot error (superusers are expected to know
what they're doing), should we attempt to prevent the case?
We can't detect binary-incompatibility in general, so I presume you
meant just for t
e database effectively
unavailable.
However, in almost all cases, there is no need for such relaxing of limits
to require a table rewrite.
While this isn't a bug, it's a reasonable feature request. I've added
this to the TODO page: http://wiki.postgresql.org/wiki/Todo#ALTER
Patches
Tom Lane wrote:
Heikki Linnakangas writes:
If we go down that path, how far do we go? We also know that two enums
are never binary-compatible, right? Composite type and a user-defined
base type? Hardly, unless you're doing something very hacky...
Disallowing binary casts when any comp
to know if the string after "@" is a
valid hostname, we can stop the recursion as soon as we find out that
it's not. The attached patch does that.
Teodor, does this look OK to you?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
diff --git a/src/backend/tsear
transaction is in process. The session and any
transactions would remain active.
See statement_timeout.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
sql;
SELECT foofunc();
Gives error:
ERROR: invalid input syntax for integer: "(1)"
CONTEXT: PL/pgSQL function "foofunc" line 6 at SQL statement
Surely assigning a value of btype to a variable of the same type should
always work..
--
Heikki Linnakangas
EnterpriseDB
syslogFile) this is
causing a race condition due to an error in the way we are using the related
critical section.
Thanks, committed. I hope this helps with Ati's problems.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
-
Sent via pgsql-bugs mailing list (pgsql
t all the other characters in the
ETEN extension?
Is there some authoritative source for the Big5 encoding, to look these
things up?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
-
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
compliant
with CP950, since few years ago.
Ok, so Windows codepage 950 has those 7 characters, but not the other
ETEN extended chars. I think that's a good enough reason to add those 7
chars; we have 'win950' as an alias for big5 anyway.
I'll go add those characters.
--
Heikki Linnakangas wrote:
張桂賢 Roger Chang wrote:
There is authoritative source for the Big5 encoding, but don't believe
that do help
http://www.cns11643.gov.tw/AIDB/encodings_en.do
Skip the historical mess already done. we should focus on reality?
brief events according time
IG5.TXT as before, with the addition of those seven extra
characters from CP950.TXT.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
-
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
n into problems with that.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ase might
also not be self-consistent, because of corrupted indexes etc.
REINDEXing the database is a good idea.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www
rrupts during COPY FROM, but we
should react to fast shutdown and query cancel.
I'm not too familiar with this code, but I think we could just enable
ImmediateInterruptOK in CopyGetData().
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mail
unction oid and args in a
fastpath function call. Using v2 protocol. That has got to be deprecated
enough to not worry about :-). Then again, it wouldn't be hard to put
set ImmediateInterruptOK there as well, for the sake of completeness.
--
Heikki Linnakangas
EnterpriseDB http://www.
> (select keyword_id /
carrier_id from carrier)
If keyword_id wasn't allowed in the subquery, it would be impossible to
write more complex queries like that.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
ngth('é')" with
"INSERT INTO foo VALUES ('é')", and check the contents of the table with
SELECT * FROM foo afterwards, you'll see that the string is garbled in
the latter case, and indeed consists of two characters.
As you noticed, server_e
art, I can see below in the
pgstartup.log
FATAL: unrecognized configuration parameter "redirect_stderr"
redirect_stderr was renamed to logging_collector in version 8.3.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bug
ere renamed to LC_COLLATE and LC_CTYPE a
few days before packaging beta1. If there's still mentions of
COLLATE/CTYPE somewhere in the docs, please let me know.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.or
lany wrote:
$ createdb spectra
Ok
FATAL: database "spectra" does not exist
Without more details, no idea. createdb shouldn't print "Ok", and it's
not shown what command printed the error.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
ows.
Can you provide a self-contained test case? Including the table
definition for the table, the full query, results on both versions, and
if possible, the data. If you can reproduce it with a smaller table,
that's even better.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.
o reproduce this. Is it possible that the history file went
missing in the process? That's needed to recover WAL files from
timelines other than the latest one. You should only get that
"unexpected timeline ID" message if the history file doesn't contain a
line for tha
ion is being done at execution time? (hmm ...
this is what a one-time filter is, now that I think about it?)
Note that the function is immutable, and the argument in the query is a
constant. The planner simply runs the function and replaces the function
call with the result.
--
Heikki Linnak
Mikael Krantz wrote:
On Wed, May 6, 2009 at 6:26 PM, Heikki Linnakangas
wrote:
How to reproduce:
* restore from backup
* SELECT pg_start_backup('label');
* take a new backup
* SELECT pg_stop_backup();
* copy the relevant WAL-files
* try to restore the backup
I failed to repr
quired more invasive
changes which don't seem worth the effort.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
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 wrote:
On Thu, 2009-05-07 at 12:15 +0300, Heikki Linnakangas wrote:
Yeah, I think you're right. If you omit pg_xlog from the base backup,
as we recommend in the manual, and clear the old files from the
archive too, then you won't have the old history file around.
Simon Riggs wrote:
On Thu, 2009-05-07 at 17:54 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
A more useful thing might be to do an xlog switch before we do the
shutdown checkpoint at end of recovery. That gives the same sequence of
actions without modifying the existing sequence of
Simon Riggs wrote:
On Thu, 2009-05-07 at 18:57 +0300, Heikki Linnakangas wrote:
I don't see any user error here.
Just observing that the error occurs because we rely on a file being
there when we haven't even documented that it needs to be there for it
to work. File deletion with %
Fujii Masao wrote:
Hi,
On Fri, May 8, 2009 at 2:42 AM, Heikki Linnakangas
wrote:
When you create a new base backup, you shouldn't need any files archived
before starting the backup.
If so, this fix is not enough, since findNewestTimeLine() is
still based on the premise that *all
Fujii Masao wrote:
On Fri, May 15, 2009 at 8:20 PM, Heikki Linnakangas
wrote:
The probe in findNewestTimeLine() initialized to recovery target timeline +
1. It doesn't require history files for any old timelines to be present.
What if recovery_target_timeline = 'latest'? The
Simon Riggs wrote:
On Fri, 2009-05-15 at 20:38 +0900, Fujii Masao wrote:
On Fri, May 15, 2009 at 8:20 PM, Heikki Linnakangas
wrote:
The probe in findNewestTimeLine() initialized to recovery target timeline +
1. It doesn't require history files for any old timelines to be present.
Wh
a
WAL-file containing records from a lower numbered timeline...
That was the original issue you ran into. That has now been fixed by
forcing an xlog switch at pg_start_backup(), so that you can't start a
backup in a WAL file that contains records from a lower numbered timeline.
-
Simon Riggs wrote:
ehem, "It will work fine" isn't correct, as Fujii-san observes.
What exactly are the steps required to run into that problem? I fail to
see what the problem is.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bu
timeline history files. The backup history file(s) do need to go to
the archive, whereas the timeline file(s) do not.
(blush). Umm, and what is the distinction again? I thought they're the
same thing..
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql
_start_backup() was
called for the oldest backup you still want to be able to restore can be
deleted. And the alphabetical sorting property works with history files
as well, you can call pg_xlogfile_name(pg_start_backup()) and delete
anything < the return value from the archive.
--
He
Fujii Masao wrote:
On Fri, May 15, 2009 at 8:56 PM, Heikki Linnakangas
wrote:
Fujii Masao wrote:
When only the history file for timeline 6 is deleted, timeline 6 would be
assigned as the newest one *again* at the end of archive recovery.
Is this safe?
If you delete history file and all the
Simon Riggs wrote:
On Fri, 2009-05-15 at 17:19 +0300, Heikki Linnakangas wrote:
Yes, just as deleting old WAL files.
So what you're saying is because it's possible to blow your left foot
off, we're not concerned about blowing your right foot off either.
I don't get i
1 - 100 of 661 matches
Mail list logo
