Hello, Pgsql-bugs.
According to the "Moving tablespaces" thread started by Bruce
http://archives.postgresql.org/pgsql-docs/2011-12/msg3.php
pg_tablespace.spclocation column is removed in the 9.2beta. However
this breaks backward compatibility for a bunch of products, e.g.
pgAdmin, phpPgAdmin,
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
Sent: Monday, June 25, 2012 6:39 AM
To: Andres Freund
Cc: pgsql-hackers@postgresql.org; Florian Pflug; Simon Riggs
Subject: Re: [HACKERS] Catalog/Metadata consist
Excerpts from Kevin Grittner's message of sáb jun 23 18:38:10 -0400 2012:
> Alvaro Herrera wrote:
>
> > So here's the rebased version.
>
> I found a couple problems on `make check-world`. Attached is a patch
> to fix one of them. The other is on pg_upgrade, pasted below.
Ah, I mismerged pg
Excerpts from Heikki Linnakangas's message of dom jun 24 12:22:30 -0400 2012:
> Replace XLogRecPtr struct with a 64-bit integer.
>
> This simplifies code that needs to do arithmetic on XLogRecPtrs.
>
> To avoid changing on-disk format of data pages, the LSN on data pages is
> still stored in the
On Fri, Jun 22, 2012 at 12:38 PM, Euler Taveira wrote:
> On 20-06-2012 17:40, Marko Kreen wrote:
>> On Wed, Jun 20, 2012 at 10:05 PM, Florian Pflug wrote:
>>> I'm starting to think that relying on SSL/TLS for compression of
>>> unencrypted connections might not be such a good idea after all. We'd
On Sun, Jun 24, 2012 at 5:11 PM, Andres Freund wrote:
> There are some interesting problems related to locking and snapshots here. Not
> sure if they are resolvable:
>
> We need to restrict SnapshotNow to represent to the view it had back when the
> wal record were currently decoding had. Otherwis
On 24 June 2012 22:50, Andres Freund wrote:
> On Sunday, June 24, 2012 11:37:26 PM Simon Riggs wrote:
>> On 24 June 2012 22:11, Andres Freund wrote:
>> > One interesting problem are table rewrites (truncate, cluster, some ALTER
>> > TABLE's) and dropping tables. Because we nudge SnapshotNow to th
On Sunday, June 24, 2012 11:37:26 PM Simon Riggs wrote:
> On 24 June 2012 22:11, Andres Freund wrote:
> > One interesting problem are table rewrites (truncate, cluster, some ALTER
> > TABLE's) and dropping tables. Because we nudge SnapshotNow to the past
> > view it had back when the wal record wa
On 22 June 2012 20:30, Andres Freund wrote:
> The problem making replacement of SnapshotNow.satisfies useful is that there
> is
> no convenient way to represent subtransactions of the current transaction
> which already have committed according to the TransactionLog but aren't yet
> visible at t
On 24 June 2012 22:11, Andres Freund wrote:
> One interesting problem are table rewrites (truncate, cluster, some ALTER
> TABLE's) and dropping tables. Because we nudge SnapshotNow to the past view it
> had back when the wal record was created we get the old relfilenode. Which
> might have been d
Howdy,
We're using NetApp's flexclone's whenever we need to move our DB between
machines.
One specific case where we do that is when we're creating a new streaming
replication target.
The basic steps we're using are:
pg_start_backup();
pg_stop_backup();
The problem i'm seeing is that periodi
On Thursday, June 21, 2012 01:41:25 PM Andres Freund wrote:
> Below are two possible implementation strategies for that concept
>
> Advantages:
> * Decoding is done on the master in an asynchronous fashion
> * low overhead during normal DML execution, not much additional code in
> that path
> * c
On Sun, Jun 24, 2012 at 2:40 PM, Peter Eisentraut wrote:
> Every time I make a change to the structure of the catalog files,
> genbki.pl produces a bunch of warnings (like "Use of uninitialized value
> in string eq at genbki.pl line ..."), and produces corrupted output
> files, that are then (poss
On 24.06.2012 21:34, Peter Eisentraut wrote:
On sön, 2012-06-24 at 20:23 +0300, Heikki Linnakangas wrote:
I just committed the patch to change XLogRecPtr into a 64-bit constant,
and I did this in the patch:
#define XLogSegmentsPerXLogId (0x1LL / XLOG_SEG_SIZE)
But I started to wonder,
Every time I make a change to the structure of the catalog files,
genbki.pl produces a bunch of warnings (like "Use of uninitialized value
in string eq at genbki.pl line ..."), and produces corrupted output
files, that are then (possibly) detected later by the compiler. Also,
getting out of that i
On sön, 2012-06-24 at 20:23 +0300, Heikki Linnakangas wrote:
> I just committed the patch to change XLogRecPtr into a 64-bit constant,
> and I did this in the patch:
>
> #define XLogSegmentsPerXLogId (0x1LL / XLOG_SEG_SIZE)
>
> But I started to wonder, is that LL representation the pref
On 24 June 2012 17:24, Heikki Linnakangas
wrote:
> Ok, committed all the WAL format changes now.
Nice!
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On 24 June 2012 18:23, Heikki Linnakangas
wrote:
> I just committed the patch to change XLogRecPtr into a 64-bit constant, and
> I did this in the patch:
>
> #define XLogSegmentsPerXLogId (0x1LL / XLOG_SEG_SIZE)
>
> But I started to wonder, is that LL representation the preferred way to
>
Le samedi 23 juin 2012 02:47:15, Josh Berkus a écrit :
> > The biggest problem with pgfincore from my point of view is that it
> > only works under Linux, whereas I use a MacOS X machine for my
> > development, and there is also Windows to think about. Even if that
> > were fixed, though, I feel w
I just committed the patch to change XLogRecPtr into a 64-bit constant,
and I did this in the patch:
#define XLogSegmentsPerXLogId (0x1LL / XLOG_SEG_SIZE)
But I started to wonder, is that LL representation the preferred way to
define 64-bit integer constants? I thought it is, but now
Ok, committed all the WAL format changes now.
On 19.06.2012 18:57, Robert Haas wrote:
Should we keep the old representation in the replication protocol messages?
That would make it simpler to write a client that works with different
server versions (like pg_receivexlog). Or, while we're at it, p
Stefan Kaltenbrunner writes:
> On 06/22/2012 11:47 PM, Tom Lane wrote:
>> Could you gdb each of these processes and get a stack trace?
[ unsurprising stack traces ]
OK, so they're waiting exactly where they should be.
So what we know is that the shutdown failure is caused by the child
processes
Andrew Dunstan writes:
> On 06/22/2012 04:43 PM, Tom Lane wrote:
>> A possible objection to it is that there are now three different ways in
>> which the pg_dump code knows which DO_XXX object types go in which dump
>> section: the new addBoundaryDependencies() function knows this, the
>> SECTION_
23 matches
Mail list logo
