On Mon, Apr 13, 2015 at 7:45 PM, Jim Nasby wrote:
> On 4/13/15 7:32 PM, David G. Johnston wrote:
>
> That particular use-case would probably best be served with a separate
>> replication channel which pushes data files from the primary to the
>> slaves and allows for the slave to basically "rew
On 4/13/15 7:32 PM, David G. Johnston wrote:
The missing feature is an option to leaved restored the last
checkpoint. Instead, not knowing whether there were changes
since the last checkpoint, the system truncated the relation.
What use case is there for a behavi
On Mon, Apr 13, 2015 at 4:49 PM, Jeff Janes wrote:
> On Mon, Apr 13, 2015 at 1:49 PM, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> On Monday, April 13, 2015, Matheus de Oliveira
>> wrote:
>>
>>>
>>> On Mon, Apr 13, 2015 at 4:31 PM, dgabriel
>>> wrote:
>>>
"In the event of
On Mon, Apr 13, 2015 at 1:49 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Monday, April 13, 2015, Matheus de Oliveira
> wrote:
>
>>
>> On Mon, Apr 13, 2015 at 4:31 PM, dgabriel
>> wrote:
>>
>>> "In the event of a normal shutdown, we can flush all the writes to disk
>>> so we k
On 4/13/15 4:13 PM, Alvaro Herrera wrote:
Jim Nasby wrote:
Yeah, this is not something that would be very easy to accomplish, because a
buffer can get evicted and written to disk at any point. It wouldn't be too
hard to read every unlogged table during recovery and see if there are any
pages th
Jim Nasby wrote:
> Yeah, this is not something that would be very easy to accomplish, because a
> buffer can get evicted and written to disk at any point. It wouldn't be too
> hard to read every unlogged table during recovery and see if there are any
> pages that were written after the last checkp
On 4/13/15 3:49 PM, David G. Johnston wrote:
On Monday, April 13, 2015, Matheus de Oliveira
mailto:matioli.math...@gmail.com>> wrote:
On Mon, Apr 13, 2015 at 4:31 PM, dgabriel > wrote:
"In the event of a normal shutdown, we can flush all the writes
to disk
so we know
On Monday, April 13, 2015, Matheus de Oliveira
wrote:
>
> On Mon, Apr 13, 2015 at 4:31 PM, dgabriel > wrote:
>
>> "In the event of a normal shutdown, we can flush all the writes to disk
>> so we know all the data has been written, so there is no need to
>> truncate."
>>
>> Isn't possible to peri
On Mon, Apr 13, 2015 at 5:30 PM, Yves Dorfsman wrote:
>
> In my experience postgres is very aggressive in getting rid of unlogged
> tables, it does get rid of them from shutdowns that seem perfectly fine (no
> crash). A lot of people get surprised by this.
Shutdowns in "fast" or "smart" modes d
On 2015-04-13 14:16, dgabriel wrote:
> That will be a very useful feature.
I agree, unlogged tables would be a lot more useful if they didn't "disappear"
on re-start.
> could be expensive. Also i have to detect when postgres crush, i have no
> idea how i can detect if postgres crushed. Then i ha
That will be a very useful feature. I don'
t care if i loss 1-2 hours of data. I know we could have some cron jobs to
dump the table periodically but the table could be big, so this operation
could be expensive. Also i have to detect when postgres crush, i have no
idea how i can detect if postgr
On Mon, Apr 13, 2015 at 4:31 PM, dgabriel wrote:
> "In the event of a normal shutdown, we can flush all the writes to disk
> so we know all the data has been written, so there is no need to truncate."
>
> Isn't possible to periodically flush data to disk and in case of crush
> postgres to load on
"In the event of a normal shutdown, we can flush all the writes to disk
so we know all the data has been written, so there is no need to truncate."
Isn't possible to periodically flush data to disk and in case of crush
postgres to load only the data that existed at last flush? The periodic
flush
13 matches
Mail list logo
