Backpatched to 8.0.X and 8.1.X.
---
Kris Jurka wrote:
>
>
> On Fri, 24 Mar 2006, Jim C. Nasby wrote:
>
> > On Wed, Mar 22, 2006 at 02:37:28PM -0500, Kris Jurka wrote:
> >>
> >> On Wed, 22 Mar 2006, Jim C. Nasby wrote:
> >
On Fri, 2006-04-21 at 19:56 -0400, Bruce Momjian wrote:
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> It will be applied as soon as one of the PostgreSQL committers reviews
> and approves it.
This patch shou
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Kr
On Fri, 24 Mar 2006, Jim C. Nasby wrote:
On Wed, Mar 22, 2006 at 02:37:28PM -0500, Kris Jurka wrote:
On Wed, 22 Mar 2006, Jim C. Nasby wrote:
Ok, I saw disk activity on the base directory and assumed it was pg_xlog
stuff. Turns out that both SELECT INTO and CREATE TABLE AS ignore
default_t
On Fri, Mar 24, 2006 at 09:47:20AM -0400, Alvaro Herrera wrote:
> Jim C. Nasby wrote:
> > On Fri, Mar 24, 2006 at 08:39:02AM -0400, Alvaro Herrera wrote:
> > > Jim C. Nasby wrote:
> > >
> > > > Why would the content of the old_table be unreliable? If we've replayed
> > > > logs up to the point of
Jim C. Nasby wrote:
> On Fri, Mar 24, 2006 at 08:39:02AM -0400, Alvaro Herrera wrote:
> > Jim C. Nasby wrote:
> >
> > > Why would the content of the old_table be unreliable? If we've replayed
> > > logs up to the point of the CTAS then any data that would be visible to
> > > the CTAS should be fin
On Fri, Mar 24, 2006 at 08:39:02AM -0400, Alvaro Herrera wrote:
> Jim C. Nasby wrote:
>
> > Why would the content of the old_table be unreliable? If we've replayed
> > logs up to the point of the CTAS then any data that would be visible to
> > the CTAS should be fine, no?
> >
> > Though, the way
Jim C. Nasby wrote:
> Why would the content of the old_table be unreliable? If we've replayed
> logs up to the point of the CTAS then any data that would be visible to
> the CTAS should be fine, no?
>
> Though, the way Tom put it in one of his replies it sounds like WAL
> doesn't do any kind of s
On Wed, Mar 22, 2006 at 02:20:39PM +0800, Qingqing Zhou wrote:
>
> "Simon Riggs" <[EMAIL PROTECTED]> wrote
> > On Tue, 2006-03-21 at 06:22 -0600, Jim C. Nasby wrote:
> > > Currently, it appears that SELECT * INTO new_table FROM old_table logs
> > > each page as it's written to WAL. Is this actuall
On Wed, Mar 22, 2006 at 02:37:28PM -0500, Kris Jurka wrote:
>
>
> On Wed, 22 Mar 2006, Jim C. Nasby wrote:
>
> >Ok, I saw disk activity on the base directory and assumed it was pg_xlog
> >stuff. Turns out that both SELECT INTO and CREATE TABLE AS ignore
> >default_tablepsace and create the new t
"Simon Riggs" <[EMAIL PROTECTED]> wrote
> On Tue, 2006-03-21 at 06:22 -0600, Jim C. Nasby wrote:
> > Currently, it appears that SELECT * INTO new_table FROM old_table logs
> > each page as it's written to WAL. Is this actually needed? Couldn't the
> > database simply log that the SELECT ... INTO s
On Wed, 22 Mar 2006, Jim C. Nasby wrote:
Ok, I saw disk activity on the base directory and assumed it was pg_xlog
stuff. Turns out that both SELECT INTO and CREATE TABLE AS ignore
default_tablepsace and create the new tables in the base directory. I'm
guessing that's a bug... (this is on 8.1.2
On Wed, 2006-03-22 at 16:35, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Oh, so in other words, SELECT * INTO temp FROM table is inherently
> > non-deterministic at the physical level, so the only way to be able to
> > allow PITR to work is to duplicate all the physical changes
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Oh, so in other words, SELECT * INTO temp FROM table is inherently
> non-deterministic at the physical level, so the only way to be able to
> allow PITR to work is to duplicate all the physical changes. Darn.
Well, lemme put it this way: I'm not prepare
On Wed, Mar 22, 2006 at 10:06:05AM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> >> PITR wants all changes. Without PITR we can optimize certain logging
> >> actions.
>
> > The only change here is that we're creating a new table based on the
> > results of a SELECT. If that
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>> PITR wants all changes. Without PITR we can optimise certain logging
>> actions.
> The only change here is that we're creating a new table based on the
> results of a SELECT. If that SELECT doesn't use anything that's
> non-deterministic, then the mach
On Wed, Mar 22, 2006 at 01:08:34PM +, Simon Riggs wrote:
> On Wed, 2006-03-22 at 06:47 -0600, Jim C. Nasby wrote:
>
> > Also, why do we log rows for CTAS/SELECT INTO when PITR is in use for
> > simple SELECTs (ones that don't call non-deterministic functions)? The
> > data should alread be ava
On Wed, 2006-03-22 at 06:47 -0600, Jim C. Nasby wrote:
> Also, why do we log rows for CTAS/SELECT INTO when PITR is in use for
> simple SELECTs (ones that don't call non-deterministic functions)? The
> data should alread be available AFAICS...
Not sure what you're asking... SELECTs don't produce
On Tue, Mar 21, 2006 at 08:33:50PM +, Simon Riggs wrote:
> On Tue, 2006-03-21 at 06:22 -0600, Jim C. Nasby wrote:
> > Currently, it appears that SELECT * INTO new_table FROM old_table logs
> > each page as it's written to WAL. Is this actually needed? Couldn't the
> > database simply log that t
On Tue, 2006-03-21 at 06:22 -0600, Jim C. Nasby wrote:
> Currently, it appears that SELECT * INTO new_table FROM old_table logs
> each page as it's written to WAL. Is this actually needed? Couldn't the
> database simply log that the SELECT ... INTO statement was executed
> instead? Doing so would l
Currently, it appears that SELECT * INTO new_table FROM old_table logs
each page as it's written to WAL. Is this actually needed? Couldn't the
database simply log that the SELECT ... INTO statement was executed
instead? Doing so would likely result in a large performance improvement
in most install
21 matches
Mail list logo
