Andrew Dunstan and...@dunslane.net 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,
Stefan Kaltenbrunner ste...@kaltenbrunner.cc 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
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,
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
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 we ought
On 24 June 2012 18:23, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On 24 June 2012 17:24, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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 preferred
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 is
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
On Sun, Jun 24, 2012 at 2:40 PM, Peter Eisentraut pete...@gmx.net 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
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
* can be
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();
flex clone within the netapp
pg_stop_backup();
The
On 24 June 2012 22:11, Andres Freund and...@2ndquadrant.com 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
On 22 June 2012 20:30, Andres Freund and...@2ndquadrant.com 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
On Sunday, June 24, 2012 11:37:26 PM Simon Riggs wrote:
On 24 June 2012 22:11, Andres Freund and...@2ndquadrant.com 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
On 24 June 2012 22:50, Andres Freund and...@2ndquadrant.com wrote:
On Sunday, June 24, 2012 11:37:26 PM Simon Riggs wrote:
On 24 June 2012 22:11, Andres Freund and...@2ndquadrant.com wrote:
One interesting problem are table rewrites (truncate, cluster, some ALTER
TABLE's) and dropping
On Sun, Jun 24, 2012 at 5:11 PM, Andres Freund and...@2ndquadrant.com 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
On Fri, Jun 22, 2012 at 12:38 PM, Euler Taveira eu...@timbira.com wrote:
On 20-06-2012 17:40, Marko Kreen wrote:
On Wed, Jun 20, 2012 at 10:05 PM, Florian Pflug f...@phlo.org wrote:
I'm starting to think that relying on SSL/TLS for compression of
unencrypted connections might not be such a
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 old
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
-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
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,
23 matches
Mail list logo
