Re: making an unlogged table logged - Mailing list pgsql-hackers

From A.M.
Subject Re: making an unlogged table logged
Date
Msg-id 04CA4CA0-4A53-4BEA-A428-E83C3EBD3C67@themactionfaction.com
Whole thread Raw
In response to Re: making an unlogged table logged  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: making an unlogged table logged  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Jan 5, 2011, at 2:37 PM, Robert Haas wrote:

> On Wed, Jan 5, 2011 at 2:36 PM, Simon Riggs <simon@2ndquadrant.com> 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.
>
>> Question: what does an unlogged table look like on the standby? Are they
>> visible at all, does it throw an error, or do they just look empty. We
>> probably need some docs in the HS section to explain that. I hope the
>> answer isn't "look empty" since that is effectively data loss for people
>> spreading queries across multiple nodes.
>
> Error.

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
"itlooked like this at some point". Since the tables are not writing WAL, would it be possible to allow for writing to
unloggedtables on the standby to allow for out-of-band syncing? Otherwise, it seems the only alternative is to push
changesto a separate database on the standby machine and then suck the data in when it becomes master. 

Cheers,
M

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: making an unlogged table logged
Next
From: Simon Riggs
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Reduce spurious Hot Standby conflicts from never-visible records