"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Dimitri Fontaine wrote:
> -- Start of PGP signed section.
>> Hi,
>>
>> Le jeudi 31 janvier 2008, Tom Lane a ?crit?:
>> > We have *never* promised that pg_dump version N could dump from server
>> > version N+1 .., in fact, personally I'd like to make t
Le jeudi 31 janvier 2008, Tom Lane a écrit :
> I'm thinking next major. In principle there could be cases where a
> minor update could break pg_dump, but it seems unlikely enough that
> it's not reasonable to embed such a policy in the code. As for
> next major, though, the mere existence of the
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> Le jeudi 31 janvier 2008, Tom Lane a écrit :
>> We have *never* promised that pg_dump version N could dump from server
>> version N+1 .., in fact, personally I'd like to make that case be a hard
>> error, rather than something people could override w
Dimitri Fontaine wrote:
-- Start of PGP signed section.
> Hi,
>
> Le jeudi 31 janvier 2008, Tom Lane a ?crit?:
> > We have *never* promised that pg_dump version N could dump from server
> > version N+1 .., in fact, personally I'd like to make that case be a hard
> > error, rather than something pe
Hi,
Le jeudi 31 janvier 2008, Tom Lane a écrit :
> We have *never* promised that pg_dump version N could dump from server
> version N+1 .., in fact, personally I'd like to make that case be a hard
> error, rather than something people could override with -i.
Are you thinking about next major or m
On Thu, 2008-01-31 at 11:20 -0300, Alvaro Herrera wrote:
> > Tom Lane wrote:
>
> > > in fact, personally I'd like to make that case be a hard error,
> > > rather than something people could override with -i.
>
> +1 to this idea. TODO for 8.4?
-1 without some more planning about the effects and
> Tom Lane wrote:
> > in fact, personally I'd like to make that case be a hard error,
> > rather than something people could override with -i.
+1 to this idea. TODO for 8.4?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custo
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, but keep in mind if we use synchronized_seqscans in pg_dump we will
> > have to recognize that GUC forever.
>
> No, because it's being used on the query side, not in the emitted dump.
> We have *never* promised that pg_dump versio
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, but keep in mind if we use synchronized_seqscans in pg_dump we will
> have to recognize that GUC forever.
No, because it's being used on the query side, not in the emitted dump.
We have *never* promised that pg_dump version N could dump from server
v
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Another question --- why don't we just turn off synchronized_seqscans
> > when we do COPY TO? That would fix pg_dump and be transparent.
>
> Enforcing this from the server side seems a pretty bad idea. Note that
> there were squawks
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Another question --- why don't we just turn off synchronized_seqscans
> when we do COPY TO? That would fix pg_dump and be transparent.
Enforcing this from the server side seems a pretty bad idea. Note that
there were squawks about having pg_dump behave
Bruce Momjian wrote:
> Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > I'm still not very happy with any of the options here.
> >
> > > BAS is great if you didn't want to trash the cache, but its also
> > > annoying to people that really did want to load a large table into
> > >
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I'm still not very happy with any of the options here.
>
> > BAS is great if you didn't want to trash the cache, but its also
> > annoying to people that really did want to load a large table into
> > cache. However we set it, we're goi
On Wed, 2008-01-30 at 18:42 +, Heikki Linnakangas wrote:
> Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> >> I'm still not very happy with any of the options here.
> >
> >> BAS is great if you didn't want to trash the cache, but its also
> >> annoying to people that really did w
Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
I'm still not very happy with any of the options here.
BAS is great if you didn't want to trash the cache, but its also
annoying to people that really did want to load a large table into
cache. However we set it, we're going to have prob
Simon Riggs <[EMAIL PROTECTED]> writes:
> I'm still not very happy with any of the options here.
> BAS is great if you didn't want to trash the cache, but its also
> annoying to people that really did want to load a large table into
> cache. However we set it, we're going to have problems because
On Mon, 2008-01-28 at 16:21 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Rather than having a boolean GUC, we should have a number and make the
> > parameter "synchronised_scan_threshold".
>
> This would open up a can of worms I'd prefer not to touch, having to do
> with wh
On Mon, 2008-01-28 at 16:21 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Rather than having a boolean GUC, we should have a number and make the
> > parameter "synchronised_scan_threshold".
>
> This would open up a can of worms I'd prefer not to touch, having to do
> with wh
Simon Riggs <[EMAIL PROTECTED]> writes:
> Rather than having a boolean GUC, we should have a number and make the
> parameter "synchronised_scan_threshold".
This would open up a can of worms I'd prefer not to touch, having to do
with whether the buffer-access-strategy behavior should track that or
On Jan 28, 2008, at 6:14 PM, Simon Riggs wrote:
On Sun, 2008-01-27 at 21:04 -0500, Tom Lane wrote:
[ redirecting thread to -hackers ]
Neil Conway <[EMAIL PROTECTED]> writes:
On Sun, 2008-01-27 at 21:54 +, Gregory Stark wrote:
I liked the "synchronized_sequential_scans" idea myself.
I
On Sun, 2008-01-27 at 21:04 -0500, Tom Lane wrote:
> [ redirecting thread to -hackers ]
>
> Neil Conway <[EMAIL PROTECTED]> writes:
> > On Sun, 2008-01-27 at 21:54 +, Gregory Stark wrote:
> >> I liked the "synchronized_sequential_scans" idea myself.
>
> > I think that's a bit too long. How ab
> >> I liked the "synchronized_sequential_scans" idea myself.
>
> > I think that's a bit too long. How about "synchronized_scans", or
> > "synchronized_seqscans"?
>
> We have enable_seqscan already, so that last choice seems to fit in.
Yes looks good, how about synchronized_seqscan without plur
Michael Glaesemann <[EMAIL PROTECTED]> writes:
>> Neil Conway <[EMAIL PROTECTED]> writes:
>>> I think that's a bit too long. How about "synchronized_scans", or
>>> "synchronized_seqscans"?
> Would it make sense to match the plural as well?
Actually, the best suggestion I've seen so far is Guillau
On Jan 27, 2008, at 21:04 , Tom Lane wrote:
[ redirecting thread to -hackers ]
Neil Conway <[EMAIL PROTECTED]> writes:
On Sun, 2008-01-27 at 21:54 +, Gregory Stark wrote:
I liked the "synchronized_sequential_scans" idea myself.
I think that's a bit too long. How about "synchronized_sc
[ redirecting thread to -hackers ]
Neil Conway <[EMAIL PROTECTED]> writes:
> On Sun, 2008-01-27 at 21:54 +, Gregory Stark wrote:
>> I liked the "synchronized_sequential_scans" idea myself.
> I think that's a bit too long. How about "synchronized_scans", or
> "synchronized_seqscans"?
We have
25 matches
Mail list logo
