On Tue, Jan 4, 2011 at 9:41 PM, Robert Haas wrote:
> Generally, to do this, it would be necessary to do the following
> things (plus anything I'm forgetting):
It occurs to me that almost exactly this same procedure could be used
to make a *temporary* table into a permanent table. You'd have to
a
> Jan Wieck started a discussion back then to offer the basics we need in
> core as far as queuing goes, here:
>
> http://archives.postgresql.org/pgsql-hackers/2010-05/msg01209.php
>
> What happened to that effort?
Stalled due to lack of manpower, currently.
--
Robert Haas writes:
> Adding logical replication would be a lot of
> work but we'd get a lot of collateral benefits. Imagine that PG had
There has been extensive discussions at last pgcon about that (mainly in
the "hallway track", but also in the devroom we had) to work on getting
the common b
On Wed, Jan 5, 2011 at 6:25 PM, Josh Berkus wrote:
> On 1/5/11 3:14 PM, Robert Haas wrote:
>> I think that's probably a dead end - just to take one example, if you
>> don't sync often enough, the standby might have transaction ID
>> wraparound problems. Autovacuum on the master will prevent that
On 1/5/11 3:14 PM, Robert Haas wrote:
> I think that's probably a dead end - just to take one example, if you
> don't sync often enough, the standby might have transaction ID
> wraparound problems. Autovacuum on the master will prevent that for
> permanent tables, but not for an only-occasionally-
On Wed, Jan 5, 2011 at 3:58 PM, Josh Berkus wrote:
>> Hm- if the unlogged tables are being used as HTTP transient state storage,
>> it would be handy to have that (admittedly non-essential) data on the
>> standby when it becomes master, even if there are no guarantees surrounding
>> the data be
Josh Berkus writes:
> It would be useful (this would allow per-standby buffer tables, for that
> matter), but it would also be tremendously difficult. Seems worthy of a
> TODO, though.
Don't we have anything covering xid-less tables in the TODO already? The
read-only tables "compressions" of rem
> Hm- if the unlogged tables are being used as HTTP transient state storage, it
> would be handy to have that (admittedly non-essential) data on the standby
> when it becomes master, even if there are no guarantees surrounding the data
> beyond "it looked like this at some point". Since the tab
On Jan 5, 2011, at 2:37 PM, Robert Haas wrote:
> On Wed, Jan 5, 2011 at 2:36 PM, Simon Riggs wrote:
>> The lock strength selected on the master doesn't need to be the same as
>> the lock strength on the standby. You could quite easily generate AEL
>> lock records to send to standby, without actu
On Wed, Jan 5, 2011 at 2:36 PM, Simon Riggs wrote:
> The lock strength selected on the master doesn't need to be the same as
> the lock strength on the standby. You could quite easily generate AEL
> lock records to send to standby, without actually taking that lock level
> on the master.
True.
>
On Tue, 2011-01-04 at 21:41 -0500, Robert Haas wrote:
> 6. If wal_level != minimal, XLOG every page of every fork except the
> init fork, for both the table and the associated indexes. (Note that
> this step also requires an AccessExclusiveLock rather than some weaker
> lock, because of the arbitr
On Wed, Jan 5, 2011 at 2:02 PM, Josh Berkus wrote:
> Note that the conversion both ways can be worked around with the
> CREATE/ALTER TABLE dosiedo, so I don't think either of these is critical
> for 9.1. Unless you feel like working on them, of course.
As I said in my OP, I don't intend to work
On 1/4/11 6:41 PM, Robert Haas wrote:
> Going the other direction ought to be possible too, although it seems
> somewhat less useful.
Actually, it's more useful; many people who *upgrade* to 9.1 will wand
to convert one or two of their tables to unlogged.
Note that the conversion both ways can be
On Wed, Jan 5, 2011 at 7:48 AM, David Fetter wrote:
> On Wed, Jan 05, 2011 at 09:04:08AM -0500, Robert Haas wrote:
>> On Tue, Jan 4, 2011 at 10:56 PM, Rob Wultsch wrote:
>> > 1. Could the making a table logged be a non-exclusive lock if the
>> > ALTER is allowed to take a full checkpoint?
>>
>> N
On Wed, Jan 05, 2011 at 09:04:08AM -0500, Robert Haas wrote:
> On Tue, Jan 4, 2011 at 10:56 PM, Rob Wultsch wrote:
> > 1. Could the making a table logged be a non-exclusive lock if the
> > ALTER is allowed to take a full checkpoint?
>
> No, that doesn't solve either of the two problems I describe
On Tue, Jan 4, 2011 at 10:56 PM, Rob Wultsch wrote:
> 1. Could the making a table logged be a non-exclusive lock if the
> ALTER is allowed to take a full checkpoint?
No, that doesn't solve either of the two problems I described, unfortunately.
> 2. Unlogged to logged has giant use case.
Agree.
> > --
> > Robert Haas
> > EnterpriseDB: http://www.enterprisedb.com
> > The Enterprise PostgreSQL Company
>
> A couple thoughts:
> 1. Could the making a table logged be a non-exclusive lock if the
> ALTER is allowed to take a full checkpoint?
If possible, that would certainly be better. If the
On Tue, Jan 4, 2011 at 7:41 PM, Robert Haas wrote:
> Somebody asked about this on Depesz's blog today, and I think it's
> come up here before too, so I thought it might be worth my writing up
> a few comments on this. I don't think I'm going to have time to work
> on this any time soon, but if so
18 matches
Mail list logo
