AFAIK we don't truncate the log file created by the log_filename GUC
on every unclean crash and every clean shutdown.
That's not a remotely relevant analogy. A log file is not a database table.
If we allow a database table to become corrupted due to being unsynched
at the time of shutdown,
Josh Berkus wrote:
>> With the current patches, the data survives a restart just fine.
>
> Per -hackers, that's not guarenteed.
"Not guaranteed" is fine. What people are asking for is "often survives".
AFAIK we don't truncate the log file created by the log_filename GUC
on every unclean crash an
Glen Parker wrote:
> As was already mentioned, application logs. Unlogged tables would be
> perfect for that, provided they don't go *poof* every now and then for
> no good reason. Nobody's going to be too heart broken if a handful of
> log records go missing, or get garbled, after a server crash
Hello,
> > Thank you for the reply. But my doubt was not about layout, rather the
> > DMLs. If I do an insert into an 'unlogged' table, what happens to
that?
> > Will that be replicated in the slave (using PostgreSQL's inbuilt
> > replication)?
>
> What are the use-cases for replicating unlo
> What are the use-cases for replicating unlogged tables?
Hello,
I guess they could be useful in cloud infrastructures.
(see http://archives.postgresql.org/pgsql-general/2010-11/msg00865.php)
regards,
Marc Mamin
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make ch
On 19 Nov 2010, at 4:23, Jayadevan M wrote:
> Hi,
>
>>> One doubt - if the tables are 'unlogged' , will the DMLs against these
>>> still be replicated to a slave?
>>>
>>
>> Yes, because the system tables, which store the layout of all tables, is
>
>> written to WAL.
> Thank you for the reply.
Hi,
> > One doubt - if the tables are 'unlogged' , will the DMLs against these
> > still be replicated to a slave?
> >
>
> Yes, because the system tables, which store the layout of all tables, is
> written to WAL.
Thank you for the reply. But my doubt was not about layout, rather the
DMLs. If
Does that sum it up adequately?
One more thing: that you might not get all of these options in 9.1.
Currently the discussion is talking about *maybe* offering checkpointing
of unlogged tables, which would allow such tables to survive a normal
restart, and including unlogged tables in pg_dum
On 11/18/2010 3:46 AM, Jayadevan M wrote:
Hello,
PostgreSQL 9.1 is likely to have, as a feature, the ability to create
tables which are "unlogged", meaning that they are not added to the
transaction log, and will be truncated (emptied) on database restart.
Such tables are intended for highly vo
Hello,
> > PostgreSQL 9.1 is likely to have, as a feature, the ability to create
> > tables which are "unlogged", meaning that they are not added to the
> > transaction log, and will be truncated (emptied) on database restart.
> > Such tables are intended for highly volatile, but not very valuable
On Thu, Nov 18, 2010 at 10:30:46AM +0100, Karsten Hilbert wrote:
> That is why I argued for options:
>
> - alter database dump_unlogged_tables to on/off
>
> default on: better safe than sorry, point the gun but don't pull the
> trigger
(I agree, however, that the database metadata isn't
On Thu, Nov 18, 2010 at 08:49:12AM +0100, Alban Hertroys wrote:
> From the discussion so far it appears to me that
> "unlogged" should probably be split into various gradations
> of unlogged. There appear to be a number of popular
> use-cases for such tables, with different requirements,
That's p
On 16 Nov 2010, at 23:46, Josh Berkus wrote:
> Folks,
>
> Please help us resolve a discussion on -hackers.
>
> PostgreSQL 9.1 is likely to have, as a feature, the ability to create
> tables which are "unlogged", meaning that they are not added to the
> transaction log, and will be truncated (emp
On Tue, Nov 16, 2010 at 5:46 PM, Josh Berkus wrote:
> Folks,
>
> Please help us resolve a discussion on -hackers.
>
> PostgreSQL 9.1 is likely to have, as a feature, the ability to create
> tables which are "unlogged", meaning that they are not added to the
> transaction log, and will be truncated
ng up unlogged tables: help us
with PostgreSQL development!
"Marc Mamin" writes:
> Will it be possible to switch from unlogged to logged ?
Probably not, because it would completely confuse hot standby slaves
(or anything else looking at the WAL replay stream). You can't just
st
"Marc Mamin" writes:
> Will it be possible to switch from unlogged to logged ?
Probably not, because it would completely confuse hot standby slaves
(or anything else looking at the WAL replay stream). You can't just
start issuing WAL records against an already-built table or index,
because the W
Hello,
another question.
I haven't read the complete threads, so I apologize if this was already
discussed.
Will it be possible to switch from unlogged to logged ?
To improve COPY performances, I currently:
- make a copy of heavily indexed tables
- load new data in the shadow table
- add the
I would like to choose the table behaviour on restart (restore/forget it)
Currently, I'm looking for a way to split large transaction on different
threads (with dblink).
AN issue is to efficiently share temp data across the threads. unlogged tables
would be here fine, something like glo
On Wed, Nov 17, 2010 at 12:49 PM, Josh Berkus wrote:
>
> As was already mentioned, application logs. Unlogged tables would be
>> perfect for that, provided they don't go *poof* every now and then for
>> no good reason. Nobody's going to be too heart broken if a handful of
>> log records go missi
On 11/16/2010 07:25 PM, Tom Lane wrote:
2. What's proposed as the new feature is that specific non-system
tables can be marked as unlogged, meaning that WAL entries won't
be made for changes in those tables' contents (nor their indexes'
contents). So we can't guarantee that the contents of such
As was already mentioned, application logs. Unlogged tables would be
perfect for that, provided they don't go *poof* every now and then for
no good reason. Nobody's going to be too heart broken if a handful of
log records go missing, or get garbled, after a server crash or power
outage. Delete '
Steve Crawford writes:
> 1. Would there be restrictions preventing a standard table from having a
> FK or other constraint that depends on an unlogged table? If not, it
> seems like there could be an unwanted ripple-effect from lost of the
> unlogged table.
I would assume that we should disall
On 11/16/2010 07:25 PM, Tom Lane wrote:
Man, the number of misunderstandings in this thread is staggering
First, I have plenty of processes that I would immediately convert to
using this (and, FWIW, none of them would benefit from preserving data
across restarts). But I have some que
Derrick Rice writes:
> Is there a difference between a global temporary table (if such a thing
> existed in PostgreSQL) and an unlogged table?
Yes --- IIRC, a "global temp table" per spec has session-local contents.
An unlogged table acts just like any other table except with respect to
crash saf
On Wed, Nov 17, 2010 at 10:38 AM, Scott Mead wrote:
> On Tue, Nov 16, 2010 at 10:25 PM, Tom Lane wrote:
>
>> Man, the number of misunderstandings in this thread is staggering.
>> Let me try to explain what the proposed feature will and will not do.
>>
>> 1. The system catalog entries for all tab
On Tue, Nov 16, 2010 at 10:25 PM, Tom Lane wrote:
> Man, the number of misunderstandings in this thread is staggering.
> Let me try to explain what the proposed feature will and will not do.
>
> 1. The system catalog entries for all tables will be wal-logged.
> So schema (DDL) will survive a cras
On Wed, Nov 17, 2010 at 8:20 AM, Yeb Havinga wrote:
> That sounds an awful lot like temporary tables.
A lot like a GLOBAL temporary table, which isn't currently supported.
Is there a difference between a global temporary table (if such a thing
existed in PostgreSQL) and an unlogged table?
Der
On 2010-11-17 02:55, Josh Berkus wrote:
If you do wish to have the data tossed out for no good reason every so
often, then there ought to be a separate attribute to control that. I'm
really having trouble seeing how such behavior would be desirable enough
to ever have the server do it for you, o
On Tue, Nov 16, 2010 at 10:25:13PM -0500, Tom Lane wrote:
> 4. The last bit of discussion on -hackers concerned what to do in
> the case where the server got shut down cleanly. If it was shut
> down cleanly, then any data for unlogged tables would have been
> written out from shared buffers ... b
Man, the number of misunderstandings in this thread is staggering.
Let me try to explain what the proposed feature will and will not do.
1. The system catalog entries for all tables will be wal-logged.
So schema (DDL) will survive a crash. There wouldn't be any way
to make it not do that, because
On 11/16/2010 05:55 PM, Josh Berkus wrote:
If you do wish to have the data tossed out for no good reason every so
often, then there ought to be a separate attribute to control that. I'm
really having trouble seeing how such behavior would be desirable enough
to ever have the server do it for y
On 11/16/2010 07:55 PM, Josh Berkus wrote:
If you do wish to have the data tossed out for no good reason every so
often, then there ought to be a separate attribute to control that. I'm
really having trouble seeing how such behavior would be desirable enough
to ever have the server do it for y
> I'd vote for backing up the schema of an unlogged table so it's there
> on a restore.
The schema is always there. What may or may not be there is the data.
--
-- Josh Berkus
PostgreSQL Experts Inc.
> If you do wish to have the data tossed out for no good reason every so
> often, then there ought to be a separate attribute to control that. I'm
> really having trouble seeing how such behavior would be desirable enough
> to ever have the server do it for you, on its terms rather than yours.
I
On 11/16/2010 05:33 PM, Josh Berkus wrote:
With the current patches, the data survives a restart just fine.
Per -hackers, that's not guarenteed.
Which is fine. If you choose to set a table to nonlogged, that implies
that you accept the risk of corrupted data, or that you don't "get it",
On Tue, Nov 16, 2010 at 8:15 PM, Tom Lane wrote:
> Scott Mead writes:
> > +1 -- Is there a technical reason to do a TRUNCATE on restart? I'd feel
> > better if I could just have unlogged tables that survive unless something
> > like a power-outage etc... I'm in the exact same boat here, lots
On Tue, Nov 16, 2010 at 5:23 PM, Scott Ribe wrote:
> On Nov 16, 2010, at 3:46 PM, Josh Berkus wrote:
>
>> ...and will be truncated (emptied) on database restart.
>
> I think that's key. Anything that won't survive a database restart, I sure
> don't expect to survive backup & restore.
I'd vote f
On 11/16/2010 07:33 PM, Josh Berkus wrote:
With the current patches, the data survives a restart just fine.
Per -hackers, that's not guarenteed.
Ah, I just read the thread on -hackers. And yea, my system had 24 hours to
write/flush/etc before I'd restarted it moments ago as a test. I ha
> With the current patches, the data survives a restart just fine.
Per -hackers, that's not guarenteed.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sent via pg
On 11/16/2010 05:15 PM, Tom Lane wrote:
Keep in mind that these tables are *not* going to survive any type of
backend crash. Maybe my perceptions are colored because I deal with
Postgres bugs all the time, but I think of backend crashes as pretty
common, certainly much more common than an OS-lev
On 11/16/2010 04:46 PM, Josh Berkus wrote:
PostgreSQL 9.1 is likely to have, as a feature, the ability to create
tables which are "unlogged", meaning that they are not added to the
transaction log, and will be truncated (emptied) on database restart.
Such tables are intended for highly volatile,
Scott Mead writes:
> +1 -- Is there a technical reason to do a TRUNCATE on restart? I'd feel
> better if I could just have unlogged tables that survive unless something
> like a power-outage etc... I'm in the exact same boat here, lots of big
> logging tables that need to survive reboot, but ar
On Tue, Nov 16, 2010 at 7:21 PM, Glen Parker wrote:
> On 11/16/2010 03:24 PM, Karsten Hilbert wrote:
>
>> PostgreSQL 9.1 is likely to have, as a feature, the ability to create
>>> tables which are "unlogged", meaning that they are not added to the
>>> transaction log, and will be truncated (empti
> This is a link to a read-only spreadsheet for me.
You're correct. Darn those Google unreadable links!
https://spreadsheets.google.com/viewform?formkey=dDFnT2VKNC1FQ0pQNmJGS2dWMTNYMEE6MQ
That should work.
--
-- Josh Berkus
On 11/16/2010 03:24 PM, Karsten Hilbert wrote:
PostgreSQL 9.1 is likely to have, as a feature, the ability to create
tables which are "unlogged", meaning that they are not added to the
transaction log, and will be truncated (emptied) on database restart.
Such tables are intended for highly volati
On Nov 16, 2010, at 3:46 PM, Josh Berkus wrote:
> ...and will be truncated (emptied) on database restart.
I think that's key. Anything that won't survive a database restart, I sure
don't expect to survive backup & restore.
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
On Tue, Nov 16, 2010 at 5:46 PM, Josh Berkus wrote:
>
> Survey is here:
>
> https://spreadsheets.google.com/ccc?key=0AoeuP3g2YZsFdDFnT2VKNC1FQ0pQNmJGS2dWMTNYMEE&hl=en&authkey=CISbwuYD
This is a link to a read-only spreadsheet for me.
Derrick
> PostgreSQL 9.1 is likely to have, as a feature, the ability to create
> tables which are "unlogged", meaning that they are not added to the
> transaction log, and will be truncated (emptied) on database restart.
> Such tables are intended for highly volatile, but not very valuable,
> data, such a
Folks,
Please help us resolve a discussion on -hackers.
PostgreSQL 9.1 is likely to have, as a feature, the ability to create
tables which are "unlogged", meaning that they are not added to the
transaction log, and will be truncated (emptied) on database restart.
Such tables are intended for high
49 matches
Mail list logo
