On Thu, May 9, 2013 at 2:26 AM, Peter Eisentraut wrote:
> On Wed, 2013-05-08 at 18:24 +0100, Dave Page wrote:
>> It's failing on Linux. Even worse, it configures fine and then builds
>> without error. There is a message spewed out by configure, but it
>> doesn't contain the words warning or error.
Maybe some tests could be applied under some condition, say a given locale is
indeed available, but ISTM that it would require to change the test
infrastructure in a portable way to add such feature.
I just noticed that there is a "src/test/locale" directory with some stuff
about german, gre
On Thu, May 9, 2013 at 8:09 AM, Dave Page wrote:
> On Thu, May 9, 2013 at 2:26 AM, Peter Eisentraut wrote:
>> On Wed, 2013-05-08 at 18:24 +0100, Dave Page wrote:
>>> It's failing on Linux. Even worse, it configures fine and then builds
>>> without error. There is a message spewed out by configure
Hello,
> I think it can so happen that last checkpoint is with old timeline and there
> are operations with new timeline which might have caused the problem Heikki
> has seen.
I suppose to have seen that.
After adding an SQL command to modify the DB on standby-B after
passive(propagated?) promot
This updated version works for me and addresses previous comments.
I think that such tests are definitely valuable, especially as many corner
cases which must trigger errors are covered.
I recommend to apply it.
Please find an updated patch as per comments on Commitfest (comments
replicated
With printing some additinal logs, the situation should be more
clear..
It seems that Sby-B failes to promote to TLI= 2; nevertheless the
history file for TLI = 2 is somehow sent to sby-C. So sby-B
remains on TLI=1 but sby-C solely switches onto TLI=2.
# Come to think of this, I suspect that the
On Thu, May 9, 2013 at 9:12 AM, David Fetter wrote:
> On Wed, May 08, 2013 at 06:08:28PM -0500, Jim Nasby wrote:
> > I believe that makes it significantly harder for them to actually
> > contribute code back that doesn't give them a business advantage, as
> > well as making it harder to justify h
On Thu, May 9, 2013 at 4:19 PM, Fabien COELHO wrote:
> However, it is not clear whether these tests run automatically or only if
> they are explicitely called. The README seems to suggest that it is the
> later. If so, maybe having them invoked automatically if possible would
> ensure that they
On Thursday, May 09, 2013 2:14 PM Kyotaro HORIGUCHI wrote:
> With printing some additinal logs, the situation should be more
> clear..
>
> It seems that Sby-B failes to promote to TLI= 2; nevertheless the
> history file for TLI = 2 is somehow sent to sby-C. So sby-B
> remains on TLI=1 but sby-C s
On Wed, May 8, 2013 at 2:16 PM, Atri Sharma wrote:
>>
>> Your second drawing didn't really make any sense to me. :(
>>
>> I do think it would be most productive to focus on what the API for dealing
>> with graph data would look like before trying to handle the storage aspect.
>> The storage is pot
On 5/9/13 3:09 AM, Dave Page wrote:
> I assume you'll fix the configure script so it actually errors out if
> plpython cannot be built, but is explicitly requested?
That is ancient behavior, which I'm not fond of, but now is not the time
to change that.
--
Sent via pgsql-hackers mailing list (p
On 5/9/13 3:25 AM, Dave Page wrote:
> BTW - it's always worked fine for us on 64 bit machines with the past
> few major releases of both PG and Python - are you saying that's pure
> chance?
It works because ActiveState Python has PIC inside a static library.
But we have no straightforward way of k
>From the 9.1 cluster (port 5432):
db=# SELECT relname, relfilenode, relkind from pg_class where oid = 2938685;
relname| relfilenode | relkind
---+-+-
substitutionlist_pkey |21446253 | i
(1 row)
db=#
>From the 9.2 cluster (port 5433)
On Thu, May 9, 2013 at 10:20:12AM -0400, Evan D. Hoffman wrote:
> >From the 9.1 cluster (port 5432):
>
>
> db=# SELECT relname, relfilenode, relkind from pg_class where oid = 2938685;
> relname| relfilenode | relkind
> ---+-+-
> substitut
On Thu, May 9, 2013 at 3:09 PM, Peter Eisentraut wrote:
> On 5/9/13 3:09 AM, Dave Page wrote:
>> I assume you'll fix the configure script so it actually errors out if
>> plpython cannot be built, but is explicitly requested?
>
> That is ancient behavior, which I'm not fond of, but now is not the t
On Sat, May 4, 2013 at 3:59 PM, Tom Lane wrote:
> Given the lack of any good alternative proposals, I think we should
> press ahead with this approach. We still need doc updates and fixes
> for the affected contrib module(s), though. Also, in view of point 2,
> it seems like the extensions code
Hello
I am writing a article about 9.3. I found so event trigger functions is not
complete. We have only pg_event_trigger_dropped_objects() function. It
looks really strange and asymmetric. Can we implement similar function for
CREATE as minimum to 9.3?
I am expecting so this function should not
On 2013.05.09 10:40 AM, Pavel Stehule wrote:
I am writing a article about 9.3. I found so event trigger functions is not
complete. We have only pg_event_trigger_dropped_objects() function. It looks
really strange and asymmetric. Can we implement similar function for CREATE as
minimum to 9.3?
I a
Darren Duncan writes:
> On 2013.05.09 10:40 AM, Pavel Stehule wrote:
>> I am expecting so this function should not be too complex - and can be moved
>> to
>> contrib maybe (if it is too late now).
My understanding is that it's too late even for contrib now.
> Really, the touted new event trigge
2013/5/9 Dimitri Fontaine
> Darren Duncan writes:
> > On 2013.05.09 10:40 AM, Pavel Stehule wrote:
> >> I am expecting so this function should not be too complex - and can be
> moved to
> >> contrib maybe (if it is too late now).
>
> My understanding is that it's too late even for contrib now.
>
Darren Duncan wrote:
> On 2013.05.09 10:40 AM, Pavel Stehule wrote:
> >I am writing a article about 9.3. I found so event trigger functions is not
> >complete. We have only pg_event_trigger_dropped_objects() function. It looks
> >really strange and asymmetric. Can we implement similar function for
2013/5/9 Pavel Stehule
> Hello
>
> I am writing a article about 9.3. I found so event trigger functions is
> not complete. We have only pg_event_trigger_dropped_objects() function. It
> looks really strange and asymmetric. Can we implement similar function for
> CREATE as minimum to 9.3?
>
> I am
On 2013.05.09 11:22 AM, Alvaro Herrera wrote:
Darren Duncan wrote:
On 2013.05.09 10:40 AM, Pavel Stehule wrote:
I am writing a article about 9.3. I found so event trigger functions is not
complete. We have only pg_event_trigger_dropped_objects() function. It looks
really strange and asymmetric.
I just did the whole process over from the beginning. here's the full
output:
-bash-4.1$ date ; time /usr/pgsql-9.2/bin/pg_upgrade -b /usr/pgsql-9.1/bin/
-B /usr/pgsql-9.2/bin/ -d /var/lib/pgsql/9.1/data/ -D
/var/lib/pgsql/9.2/data/ -p 50432 -P 50433 ; date
Thu May 9 14:31:07 EDT 2013
Performing
On 5/8/13 7:34 PM, Jeff Davis wrote:
On Wed, 2013-05-08 at 17:56 -0500, Jim Nasby wrote:
Apologies if this is a stupid question, but is this mostly an issue
due to torn pages? IOW, if we had a way to ensure we never see torn
pages, would that mean an invalid CRC on a WAL page indicated there
rea
On Thu, May 9, 2013 at 03:23:20PM -0400, Evan D. Hoffman wrote:
> I just did the whole process over from the beginning. here's the full output:
>
> Copying user relation files
> /var/lib/pgsql/9.1/data/base/16406/3016054
> Mismatch of relation OID in database "db": old OID 29
That's correct. Here's what substitutionlist_pkey looks like in the new
cluster. From this, it looks like it's actually correct (the oid for
substitutionlist_pkey is correct) but pg_upgrade thinks it's wrong and
dies. I'll look for the logs you requested and send them separately
db=# SELECT rel
On Thu, May 9, 2013 at 03:52:42PM -0400, Evan D. Hoffman wrote:
> That's correct. Here's what substitutionlist_pkey looks like in the new
> cluster. From this, it looks like it's actually correct (the oid for
> substitutionlist_pkey is correct) but pg_upgrade thinks it's wrong and dies.
> I'll
Looks like your guess was correct:
[ehoffman@dev-db2 ~]$ psql -Upostgres db -p 5433
psql (9.2.4)
Type "help" for help.
db=# SELECT oid, relname, reltoastrelid, reltoastidxid FROM pg_class
db-# WHERE reltoastrelid = 299749;
oid | relname | reltoastrelid | reltoastidxid
---
"Evan D. Hoffman" writes:
> Looks like your guess was correct:
Could we see the full schema (eg psql \d+) for setupinfo?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
Here it is with the interesting field names mangled for paranoia reasons:
db=# \d+ bpm.setupinfo;
Table
"bpm.setupinfo"
Column| Type |
Modifiers | Storage | Stats target | Description
-
On Thu, May 9, 2013 at 04:21:05PM -0400, Evan D. Hoffman wrote:
> Looks like your guess was correct:
>
> [ehoffman@dev-db2 ~]$ psql -Upostgres db -p 5433
> psql (9.2.4)
> Type "help" for help.
>
> db=# SELECT oid, relname, reltoastrelid, reltoastidxid FROM pg_class
> db-# WHERE r
On 5/9/13 10:52 AM, Dave Page wrote:
> On Thu, May 9, 2013 at 3:09 PM, Peter Eisentraut wrote:
>> On 5/9/13 3:09 AM, Dave Page wrote:
>>> I assume you'll fix the configure script so it actually errors out if
>>> plpython cannot be built, but is explicitly requested?
>>
>> That is ancient behavior,
Bruce Momjian writes:
> OK, that's progress. Having received the table schema privately via
> email, I see several 'character varying(40)' fields in the schema. So
> the question is how was this table able to get away without a TOAST
> table in 9.1, while 9.2 created one for an empty table? Ide
On 9 May 2013 20:28, Jim Nasby wrote:
>> Unfortunately, it seems that doing any kind of validation to determine
>> that we have a valid end-of-the-WAL inherently requires some kind of
>> separate durable write somewhere. It would be a tiny amount of data (an
>> LSN and maybe some extra crosscheck
On Thu, May 9, 2013 at 05:11:43PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > OK, that's progress. Having received the table schema privately via
> > email, I see several 'character varying(40)' fields in the schema. So
> > the question is how was this table able to get away without a TO
On Thu, May 9, 2013 at 10:06 PM, Peter Eisentraut wrote:
> On 5/9/13 10:52 AM, Dave Page wrote:
>> On Thu, May 9, 2013 at 3:09 PM, Peter Eisentraut wrote:
>>> On 5/9/13 3:09 AM, Dave Page wrote:
I assume you'll fix the configure script so it actually errors out if
plpython cannot be bui
Simon Riggs writes:
> If the current WAL record is corrupt and the next WAL record is in
> every way valid, we can potentially continue.
That seems like a seriously bad idea.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
I believe the history of this cluster is that it started on 9.0 and was
upgraded to 9.1 via pg_upgrade. The instance I'm working on was created as a
streaming replica, then I broke the replication to make it a standalone master
specifically for testing pg_upgrade to 9.2.
On May 9, 2013, at 5:2
On 9 May 2013 22:39, Tom Lane wrote:
> Simon Riggs writes:
>> If the current WAL record is corrupt and the next WAL record is in
>> every way valid, we can potentially continue.
>
> That seems like a seriously bad idea.
I agree. But if you knew that were true, is stopping a better idea?
Any cor
On Thu, May 9, 2013 at 10:11 PM, Tom Lane wrote:
> In any case, it seems like pg_upgrade ought to have a strategy for
> dealing with tables acquiring toast tables like this,
Acquiring toast tables seems pretty trivial to deal with. *Losing* a
toast table might be a bit more involved...
Neither s
Greg Stark escribió:
> On Thu, May 9, 2013 at 10:11 PM, Tom Lane wrote:
> > In any case, it seems like pg_upgrade ought to have a strategy for
> > dealing with tables acquiring toast tables like this,
>
> Acquiring toast tables seems pretty trivial to deal with. *Losing* a
> toast table might be
On Thu, May 9, 2013 at 10:45 PM, Simon Riggs wrote:
> On 9 May 2013 22:39, Tom Lane wrote:
>> Simon Riggs writes:
>>> If the current WAL record is corrupt and the next WAL record is in
>>> every way valid, we can potentially continue.
>>
>> That seems like a seriously bad idea.
>
> I agree. But
On Thu, 2013-05-09 at 14:28 -0500, Jim Nasby wrote:
> What about moving some critical data from the beginning of the WAL
> record to the end? That would make it easier to detect that we don't
> have a complete record. It wouldn't necessarily replace the CRC
> though, so maybe that's not good enough
On Thu, May 9, 2013 at 06:05:14PM -0400, Alvaro Herrera wrote:
> Greg Stark escribió:
> > On Thu, May 9, 2013 at 10:11 PM, Tom Lane wrote:
> > > In any case, it seems like pg_upgrade ought to have a strategy for
> > > dealing with tables acquiring toast tables like this,
> >
> > Acquiring toast
On Thu, 2013-05-09 at 23:13 +0100, Greg Stark wrote:
> However it is possible to reduce the window...
Sounds reasonable.
It's fairly limited though -- the window is already a checkpoint
(typically 5-30 minutes), and we'd bring that down an order of magnitude
(10s). I speculate that, if it got cor
On Thu, May 9, 2013 at 05:41:39PM -0400, Evan D. Hoffman wrote:
> I believe the history of this cluster is that it started on 9.0 and
> was upgraded to 9.1 via pg_upgrade. The instance I'm working on was
> created as a streaming replica, then I broke the replication to make
> it a standalone master
Hmm... the database itself predates me, so I can't say for sure what
encoding it was created with, but when I did a "pg_dumpall -s" it
showed every database in the cluster uses "SET client_encoding =
'UTF8';"
On Thu, May 9, 2013 at 7:25 PM, Bruce Momjian wrote:
> On Thu, May 9, 2013 at 05:41:39PM
One workaround is to use DROP COLLATION IF EXISTS, that conveys the message
without UTF8 in the message string.
But three other tests use ALTER COLLATION and I see no way but to comment /
disable them. Currently have them disabled (with comments as to what they
do, and why they're disabled).
This
On Thu, 2013-05-09 at 10:11 -0400, Peter Eisentraut wrote:
> On 5/9/13 3:25 AM, Dave Page wrote:
> > BTW - it's always worked fine for us on 64 bit machines with the past
> > few major releases of both PG and Python - are you saying that's pure
> > chance?
>
> It works because ActiveState Python h
On Thu, May 9, 2013 at 09:22:55PM -0400, Evan D. Hoffman wrote:
> Hmm... the database itself predates me, so I can't say for sure what
> encoding it was created with, but when I did a "pg_dumpall -s" it
> showed every database in the cluster uses "SET client_encoding =
> 'UTF8';"
OK, that's good
On 9 May 2013 23:13, Greg Stark wrote:
> On Thu, May 9, 2013 at 10:45 PM, Simon Riggs wrote:
>> On 9 May 2013 22:39, Tom Lane wrote:
>>> Simon Riggs writes:
If the current WAL record is corrupt and the next WAL record is in
every way valid, we can potentially continue.
>>>
>>> That se
On Fri, May 10, 2013 at 2:47 AM, Peter Eisentraut wrote:
> On Thu, 2013-05-09 at 10:11 -0400, Peter Eisentraut wrote:
>> On 5/9/13 3:25 AM, Dave Page wrote:
>> > BTW - it's always worked fine for us on 64 bit machines with the past
>> > few major releases of both PG and Python - are you saying tha
53 matches
Mail list logo
