Applied.
---
On Fri, Nov 30, 2012 at 10:43:29PM -0500, Bruce Momjian wrote:
> On Mon, Nov 26, 2012 at 02:43:19PM -0500, Bruce Momjian wrote:
> > > >> In any event, I think the documentation should caution that the
> > > >> u
On Mon, Nov 26, 2012 at 02:43:19PM -0500, Bruce Momjian wrote:
> > >> In any event, I think the documentation should caution that the
> > >> upgrade should not be deemed to be a success until after a system-wide
> > >> sync has been done. Even if we use the link rather than copy method,
> > >> are
On Sat, Nov 24, 2012 at 09:42:08PM -0800, Jeff Janes wrote:
> On Fri, Nov 23, 2012 at 7:22 PM, Bruce Momjian wrote:
> > On Mon, Nov 19, 2012 at 12:11:26PM -0800, Jeff Janes wrote:
> >
> >>
> >> Yes, it is with synchronous_commit=off. (or if it wasn't originally,
> >> it is now, with the same resu
On Fri, Nov 23, 2012 at 7:22 PM, Bruce Momjian wrote:
> On Mon, Nov 19, 2012 at 12:11:26PM -0800, Jeff Janes wrote:
>
>>
>> Yes, it is with synchronous_commit=off. (or if it wasn't originally,
>> it is now, with the same result)
>>
>> Applying your fsync patch does solve the problem for me on ext
On Mon, Nov 19, 2012 at 12:11:26PM -0800, Jeff Janes wrote:
[ Sorry for the delay in replying.]
> On Wed, Nov 14, 2012 at 3:55 PM, Bruce Momjian wrote:
> > On Mon, Nov 12, 2012 at 10:29:39AM -0800, Jeff Janes wrote:
> >>
> >> Is turning off synchronous_commit enough? What about turning off fsy
On Wed, Nov 14, 2012 at 3:55 PM, Bruce Momjian wrote:
> On Mon, Nov 12, 2012 at 10:29:39AM -0800, Jeff Janes wrote:
>>
>> Is turning off synchronous_commit enough? What about turning off fsync?
>
> I did some testing with the attached patch on a magnetic disk with no
> BBU that turns off fsync;
On Mon, Nov 12, 2012 at 10:29:39AM -0800, Jeff Janes wrote:
> On Mon, Nov 5, 2012 at 12:08 PM, Bruce Momjian wrote:
> > Magnus reported that a customer with a million tables was finding
> > pg_upgrade slow. I had never considered many table to be a problem, but
> > decided to test it. I created
On Mon, 2012-11-12 at 10:29 -0800, Jeff Janes wrote:
> When I'm doing a pg_upgrade with thousands of tables, the shutdown
> checkpoint after restoring the dump to the new cluster takes a very
> long time, as the writer drains its operation table by opening and
> individually fsync-ing thousands of
On Mon, Nov 5, 2012 at 12:08 PM, Bruce Momjian wrote:
> Magnus reported that a customer with a million tables was finding
> pg_upgrade slow. I had never considered many table to be a problem, but
> decided to test it. I created a database with 2k tables like this:
>
> CREATE TABLE test19
On Mon, Nov 5, 2012 at 03:08:17PM -0500, Bruce Momjian wrote:
> Magnus reported that a customer with a million tables was finding
> pg_upgrade slow. I had never considered many table to be a problem, but
> decided to test it. I created a database with 2k tables like this:
>
> CREATE TABLE
On 11/05/2012 08:52 PM, Bruce Momjian wrote:
On Mon, Nov 5, 2012 at 05:39:40PM -0800, Josh Berkus wrote:
Sorry, I should've said psql --single-transaction. Although that isn't
going to work either given the presence of \connect commands in the
script. I wonder whether pg_dumpall ought to hav
On Mon, Nov 5, 2012 at 05:39:40PM -0800, Josh Berkus wrote:
>
> > Sorry, I should've said psql --single-transaction. Although that isn't
> > going to work either given the presence of \connect commands in the
> > script. I wonder whether pg_dumpall ought to have some sort of "one
> > transactio
> Sorry, I should've said psql --single-transaction. Although that isn't
> going to work either given the presence of \connect commands in the
> script. I wonder whether pg_dumpall ought to have some sort of "one
> transaction per database please" option.
pg_dumpall ought to support -Fc output
Bruce Momjian writes:
> That could generate a lot of WAL files if used regularly. :-( Does
> SELECT txid_current() generate WAL? I think it does.
Well, it assigns a XID. I'm not sure it'd be a good idea to assume that
the mere act of doing that, without actually writing anything to tables,
wo
On Mon, Nov 5, 2012 at 12:14 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Magnus reported that a customer with a million tables was finding
>> pg_upgrade slow.
>
> You sure there's not an O(N^2) issue in there somewhere?
There certainly will be before he gets to a million, but it probably
does
On Mon, Nov 5, 2012 at 1:39 PM, Robert Haas wrote:
> On Mon, Nov 5, 2012 at 4:33 PM, Alvaro Herrera
> wrote:
>> AFAIR any transaction that modifies catalogs gets sync commit forcibly,
>> regardless of the setting. And sync commit means you get to wait for
>> all previous transactions to be flus
On Mon, Nov 05, 2012 at 04:42:56PM -0500, Bruce Momjian wrote:
> On Mon, Nov 5, 2012 at 04:39:27PM -0500, Robert Haas wrote:
> > On Mon, Nov 5, 2012 at 4:33 PM, Alvaro Herrera
> > wrote:
> > > AFAIR any transaction that modifies catalogs gets sync commit forcibly,
> > > regardless of the setting
On Mon, Nov 5, 2012 at 4:42 PM, Bruce Momjian wrote:
> On Mon, Nov 5, 2012 at 04:39:27PM -0500, Robert Haas wrote:
>> On Mon, Nov 5, 2012 at 4:33 PM, Alvaro Herrera
>> wrote:
>> > AFAIR any transaction that modifies catalogs gets sync commit forcibly,
>> > regardless of the setting. And sync c
On Mon, Nov 5, 2012 at 04:39:27PM -0500, Robert Haas wrote:
> On Mon, Nov 5, 2012 at 4:33 PM, Alvaro Herrera
> wrote:
> > AFAIR any transaction that modifies catalogs gets sync commit forcibly,
> > regardless of the setting. And sync commit means you get to wait for
> > all previous transaction
On Mon, Nov 5, 2012 at 4:33 PM, Alvaro Herrera wrote:
> AFAIR any transaction that modifies catalogs gets sync commit forcibly,
> regardless of the setting. And sync commit means you get to wait for
> all previous transactions to be flushed as well. So simply creating a
> temp table ought to do
On Mon, Nov 5, 2012 at 06:33:16PM -0300, Alvaro Herrera wrote:
> Bruce Momjian escribió:
> > On Mon, Nov 5, 2012 at 04:14:47PM -0500, Robert Haas wrote:
> > > On Mon, Nov 5, 2012 at 4:07 PM, Jeff Janes wrote:
> > > > Or have options for pg_dump and pg_restore to insert "set
> > > > synchronous_c
Bruce Momjian escribió:
> On Mon, Nov 5, 2012 at 04:14:47PM -0500, Robert Haas wrote:
> > On Mon, Nov 5, 2012 at 4:07 PM, Jeff Janes wrote:
> > > Or have options for pg_dump and pg_restore to insert "set
> > > synchronous_commit=off" into the SQL stream?
> >
> > It would be kind of neat if we ha
On Mon, Nov 5, 2012 at 01:23:58PM -0800, Jeff Janes wrote:
> On Mon, Nov 5, 2012 at 1:14 PM, Robert Haas wrote:
> > On Mon, Nov 5, 2012 at 4:07 PM, Jeff Janes wrote:
> >> Or have options for pg_dump and pg_restore to insert "set
> >> synchronous_commit=off" into the SQL stream?
> >
> > It would
On Mon, Nov 5, 2012 at 1:14 PM, Robert Haas wrote:
> On Mon, Nov 5, 2012 at 4:07 PM, Jeff Janes wrote:
>> Or have options for pg_dump and pg_restore to insert "set
>> synchronous_commit=off" into the SQL stream?
>
> It would be kind of neat if we had a command that would force all
> previously-as
On Mon, Nov 5, 2012 at 04:14:47PM -0500, Robert Haas wrote:
> On Mon, Nov 5, 2012 at 4:07 PM, Jeff Janes wrote:
> > Or have options for pg_dump and pg_restore to insert "set
> > synchronous_commit=off" into the SQL stream?
>
> It would be kind of neat if we had a command that would force all
> p
On Mon, Nov 5, 2012 at 4:07 PM, Jeff Janes wrote:
> Or have options for pg_dump and pg_restore to insert "set
> synchronous_commit=off" into the SQL stream?
It would be kind of neat if we had a command that would force all
previously-asynchronous commits to complete. It seems likely that
very, v
On Mon, Nov 5, 2012 at 01:07:45PM -0800, Jeff Janes wrote:
> On Mon, Nov 5, 2012 at 12:49 PM, Bruce Momjian wrote:
> > On Mon, Nov 5, 2012 at 03:30:32PM -0500, Tom Lane wrote:
> >> Magnus Hagander writes:
> >> > On Mon, Nov 5, 2012 at 9:14 PM, Tom Lane wrote:
> >> >> BTW, does pg_upgrade run p
On Mon, Nov 5, 2012 at 12:49 PM, Bruce Momjian wrote:
> On Mon, Nov 5, 2012 at 03:30:32PM -0500, Tom Lane wrote:
>> Magnus Hagander writes:
>> > On Mon, Nov 5, 2012 at 9:14 PM, Tom Lane wrote:
>> >> BTW, does pg_upgrade run pg_restore in --single-transaction mode?
>> >> That would probably make
On Mon, Nov 5, 2012 at 10:01:22PM +0100, Magnus Hagander wrote:
> On Mon, Nov 5, 2012 at 9:49 PM, Bruce Momjian wrote:
>
> On Mon, Nov 5, 2012 at 03:30:32PM -0500, Tom Lane wrote:
> > Magnus Hagander writes:
> > > On Mon, Nov 5, 2012 at 9:14 PM, Tom Lane wrote:
> > >> BTW, doe
On Mon, Nov 5, 2012 at 9:49 PM, Bruce Momjian wrote:
> On Mon, Nov 5, 2012 at 03:30:32PM -0500, Tom Lane wrote:
> > Magnus Hagander writes:
> > > On Mon, Nov 5, 2012 at 9:14 PM, Tom Lane wrote:
> > >> BTW, does pg_upgrade run pg_restore in --single-transaction mode?
> > >> That would probably
On Mon, Nov 5, 2012 at 03:30:32PM -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > On Mon, Nov 5, 2012 at 9:14 PM, Tom Lane wrote:
> >> BTW, does pg_upgrade run pg_restore in --single-transaction mode?
> >> That would probably make synchronous_commit moot, at least for that
> >> step.
>
> >
Magnus Hagander writes:
> On Mon, Nov 5, 2012 at 9:14 PM, Tom Lane wrote:
>> BTW, does pg_upgrade run pg_restore in --single-transaction mode?
>> That would probably make synchronous_commit moot, at least for that
>> step.
> It doesn't use pg_restore at all - it uses the dump from pg_dumpall, wh
On Mon, Nov 5, 2012 at 9:14 PM, Tom Lane wrote:
> Bruce Momjian writes:
> > Magnus reported that a customer with a million tables was finding
> > pg_upgrade slow.
>
> You sure there's not an O(N^2) issue in there somewhere?
> > I don't see anything unsafe about having pg_upgrade use
> > synchr
Bruce Momjian writes:
> Magnus reported that a customer with a million tables was finding
> pg_upgrade slow.
You sure there's not an O(N^2) issue in there somewhere?
> I don't see anything unsafe about having pg_upgrade use
> synchronous_commit=off.
No objection, but this seems unlikely to be b
34 matches
Mail list logo
