Andrew Dunstan schrieb:
Tom Lane wrote:
Andrew Dunstan writes:
Marko Kreen wrote:
On Sun, Aug 07, 2005 at 12:08:28PM -0400, Tom Lane wrote:
Couple thoughts here --- one, someone upthread suggested
"cyg$(NAME)$(DLSUFFIX" as the proper value for shlib.
.exe's in different directories than .dl
Bruce Momjian writes:
> My proposal is to remove fdatasync and open_datasync, and have have
> fsync _prefer_ fdatasync, and open_sync prefer open_datastync, but fall
> back to fsync and open_sync if the *data* version are not supported.
And this will buy us what, other than lack of flexibility?
Tom Lane wrote:
> Bruce Momjian writes:
> > My proposal is to remove fdatasync and open_datasync, and have have
> > fsync _prefer_ fdatasync, and open_sync prefer open_datastync, but fall
> > back to fsync and open_sync if the *data* version are not supported.
>
> And this will buy us what, othe
Tom Lane wrote:
> Bruce Momjian writes:
> > Marko Kreen wrote:
> >> On same topic:
> >> http://archives.postgresql.org/pgsql-general/2005-07/msg00811.php
> >> Why does win32 PostgreSQL allow data corruption by default?
>
> > It behaves the same on Unix as Win32, and if you have battery-backed
> >
Tom Lane wrote:
> Bruce Momjian writes:
> > No one is every going to do it, so we might as well make the best guess
> > we have. I think any platform where the *data* options are slower than
> > the non-*data* options is broken, and if that logic holds, we might as
> > well just use *data* by def
On Mon, 2005-08-08 at 17:03 -0400, Tom Lane wrote:
>
> That's a decision that hasn't got a shred of evidence to justify
> imposing it on every platform.
This option has its uses on Linux, however. In my testing it's good for
a large speedup (20%) on a 10-client pgbench, and a minor improvement
w
Good catch. I forgot that was in there. I have updated it. Thanks.
---
Brendan Jurd wrote:
> > I apologize that my server was down Monday/Tuesday, rendering the
> > patches queue unavailable. I also apologize that my secon
Bruce Momjian writes:
>> fsync_writethrough only works on Win32 the postgresql.conf should
>> reflect that.
> Right now what wal_sync_method supports isn't clear at all.
Yeah. I think we had a TODO to figure out a way for the assign_hook to
report back exactly which values *are* allowed on the
Joshua D. Drake wrote:
>
> >>>I think we should offer the reliable option by default, and mention the
> >>>fast option for those who have battery-backed cache in the manual.
> >>
> >>But only on Win32?
> >
> >
> > Yes, because that's the only place where that option works, right?
>
> fsync_writ
> I apologize that my server was down Monday/Tuesday, rendering the
> patches queue unavailable. I also apologize that my secondary MX was
> misconfigured, causing some email bounces. I think everything is fixed
> now.
Hi Bruce,
I was checking out the patches queue, and there seems to be a mi
Tom Lane said:
> Kris Jurka <[EMAIL PROTECTED]> writes:
>> Automated performance testing seems like a bad idea for the buildfarm.
>> Consider in my particular case I've got three members that all
>> happen to be running in virtual machines on the same host. What
>> virtualization does for perf
Kris Jurka <[EMAIL PROTECTED]> writes:
> Automated performance testing seems like a bad idea for the buildfarm.
> Consider in my particular case I've got three members that all happen to
> be running in virtual machines on the same host. What virtualization does
> for performance and what happ
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
So the short answer is possibly "You build the tests and we'll run 'em."
The availability of the buildfarm certainly makes it a lot more feasible
to do performance tests on a variety of platforms. So, who wants to
knock som
On Mon, 8 Aug 2005, Andrew Dunstan wrote:
> So the short answer is possibly "You build the tests and we'll run 'em."
>
Automated performance testing seems like a bad idea for the buildfarm.
Consider in my particular case I've got three members that all happen to
be running in virtual machin
Bruce Momjian writes:
> Marko Kreen wrote:
>> On same topic:
>> http://archives.postgresql.org/pgsql-general/2005-07/msg00811.php
>> Why does win32 PostgreSQL allow data corruption by default?
> It behaves the same on Unix as Win32, and if you have battery-backed
> cache, you don't need writethro
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> So the short answer is possibly "You build the tests and we'll run 'em."
The availability of the buildfarm certainly makes it a lot more feasible
to do performance tests on a variety of platforms. So, who wants to
knock something together?
I suppose w
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2005-08-08 at 16:55 -0400, Tom Lane wrote:
>> Considering we don't even have code to do this, much less have expended
>> one day of beta testing on it, back-patching seems a bit premature.
> You provided a patch and explained your testing of it. It
Simon Riggs wrote:
On Mon, 2005-08-08 at 17:44 -0400, Bruce Momjian wrote:
In summary, we added all those wal_sync_method values in hopes of
getting some data on which is best on which platform, but having gone
several years with few reports, I am thinking we should just choose the
best on
Bruce Momjian writes:
> No one is every going to do it, so we might as well make the best guess
> we have. I think any platform where the *data* options are slower than
> the non-*data* options is broken, and if that logic holds, we might as
> well just use *data* by default if we can, which is m
On Mon, 2005-08-08 at 17:44 -0400, Bruce Momjian wrote:
> In summary, we added all those wal_sync_method values in hopes of
> getting some data on which is best on which platform, but having gone
> several years with few reports, I am thinking we should just choose the
> best ones we can and move o
On Mon, 2005-08-08 at 16:55 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Wed, 2005-08-03 at 19:43 -0400, Tom Lane wrote:
> >> We've sort of brushed this problem aside in the past by telling people
> >> they could just retry their transaction ... but why don't we make the
I think we should offer the reliable option by default, and mention the
fast option for those who have battery-backed cache in the manual.
But only on Win32?
Yes, because that's the only place where that option works, right?
fsync_writethrough only works on Win32 the postgresql.conf shoul
Bruce,
> No one is every going to do it, so we might as well make the best guess
> we have. I think any platform where the *data* options are slower than
> the non-*data* options is broken, and if that logic holds, we might as
> well just use *data* by default if we can, which is my proposal.
Ch
On Mon, Aug 08, 2005 at 03:10:54PM -0700, Josh Berkus wrote:
> Marko,
> > Also, why can't win32 be safe without battery-backed cache?
> > I can't see such requirement on other platforms.
>
> Read the referenced message again. It's only an issue if you want to use
> open_datasync. fsync_writet
On Mon, Aug 08, 2005 at 06:02:37PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > I think we should offer the reliable option by default, and mention the
> > fast option for those who have battery-backed cache in the manual.
>
> But only on Win32?
We should do what's possible with what's
Tom Lane wrote:
Bruce Momjian writes:
Peter Eisentraut wrote:
The correct lingo would be standard_conforming_strings. I'm going to change
that.
Sounds good.
No problem here either.
So does that mean for 8.1 it will be:
standard_conforming_strings = on/off
?
Another question
On Mon, Aug 08, 2005 at 06:02:37PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > On Mon, Aug 08, 2005 at 05:38:59PM -0400, Bruce Momjian wrote:
> > > Marko Kreen wrote:
> > > > On Mon, Aug 08, 2005 at 03:56:39PM -0400, Bruce Momjian wrote:
> > > > > Currently, here are the options availab
Marko,
> Also, why can't win32 be safe without battery-backed cache?
> I can't see such requirement on other platforms.
Read the referenced message again. It's only an issue if you want to use
open_datasync. fsync_writethrough should be safe.
--
--Josh
Josh Berkus
Aglio Database Solutions
Marko Kreen wrote:
> On Mon, Aug 08, 2005 at 05:38:59PM -0400, Bruce Momjian wrote:
> > Marko Kreen wrote:
> > > On Mon, Aug 08, 2005 at 03:56:39PM -0400, Bruce Momjian wrote:
> > > > Currently, here are the options available for wal_sync_method:
> > > >
> > > > #wal_sync_method = fsync
Alvaro Herrera wrote:
> On Mon, Aug 08, 2005 at 05:38:59PM -0400, Bruce Momjian wrote:
> > Marko Kreen wrote:
> > > On Mon, Aug 08, 2005 at 03:56:39PM -0400, Bruce Momjian wrote:
> > > > Currently, here are the options available for wal_sync_method:
> > > >
> > > > #wal_sync_method = fsync
On Mon, Aug 08, 2005 at 05:38:59PM -0400, Bruce Momjian wrote:
> Marko Kreen wrote:
> > On Mon, Aug 08, 2005 at 03:56:39PM -0400, Bruce Momjian wrote:
> > > Currently, here are the options available for wal_sync_method:
> > >
> > > #wal_sync_method = fsync# the default varies across plat
In summary, we added all those wal_sync_method values in hopes of
getting some data on which is best on which platform, but having gone
several years with few reports, I am thinking we should just choose the
best ones we can and move on, rather than expose a confusing API to the
users.
Does anyon
Marko Kreen wrote:
> On Mon, Aug 08, 2005 at 03:56:39PM -0400, Bruce Momjian wrote:
> > Currently, here are the options available for wal_sync_method:
> >
> > #wal_sync_method = fsync# the default varies across platforms:
> > # fsync, fdatasync, fsyn
Tom Lane wrote:
> Bruce Momjian writes:
> > Currently, here are the options available for wal_sync_method:
> > #wal_sync_method = fsync# the default varies across platforms:
> > # fsync, fdatasync, fsync_writethrough,
> >
Magnus Hagander wrote:
>
> > > > > I fail to see how this is better than just editing the
> > > > file. Because
> > > > > it basically *is* a file editing function limited to
> > pg_hba.conf.
> > > > > Perhaps what we need is a file reader/writer that is
> > > > hardcoded to the
> > > > > pg_hba
Bruce Momjian writes:
> Currently, here are the options available for wal_sync_method:
> #wal_sync_method = fsync# the default varies across platforms:
> # fsync, fdatasync, fsync_writethrough,
> # open_sync,
Mark Woodward wrote:
Well, if you want PostgreSQL to act a specific way, then you are going
to
have to set up the defaults somehow, right?
Of course, which is why we could use a global table for most of it.
What if you wish to start the same database cluster with different settings?
Then c
Bruce Momjian writes:
> Peter Eisentraut wrote:
>> The correct lingo would be standard_conforming_strings. I'm going to change
>> that.
> Sounds good.
No problem here either.
> Another question is whether this should be backpatched to
> our next 7.4.X or 8.0.X release as read-only variables.
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Wed, 2005-08-03 at 19:43 -0400, Tom Lane wrote:
>> We've sort of brushed this problem aside in the past by telling people
>> they could just retry their transaction ... but why don't we make the
>> database do the retrying? I'm envisioning something lik
>> Well, if you want PostgreSQL to act a specific way, then you are going
>> to
>> have to set up the defaults somehow, right?
>
> Of course, which is why we could use a global table for most of it.
What if you wish to start the same database cluster with different settings?
>
>>
>> Which is clea
On Mon, Aug 08, 2005 at 03:56:39PM -0400, Bruce Momjian wrote:
> Currently, here are the options available for wal_sync_method:
>
> #wal_sync_method = fsync# the default varies across platforms:
> # fsync, fdatasync, fsync_writethrough,
>
On Wed, 2005-08-03 at 19:43 -0400, Tom Lane wrote:
> I was reminded again today of the problem that once a database has been
> in existence long enough for the OID counter to wrap around, people will
> get occasional errors due to OID collisions, eg
>
> http://archives.postgresql.org/pgsql-general
Josh Berkus wrote:
Josh,
My actual point was that we could put a lot of the options in a global
table that could be adjusted versus having the flat file.
You were aware of the virtual view pg_settings, right?
Yes and show all.
I've considered before adjusting pg_settings so that it wou
Currently, here are the options available for wal_sync_method:
#wal_sync_method = fsync# the default varies across platforms:
# fsync, fdatasync, fsync_writethrough,
# open_sync, open_datasync
I don't
Peter Eisentraut wrote:
> Am Mittwoch, 3. August 2005 15:40 schrieb Oliver Jowett:
> > The impression I got from previous discussion was that you need to check
> > the value of the standard_compliant_strings GUC, and double backslashes
> > inside '' only if it was false or missing.
>
> The correct
Josh Berkus writes:
> I've considered before adjusting pg_settings so that it would take
> UPDATEs and convert them to SET statements.
Uh, it's always done that. The issue here would be making it do
something with more persistent effect than a SET.
regards, tom lane
---
I returned from OSCON on Saturday. My impression is that we continue to
be a large player in the open source community. Years ago, we were
considered a minor player, but at this OSCON we had two tutorials, 5-6
sessions, a BOF, and field trip, which is impressive. At the BOF we had
four sizeable
On 2005-08-08, Josh Berkus wrote:
> I've considered before adjusting pg_settings so that it would take UPDATEs
> and convert them to SET statements. However, I'm not really sure what the
> benefit of this would be.
It's done that (via rules) since at least as far back as 7.4, no?
(Though it s
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>
>>*) there is no backslash command for getting a list of Roles (like \du &
>>\dg for Users and Groups) - I'm considering using \dr for that - does
>>that sound sensible ?
>
>
> We could just recycle \du and/or \dg for the purpo
Josh,
> > My actual point was that we could put a lot of the options in a global
> > table that could be adjusted versus having the flat file.
You were aware of the virtual view pg_settings, right?
I've considered before adjusting pg_settings so that it would take UPDATEs and
convert them to SE
Dave Page wrote:
> > With this change, editing ph_hba.conf by hand should only be done when
> > the database is down...
>
> Don't tell me, tell all the users that log bugs when their changes get
> lost because they didn't read that bit of the manual for whatever
> version this might or might not e
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> My actual point was that we could put a lot of the options in a global
> table that could be adjusted versus having the flat file.
[ shrug... ] Then we would have two incompatible mechanisms instead of one.
(We can't eliminate the flat file complet
Well, if you want PostgreSQL to act a specific way, then you are going to
have to set up the defaults somehow, right?
Of course, which is why we could use a global table for most of it.
Which is cleaner? Using a configuration file which is going to be there
anyway, or trying to rig-up some so
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
As I have been laboring over the documentation of the postgresql.conf
file for 8.1dev it seems that it may be useful to rip out most of the
options in this file?
What? The contents of postgresql.conf *are* documentation.
Yes t
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> All in all, Tatsuo is right in that there's no way to know what tuples
> are locked without scanning the whole table.
Sure. I was just questioning how much one needs to know that. It seems
to me that the only time you really care is when you are inves
On Sun, Aug 07, 2005 at 09:46:08PM +0900, Tatsuo Ishii wrote:
> With a help from Bruce, I wrote a small function which returns row
> locking information(see attached file if you are interested).
A quick note: it's easier to build tuples using heap_form_tuple instead
of BuildTupleFromCStrings.
--
On Mon, Aug 08, 2005 at 10:26:12AM -0400, Tom Lane wrote:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > If I understand correctly, it seems the above method does show a
> > locked row's TID which does not block someone else. That is a little
> > bit different from what I expcted.
>
> Well, it *co
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > If I understand correctly, it seems the above method does show a
> > locked row's TID which does not block someone else. That is a little
> > bit different from what I expcted.
>
> Well, it *could* be blocking someone else. If there were more than on
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> If I understand correctly, it seems the above method does show a
> locked row's TID which does not block someone else. That is a little
> bit different from what I expcted.
Well, it *could* be blocking someone else. If there were more than one
waiter for
> Hello,
>
> As I have been laboring over the documentation of the postgresql.conf
> file for 8.1dev it seems that it may be useful to rip out most of the
> options in this file?
>
> Considering many of the options can already be altered using SET why
> not make it the default for many of them?
>
>
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > With a help from Bruce, I wrote a small function which returns row
> > locking information(see attached file if you are interested).
>
> Scanning the whole table seems a bit slow :-(
Yes, but I couldn't find any other way.
> There is another possibi
61 matches
Mail list logo
