Re: [BUGS] BUG #8352: Using UPPER in ON clause of JOIN
On 08/02/2013 01:48 AM, dy...@rbauction.com wrote: The following bug has been logged on the website: Bug reference: 8352 Logged by: Daisy Email address: dy...@rbauction.com PostgreSQL version: 9.2.4 Operating system: Windows 7 Description: When joining two tables on a varchar column wrapped in a upper statement, the join does not work if there is a trailing space in both of the varchar values. In the two examples below, VALUE1 and VALUE2 = ABC -- Doesn't work SELECT * FROM TABLE1 INNER JOIN TABLE2 ON UPPER(VALUE1) = UPPER(VALUE2) -- Works SELECT * FROM TABLE1 INNER JOIN TABLE2 ON UPPER(TRIM(VALUE1)) = UPPER(TRIM(VALUE2)) I am unable to reproduce this. Can you provide a self-contained example please? Vik -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8347: PANIC: heap_insert_redo: failed to add tuple when applying WAL
Isn't it a funny coincidence, that we also had a corruption of that same/similar type? my disk was quite confidently not tampered. I am wondering: Does PG sign, or checksum wal_files? Is the integrity of wal_files ensured by any mechanism? Because if it IS, then - in our case - it's a corruption caused BY the postgres master server. I can replay the wal's and re-create the same error over and over. lg,k On Thu, Aug 1, 2013 at 11:13 PM, Maciek Sakrejda mac...@heroku.com wrote: On Tue, Jul 30, 2013 at 9:28 PM, Andres Freund and...@2ndquadrant.comwrote: Any chance you could https://github.com/snaga/xlogdump that and the neighbouring segments? That might tell us whether we're dealing with broken locking or possibly disk corruption (doesn't sound too likely). Actually, we did find what looks like some pretty crazy disk corruption after I reported this (heap tuple data in pg_clog files). I'm surprised Postgres did not wig out more, actually. I can run xlogdump later this week if it's still of interest, but I'm pretty satisfied that this was not Postgres' fault. Incidentally, the system performed admirably in the course of the recovery, considering the severely compromised state of heap and clog data. I'm really glad we're using Postgres.
Re: [BUGS] BUG #8347: PANIC: heap_insert_redo: failed to add tuple when applying WAL
On Fri, Aug 2, 2013 at 12:51 AM, Klaus Ita kl...@worstofall.com wrote: Isn't it a funny coincidence, that we also had a corruption of that same/similar type? my disk was quite confidently not tampered. I am wondering: Does PG sign, or checksum wal_files? Is the integrity of wal_files ensured by any mechanism? Because if it IS, then - in our case - it's a corruption caused BY the postgres master server. I can replay the wal's and re-create the same error over and over. Corruption can hitch a ride on a WAL full page image without much difficulty, as long as the page header looks legit (from what I've seen so far, a bad page header will prevent the system from doing much with it, so no FPIs will be generated). -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [GENERAL] Recovery_target_time misinterpreted?
No, it's super frustrating. While I do the recovery, it says it reaches a consistent recovery state, and i just cannot find a way how to convince pg to stop at that state: 2013-08-02 09:23:25 GMT DEBUG: postgres: PostmasterMain: initial environment dump: 2013-08-02 09:23:25 GMT DEBUG: - 2013-08-02 09:23:25 GMT DEBUG: PG_GRANDPARENT_PID=9077 2013-08-02 09:23:25 GMT DEBUG: PGLOCALEDIR=/usr/share/locale 2013-08-02 09:23:25 GMT DEBUG: PGSYSCONFDIR=/etc/postgresql-common 2013-08-02 09:23:25 GMT DEBUG: LANG=en_US.utf8 2013-08-02 09:23:25 GMT DEBUG: PWD=/var/lib/postgresql 2013-08-02 09:23:25 GMT DEBUG: PGDATA=/var/lib/postgresql/9.1/main 2013-08-02 09:23:25 GMT DEBUG: LC_COLLATE=en_US.utf8 2013-08-02 09:23:25 GMT DEBUG: LC_CTYPE=en_US.utf8 2013-08-02 09:23:25 GMT DEBUG: LC_MESSAGES=en_US.utf8 2013-08-02 09:23:25 GMT DEBUG: LC_MONETARY=C 2013-08-02 09:23:25 GMT DEBUG: LC_NUMERIC=C 2013-08-02 09:23:25 GMT DEBUG: LC_TIME=C 2013-08-02 09:23:25 GMT DEBUG: - 2013-08-02 11:23:26 CEST DEBUG: invoking IpcMemoryCreate(size=32399360) 2013-08-02 11:23:26 CEST DEBUG: removing file pg_notify/ 2013-08-02 11:23:26 CEST DEBUG: max_safe_fds = 982, usable_fds = 1000, already_open = 8 2013-08-02 11:23:26 CEST LOG: database system was interrupted while in recovery at log time 2013-07-29 11:45:24 CEST 2013-08-02 11:23:26 CEST HINT: If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target. 2013-08-02 11:23:26 CEST DEBUG: restore_command = 'cp /home/validad-pg-backups/pgmaster/wal_files/%f.gz /tmp/%f.gz gunzip /tmp/%f.gz mv /tmp/%f %p' 2013-08-02 11:23:26 CEST DEBUG: trigger_file = '/var/lib/postgresql/9.1/main/stop_replication_trigger' 2013-08-02 11:23:26 CEST LOG: starting archive recovery 2013-08-02 11:23:26 CEST DEBUG: executing restore command cp /home/validad-pg-backups/pgmaster/wal_files/0001027A002C.gz /tmp/0001027A002C.gz gunzip /tmp/0001027A002C.gz mv /tmp/0001027A002C pg_xlog/RECOVERYXLOG 2013-08-02 11:23:26 CEST DEBUG: forked new backend, pid=9090 socket=9 2013-08-02 11:23:26 CEST LOG: incomplete startup packet 2013-08-02 11:23:26 CEST DEBUG: shmem_exit(0): 0 callbacks to make 2013-08-02 11:23:26 CEST DEBUG: proc_exit(0): 1 callbacks to make 2013-08-02 11:23:26 CEST DEBUG: exit(0) 2013-08-02 11:23:26 CEST DEBUG: shmem_exit(-1): 0 callbacks to make 2013-08-02 11:23:26 CEST DEBUG: proc_exit(-1): 0 callbacks to make 2013-08-02 11:23:26 CEST DEBUG: reaping dead processes 2013-08-02 11:23:26 CEST DEBUG: server process (PID 9090) exited with exit code 0 2013-08-02 11:23:26 CEST LOG: restored log file 0001027A002C from archive 2013-08-02 11:23:26 CEST DEBUG: got WAL segment from archive 2013-08-02 11:23:26 CEST DEBUG: checkpoint record is at 27A/2CB77750 2013-08-02 11:23:26 CEST DEBUG: redo record is at 27A/2CB77750; shutdown TRUE 2013-08-02 11:23:26 CEST DEBUG: next transaction ID: 0/381985248; next OID: 1201662 2013-08-02 11:23:26 CEST DEBUG: next MultiXactId: 130079; next MultiXactOffset: 272843 2013-08-02 11:23:26 CEST DEBUG: oldest unfrozen transaction ID: 197713560, in database 331065 2013-08-02 11:23:26 CEST DEBUG: transaction ID wrap limit is 2345197207, limited by database with OID 331065 2013-08-02 11:23:26 CEST DEBUG: resetting unlogged relations: cleanup 1 init 0 2013-08-02 11:23:26 CEST LOG: redo starts at 27A/2CB777A8 2013-08-02 11:23:26 CEST DEBUG: executing restore command cp /home/validad-pg-backups/pgmaster/wal_files/0001027A002D.gz /tmp/0001027A002D.gz gunzip /tmp/0001027A002D.gz mv /tmp/0001027A002D pg_xlog/RECOVERYXLOG 2013-08-02 11:23:27 CEST DEBUG: forked new backend, pid=9098 socket=9 2013-08-02 11:23:27 CEST FATAL: the database system is starting up 2013-08-02 11:23:27 CEST DEBUG: shmem_exit(1): 0 callbacks to make 2013-08-02 11:23:27 CEST DEBUG: proc_exit(1): 1 callbacks to make 2013-08-02 11:23:27 CEST DEBUG: exit(1) 2013-08-02 11:23:27 CEST DEBUG: shmem_exit(-1): 0 callbacks to make 2013-08-02 11:23:27 CEST DEBUG: proc_exit(-1): 0 callbacks to make 2013-08-02 11:23:27 CEST DEBUG: reaping dead processes 2013-08-02 11:23:27 CEST DEBUG: server process (PID 9098) exited with exit code 1 2013-08-02 11:23:27 CEST LOG: restored log file 0001027A002D from archive 2013-08-02 11:23:27 CEST DEBUG: got WAL segment from archive 2013-08-02 11:23:27 CEST DEBUG: executing restore command cp /home/validad-pg-backups/pgmaster/wal_files/0001027A002E.gz /tmp/0001027A002E.gz gunzip /tmp/0001027A002E.gz mv /tmp/0001027A002E pg_xlog/RECOVERYXLOG 2013-08-02 11:23:27 CEST DEBUG: forked new backend, pid=9105 socket=9 2013-08-02 11:23:27 CEST FATAL: the
Re: [BUGS] BUG #8328: Unable to start postgresql on the Debian machine.
vijayakumar.su...@hp.com vijayakumar.su...@hp.com wrote: We are facing issue when trying to start postgresql on the Debian machine. This is almost certainly not a bug; so it doesn't belong on this list. pgsql-general would probably have been the best choice. Please pick a more appropriate list for any future questions. http://www.postgresql.org/community/lists/ 2013-07-24 19:16:38 LOG: could not bind IPv4 socket: Permission denied 2013-07-24 19:16:38 HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. 2013-07-24 19:16:38 WARNING: could not create listen socket for 127.0.0.1 2013-07-24 19:16:38 FATAL: could not create any TCP/IP sockets Is another postmaster running on port 5432? You could run any or all of these statements to get insight into that: lsof -i4TCP@127.0.0.1:5432 netstat -plnt | grep ':5432 ' ps aux | grep postgres -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8293: There are no methods to convert json scalar text to text in v9.3 beta2
On Wed, Jul 10, 2013 at 07:07:54PM +, jaroslav.pota...@gmail.com wrote:
The following bug has been logged on the website:
Bug reference: 8293
Logged by: Yaroslav Potapov
Email address: jaroslav.pota...@gmail.com
PostgreSQL version: Unsupported/Unknown
Operating system: All
Description:
SELECT 'a\b'::json::text
returns text: 'a\b' ,
but it must return 'ab' in my opinion.
I see you didn't get a reply, so let me try. I am no JSON expert, but I
think what is happening is that the system stores a\b because that is
what a JSON/Javascript interpreter would need to understand that value.
It would convert a\b to ab. If we just stored ab, the interpreter
would 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
(1 row)
SELECT json_extract_path('{\a: b\c}'::json, '\a');
json_extract_path
---
(1 row)
Notice the key is a, not \a.
--
Bruce Momjian br...@momjian.ushttp://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 your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8293: There are no methods to convert json scalar text to text in v9.3 beta2
On 08/02/2013 01:04 PM, Bruce Momjian wrote:
On Wed, Jul 10, 2013 at 07:07:54PM +, jaroslav.pota...@gmail.com wrote:
The following bug has been logged on the website:
Bug reference: 8293
Logged by: Yaroslav Potapov
Email address: jaroslav.pota...@gmail.com
PostgreSQL version: Unsupported/Unknown
Operating system: All
Description:
SELECT 'a\b'::json::text
returns text: 'a\b' ,
but it must return 'ab' in my opinion.
I see you didn't get a reply, so let me try. I am no JSON expert, but I
think what is happening is that the system stores a\b because that is
what a JSON/Javascript interpreter would need to understand that value.
It would convert a\b to ab. If we just stored ab, the interpreter
would throw an error on input.
Well, yes, although the shorter answer is simply that we would not be
storing legal JSON, which is defined by a standard, not by the
requirements of interpreters.
There is no specific cast to text for json. The cast therefore calls the
type's output function, which of course delivers the json string. To do
as the OP suggests would require us to treat JSON scalar strings as
special, since we would certainly not want to de-escape any JSON that
wasn't just a scalar string. e.g. removing quotes or backslashes in this
would be a major error:
select '{\a: b\c}'::json::text;
IOW, this isn't a bug in my view.
What we should possibly provide is a function to de-escape JSON scalar
strings explicitly. It would be a simple extension to write,
particularly for 9.3 where the JSON parser is hookable. (Or it could
easily be added as a core function of course).
cheers
andrew
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8354: stripped positions can generate nonzero rank in ts_rank_cd
The following bug has been logged on the website:
Bug reference: 8354
Logged by: Alex Hill
Email address: a...@hill.net.au
PostgreSQL version: 9.2.4
Operating system: OS X 10.8.4 Mountain Lion
Description:
Hi all,
The docs for ts_rank_cd state:
This function requires positional information in its input. Therefore it
will not work on stripped tsvector values — it will always return zero.
However if a tsvector contains some stripped lexemes and some non-stripped,
ts_rank_cd will rank extents including the non-stripped values.
For example, this evaluates to zero as expected:
SELECT ts_rank_cd(strip(to_tsvector('text search')),
plainto_tsquery('text search'))
But this doesn't:
SELECT ts_rank_cd(to_tsvector('text') || strip(to_tsvector('search')),
plainto_tsquery('text search'))
I think this is a bug, if not in the code then in the documentation, which
isn't clear on what happens when stripped and positioned lexemes are mixed
in one tsvector.
I would prefer that stripped lexemes were completely ignored by ts_rank_cd:
my use case is using this as a fifth pseudo-weight, which matches a @@ query
but doesn't add to a ts_rank_cd ranking.
What do you think?
Cheers,
Alex
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8355: PL/Python 3 can't convert infinity to PostgreSQL's value
The following bug has been logged on the website:
Bug reference: 8355
Logged by: Basil Peace
Email address: gr...@yandex.ru
PostgreSQL version: 9.2.4
Operating system: Windows 7 x64 (PostgreSQL is x86), Python 3.2.5
Description:
PL/Python can't convert Python's float with infinity value to PostgreSQL's
float.
The reason is that Python's standard representation of infinity is 'inf'
('Infinity' is accepted as well), but PostgreSQL's representation is
'Infinity' only.
I'm speaking of Python 3 version since I have no Python 2 to test.
Consider the following code:
-- CREATE LANGUAGE plpython3u;
CREATE TABLE IF NOT EXISTS test10 (
a double precision
);
DO LANGUAGE plpython3u $$
plan = plpy.prepare('INSERT INTO test10 (a) VALUES ($1)', ['double
precision'])
a = float('inf')
plpy.execute(plan, [a])
$$;
ERROR: spiexceptions.InvalidTextRepresentation: invalid input syntax for
type double precision: inf
CONTEXT: Traceback (most recent call last):
PL/Python anonymous code block, line 4, in module
plpy.execute(plan, [a])
PL/Python anonymous code block
I suppose this should work without any workarounds.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8355: PL/Python 3 can't convert infinity to PostgreSQL's value
gr...@yandex.ru writes:
PL/Python can't convert Python's float with infinity value to PostgreSQL's
float.
The reason is that Python's standard representation of infinity is 'inf'
('Infinity' is accepted as well), but PostgreSQL's representation is
'Infinity' only.
Hmm, I was about to contradict you, because it works fine on my Linux
and OS X machines:
regression=# select 'inf'::float8;
float8
--
Infinity
(1 row)
but further experimentation says that this doesn't work on my ancient
HPUX box; and you're complaining about Windows. So what we've got here
is a platform dependency in the behavior of strtod(). I don't think
we can promise to hide all such dependencies, but maybe it'd be a good
idea to take care of this particular one.
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
Re: [BUGS] BUG #8355: PL/Python 3 can't convert infinity to PostgreSQL's value
I wrote: ... further experimentation says that this doesn't work on my ancient HPUX box; and you're complaining about Windows. So what we've got here is a platform dependency in the behavior of strtod(). I don't think we can promise to hide all such dependencies, but maybe it'd be a good idea to take care of this particular one. I took a look in the C99 standard, and what it has to say about it is actually this: [#3] The expected form of the subject sequence is an optional plus or minus sign, then one of the following: -- a nonempty sequence of decimal digits optionally containing a decimal-point character, then an optional exponent part as defined in 6.4.4.2; -- a 0x or 0X, then a nonempty sequence of hexadecimal digits optionally containing a decimal-point character, then an optional binary-exponent part as defined in 6.4.4.2, where either the decimal-point character or the binary-exponent part is present; -- one of INF or INFINITY, ignoring case -- one of NAN or NAN(n-char-sequence-opt), ignoring case in the NAN part, where: n-char-sequence: digit nondigit n-char-sequence digit n-char-sequence nondigit Current versions of the POSIX standard say the same, though SUS v2 didn't mention any of the non-numeric variants. So what we've got is that Windows and some other (obsolete?) platforms don't accept everything the standard says they should, and that results in a visible cross-platform behavioral difference for us. I'm not at all excited about supporting 0x... constants, nor about the expanded form of NaN. But it seems like maybe we had better cover the following cases that we do not cover today: inf +inf -inf +Infinity We already backstop strtod() for these cases: NaN Infinity -Infinity but the wording of the spec clearly requires +Infinity as well as the forms with just inf. (It also appears to require +/- NaN to be accepted, but I have no idea what that would mean and suspect it to be a thinko.) Barring objections I'll go make this change. 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
Re: [BUGS] 9.3beta2: Failure to pg_upgrade
Alvaro Herrera escribió:
As it turns out, I have a patched slru.c that adds a new function to
verify whether a page exists on disk. I created this for the commit
timestamp module, for the BDR branch, but I think it's what we need
here.
Here's a patch that should fix the problem. Jesse, if you're able to
test it, please give it a run and let me know if it works for you. I
was able to upgrade an installation containing a problem that should
reproduce yours.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
*** a/src/backend/access/transam/multixact.c
--- b/src/backend/access/transam/multixact.c
***
*** 1719,1724 ZeroMultiXactMemberPage(int pageno, bool writeXlog)
--- 1719,1756
}
/*
+ * After a binary upgrade from = 9.2, the pg_multixact/offset SLRU area might
+ * contain files that are shorter than necessary; this would occur if the old
+ * installation had used multixacts beyond the first page (files cannot be
+ * copied, because the on-disk representation is different). pg_upgrade would
+ * update pg_control to set the next offset value to be at that position, so
+ * that tuples marked as locked by such MultiXacts would be seen as visible
+ * without having to consult multixact. However, trying to create a use a new
+ * MultiXactId would result in an error because the page on which the new value
+ * would reside does not exist. This routine is in charge of creating such
+ * pages.
+ */
+ static void
+ MaybeExtendOffsetSlru(void)
+ {
+ int pageno;
+
+ pageno = MultiXactIdToOffsetPage(MultiXactState-nextMXact);
+
+ LWLockAcquire(MultiXactOffsetControlLock, LW_EXCLUSIVE);
+
+ if (!SimpleLruDoesPhysicalPageExist(MultiXactOffsetCtl, pageno))
+ {
+ int slotno;
+
+ slotno = ZeroMultiXactOffsetPage(pageno, false);
+ SimpleLruWritePage(MultiXactOffsetCtl, slotno);
+ }
+
+ LWLockRelease(MultiXactOffsetControlLock);
+ }
+
+ /*
* This must be called ONCE during postmaster or standalone-backend startup.
*
* StartupXLOG has already established nextMXact/nextOffset by calling
***
*** 1738,1743 StartupMultiXact(void)
--- 1770,1782
int entryno;
int flagsoff;
+ /*
+ * During a binary upgrade, make sure that the offsets SLRU is large
+ * enough to contain the next value that would be created.
+ */
+ if (IsBinaryUpgrade)
+ MaybeExtendOffsetSlru();
+
/* Clean up offsets state */
LWLockAcquire(MultiXactOffsetControlLock, LW_EXCLUSIVE);
*** a/src/backend/access/transam/slru.c
--- b/src/backend/access/transam/slru.c
***
*** 563,568 SimpleLruWritePage(SlruCtl ctl, int slotno)
--- 563,612
SlruInternalWritePage(ctl, slotno, NULL);
}
+ /*
+ * Return whether the given page exists on disk.
+ *
+ * A false return means that either the file does not exist, or that it's not
+ * large enough to contain the given page.
+ */
+ bool
+ SimpleLruDoesPhysicalPageExist(SlruCtl ctl, int pageno)
+ {
+ int segno = pageno / SLRU_PAGES_PER_SEGMENT;
+ int rpageno = pageno % SLRU_PAGES_PER_SEGMENT;
+ int offset = rpageno * BLCKSZ;
+ char path[MAXPGPATH];
+ int fd;
+ bool result;
+ off_t endpos;
+
+ SlruFileName(ctl, path, segno);
+
+ fd = OpenTransientFile(path, O_RDWR | PG_BINARY, S_IRUSR | S_IWUSR);
+ if (fd 0)
+ {
+ /* expected: file doesn't exist */
+ if (errno == ENOENT)
+ return false;
+
+ /* report error normally */
+ slru_errcause = SLRU_OPEN_FAILED;
+ slru_errno = errno;
+ SlruReportIOError(ctl, pageno, 0);
+ }
+
+ if ((endpos = lseek(fd, 0, SEEK_END)) 0)
+ {
+ slru_errcause = SLRU_OPEN_FAILED;
+ slru_errno = errno;
+ SlruReportIOError(ctl, pageno, 0);
+ }
+
+ result = endpos = (off_t) (offset + BLCKSZ);
+
+ CloseTransientFile(fd);
+ return result;
+ }
/*
* Physical read of a (previously existing) page into a buffer slot
*** a/src/include/access/slru.h
--- b/src/include/access/slru.h
***
*** 145,150 extern int SimpleLruReadPage_ReadOnly(SlruCtl ctl, int pageno,
--- 145,151
extern void SimpleLruWritePage(SlruCtl ctl, int slotno);
extern void SimpleLruFlush(SlruCtl ctl, bool checkpoint);
extern void SimpleLruTruncate(SlruCtl ctl, int cutoffPage);
+ extern bool SimpleLruDoesPhysicalPageExist(SlruCtl ctl, int pageno);
typedef bool (*SlruScanCallback) (SlruCtl ctl, char *filename, int segpage,
void *data);
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 9.3beta2: Failure to pg_upgrade
On 2013-08-02 18:17:43 -0400, Alvaro Herrera wrote: Alvaro Herrera escribió: As it turns out, I have a patched slru.c that adds a new function to verify whether a page exists on disk. I created this for the commit timestamp module, for the BDR branch, but I think it's what we need here. Here's a patch that should fix the problem. Jesse, if you're able to test it, please give it a run and let me know if it works for you. I was able to upgrade an installation containing a problem that should reproduce yours. Wouldn't it be easier to make pg_upgrade fudge pg_control to have a safe NextMultiXactId/Offset using pg_resetxlog? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 9.3beta2: Failure to pg_upgrade
Andres Freund escribió: On 2013-08-02 18:17:43 -0400, Alvaro Herrera wrote: Alvaro Herrera escribió: As it turns out, I have a patched slru.c that adds a new function to verify whether a page exists on disk. I created this for the commit timestamp module, for the BDR branch, but I think it's what we need here. Here's a patch that should fix the problem. Jesse, if you're able to test it, please give it a run and let me know if it works for you. I was able to upgrade an installation containing a problem that should reproduce yours. Wouldn't it be easier to make pg_upgrade fudge pg_control to have a safe NextMultiXactId/Offset using pg_resetxlog? I don't understand. pg_upgrade already fudges pg_control to have a safe next multi, namely the same value used by the old cluster. The reason to preserve this value is that we must ensure no older value is consulted in pg_multixact: those might be present in tuples that were locked in the old cluster. (To be precise, this is the value to set as oldest multi, not next multi. But of course, the next multi must be greater than that one.) -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 9.3beta2: Failure to pg_upgrade
Alvaro, I applied the patch and tried upgrading again, and everything seemed to work as expected. We are now up and running the beta! -- Jesse Denardo On Fri, Aug 2, 2013 at 10:25 PM, Alvaro Herrera alvhe...@2ndquadrant.comwrote: Andres Freund escribió: On 2013-08-02 18:17:43 -0400, Alvaro Herrera wrote: Alvaro Herrera escribió: As it turns out, I have a patched slru.c that adds a new function to verify whether a page exists on disk. I created this for the commit timestamp module, for the BDR branch, but I think it's what we need here. Here's a patch that should fix the problem. Jesse, if you're able to test it, please give it a run and let me know if it works for you. I was able to upgrade an installation containing a problem that should reproduce yours. Wouldn't it be easier to make pg_upgrade fudge pg_control to have a safe NextMultiXactId/Offset using pg_resetxlog? I don't understand. pg_upgrade already fudges pg_control to have a safe next multi, namely the same value used by the old cluster. The reason to preserve this value is that we must ensure no older value is consulted in pg_multixact: those might be present in tuples that were locked in the old cluster. (To be precise, this is the value to set as oldest multi, not next multi. But of course, the next multi must be greater than that one.) -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services
Re: [BUGS] 9.3beta2: Failure to pg_upgrade
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 br...@momjian.ushttp://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 your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [HACKERS] [BUGS] 9.3beta2: Failure to pg_upgrade
On 2013-08-02 22:25:36 -0400, Alvaro Herrera wrote: Andres Freund escribió: On 2013-08-02 18:17:43 -0400, Alvaro Herrera wrote: Alvaro Herrera escribió: As it turns out, I have a patched slru.c that adds a new function to verify whether a page exists on disk. I created this for the commit timestamp module, for the BDR branch, but I think it's what we need here. Here's a patch that should fix the problem. Jesse, if you're able to test it, please give it a run and let me know if it works for you. I was able to upgrade an installation containing a problem that should reproduce yours. Wouldn't it be easier to make pg_upgrade fudge pg_control to have a safe NextMultiXactId/Offset using pg_resetxlog? I don't understand. pg_upgrade already fudges pg_control to have a safe next multi, namely the same value used by the old cluster. The reason to preserve this value is that we must ensure no older value is consulted in pg_multixact: those might be present in tuples that were locked in the old cluster. (To be precise, this is the value to set as oldest multi, not next multi. But of course, the next multi must be greater than that one.) I am suggesting to set them to a greater value than in the old cluster, computed so it's guaranteed that they are proper page boundaries. Then the situation described upthread shouldn't occur anymore, right? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
