Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Ignoring my general dislike of enums, I have a few issues with the patch
> as it is:
> 1. What's the point of having comparison operators for enums? For most
> use cases, there's no natural ordering of enum values.
If you would like to be able to
Magnus Hagander wrote:
Also, it compiles fine on MSVC. I still haven't managed to get the MingW
build environment working properly on Win64 even for building Win32
apps, so I haven't been able to build it on MingW yet. It *should* work
since it's all standard functions, but might require further
On Mon, Dec 18, 2006 at 08:56:22PM -0800, Joshua D. Drake wrote:
> On Mon, 2006-12-18 at 23:46 -0500, Tom Lane wrote:
> > Magnus Hagander <[EMAIL PROTECTED]> writes:
> > > Oh, you mean MB vs Mb. Man, it had to be that simple :)
> >
> > ISTM we had discussed whether guc.c should accept units string
"Simon Riggs" <[EMAIL PROTECTED]> wrote:
> I think what you are saying is: VACUUM places blocks so that they are
> immediately reused. This stops shared_buffers from being polluted by
> vacuumed-blocks, but it also means that almost every write becomes a
> backend dirty write when VACUUM is workin
Magnus Hagander wrote:
> Is it possible to add an error hint to the message? Along the line of
> "HINT: Did you perhaps get your casing wrong" (with better wording,
> of course).
Or how about we just make everything case-insensitive -- but
case-preserving! -- on Windows only?
--
Peter Eisentrau
> > I suspect we might need to create a pg_off_t type or some
> such gadget.
> >
> > Bleah.
> >
> > But it does need to be fixed.
>
> Bummer. That might be what's needed, but I'm going to at least try to
> find some neater way first. I wonder why it didn't happen on MSVC...
I don't see how th
On Tue, Dec 19, 2006 at 10:01:05AM +0100, Peter Eisentraut wrote:
> Magnus Hagander wrote:
> > Is it possible to add an error hint to the message? Along the line of
> > "HINT: Did you perhaps get your casing wrong" (with better wording,
> > of course).
>
> Or how about we just make everything case
On 12/18/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
> Hm, I suppose. Though starting a second gdb is a pain. What I've done in
the
> past is introduce a usleep(3000) in strategic points in the backend
to
> give me a chance to attach.
There is already a
"Takayuki Tsunakawa" <[EMAIL PROTECTED]> wrote:
> I performed some simple tests, and I'll show the results below.
> (1) The default case
> 235 80 226 77 240
> (2) No write case
> 242 250 244 253 280
> (3) No checkpoint case
> 229 252 256 292 276
> (4) No fsync() case
> 236 112 215 2
Heikki Linnakangas wrote:
> I'm sorry I missed the original discussions, but I have to ask: Why
> do we want enums in core? The only potential advantage I can see over
> using a look-up table and FK references is performance.
The difference is that foreign-key-referenced data is part of your data
Hi,
From: "Hiroshi Saito" <[EMAIL PROTECTED]>
Subject: Re: [HACKERS] pg_restore fails with a custom backup file
Date: Fri, 15 Dec 2006 00:57:50 +0900
> > Win32 does not implement fseeko() and ftello(). So I think it limit to
> > handle a 2GB file. Is this a specification?
>
> Yes, Magnus-san sug
Martijn van Oosterhout wrote:
> On Fri, Dec 01, 2006 at 10:37:07AM -0500, Tom Lane wrote:
> > Martijn van Oosterhout writes:
> > > Seems to me that you could just do this by setting stdin to be
> > > /dev/null?
> >
> > No, because the simple_prompt code makes a point of reading from
> > /dev/tty.
Alvaro Herrera wrote:
> So did we get anywhere with this? I'd propose something like
> --non-interactive rather than --daemon-mode. Was there a patch
> submitted?
With the enhanced connection string management, wouldn't it suffice to
pass a (fake/empty) password to pg_dump on the command line?
On Tue, Dec 19, 2006 at 09:59:05PM +0900, Yoshiyuki Asaba wrote:
> Hi,
>
> > > Win32 does not implement fseeko() and ftello(). So I think it limit to
> > > handle a 2GB file. Is this a specification?
> >
> > Yes, Magnus-san suggested the problem. It is present TODO. The entire
> > adjustment wa
one of our customers here found a bug in PL/pgSQL.
this is how you can create this one:
CREATE OR REPLACE FUNCTION "public"."make_victim_history" () RETURNS
trigger AS $body$ DECLARE
schemarec RECORD;
exec_schemaselect text;
curs2 refcursor;
BEGIN
exec_schemaselect := 'SELECT nspname
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
1. What's the point of having comparison operators for enums? For most
use cases, there's no natural ordering of enum values.
If you would like to be able to index enum columns, or even GROUP BY one,
you need those; whether
Hans-Juergen Schoenig wrote:
[...]
a quick fix is to prevent the language from freeing the tuple twice -
this should safely prevent the core dump here.
we still have to make sure that the tuple if freed properly. stay tuned.
here is the patch ...
this seems to be already fixed with:
http://
Magnus Hagander wrote:
On Tue, Dec 19, 2006 at 09:59:05PM +0900, Yoshiyuki Asaba wrote:
Hi,
Win32 does not implement fseeko() and ftello(). So I think it limit to
handle a 2GB file. Is this a specification?
Yes, Magnus-san suggested the problem. It is present TODO. The entire
oh sorry, i think i missed that one ...
many thanks,
hans
On Dec 19, 2006, at 3:42 PM, Stefan Kaltenbrunner wrote:
Hans-Juergen Schoenig wrote:
[...]
a quick fix is to prevent the language from freeing the tuple
twice - this should safely prevent the core dump here.
we still have
Andrew Dunstan wrote:
> As for efficiency, I agree with what Tom says about alignment and
> padding dissolving away any perceived advantage in most cases. If we
> ever get around to optimising record layout we could revisit it.
I don't, because there are always those that are knowledgeable enou
> >However, did you test the actual backend after that change? Given where you
> >change the define of off_t, that would affect every call in the backend
> >that uses off_t, and it just seems very strange that you could get away
> >with that without touching anything else? (If we're lucky, but I
>
Alvaro Herrera wrote:
Andrew Dunstan wrote:
As for efficiency, I agree with what Tom says about alignment and
padding dissolving away any perceived advantage in most cases. If we
ever get around to optimising record layout we could revisit it.
I don't, because there are always those
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I don't, because there are always those that are knowledgeable enough to
> know how to reduce space lost to padding. So it would be nice to have
> 2-byte enums on-disk, and resolve them based on the column's typid. But
> then, I'm not familiar with the
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> I'm not a big fan of ordering columns to optimise record layout, except in the
> most extreme cases (massive DW type apps). I think visible column order should
> be logical, not governed by physical considerations.
Well as long as we're talking "shou
> Did you see this from Andreas?
>
> > MinGW has fseeko64 and ftello64 with off64_t.
> >
>
> Maybe we need separate macros for MSVC and MinGW. Given the other
You mean something quick and dirty like this ? That would work.
Andreas
pg_dump_fseeko64.patch
Description: pg_dump_fseeko64.patc
On Tue, Dec 19, 2006 at 04:25:18PM +0100, Zeugswetter Andreas ADI SD wrote:
>
> > Did you see this from Andreas?
> >
> > > MinGW has fseeko64 and ftello64 with off64_t.
> > >
> >
> > Maybe we need separate macros for MSVC and MinGW. Given the other
>
> You mean something quick and dirty lik
Gregory Stark wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
I'm not a big fan of ordering columns to optimise record layout, except in the
most extreme cases (massive DW type apps). I think visible column order should
be logical, not governed by physical considerations.
Well as
> > > > MinGW has fseeko64 and ftello64 with off64_t.
> > > >
> > >
> > > Maybe we need separate macros for MSVC and MinGW. Given the other
> >
> > You mean something quick and dirty like this ? That would work.
>
> Yes, except does that actually work? If so you found the place in the
> hea
On Tue, Dec 19, 2006 at 10:48:41AM -0500, Andrew Dunstan wrote:
> Sure, but the only sane way I can think of to do that would be have
> separate logical and physical orderings, with a map between the two. I
> guess we'd need to see what the potential space savings would be and
> establish what t
Greetings,
Subject pretty much says it all. I've put up with this error in the
past when it has caused me trouble but it's now starting to hit our
clients on occation which is just unacceptable.
The way I've seen it happen, and this is just empirically so I'm not
sure that it's exactly
I have updated my Synchronized Scan patch and have had more time for
testing.
Go to http://j-davis.com/postgresql/syncscan-results10.html
where you can download the patch, and see the benchmarks that I've run.
The results are very promising. I did not see any significant slowdown
for non-concurre
I have written an article about the complexities of companies
contributing to open source projects:
http://momjian.us/main/writings/pgsql/company_contributions/
If you have any suggestions, please let me know. I am going to add a
link to this from the developer's FAQ.
--
Bruce Momjia
The 8.2.0 release went well. We spent a month more in beta than we
planned, but that time helped to eliminate many bugs, and many that had
existed in previous PostgreSQL major releases as well. We have had very
few bug reports for 8.2.0, and will be doing a minor release in 1-2
weeks to get those
On Tue, 2006-12-19 at 09:07 -0800, Jeff Davis wrote:
> I have updated my Synchronized Scan patch and have had more time for
> testing.
>
> Go to http://j-davis.com/postgresql/syncscan-results10.html
> where you can download the patch, and see the benchmarks that I've run.
>
> The results are very
On Tue, 2006-12-19 at 12:11 -0500, Bruce Momjian wrote:
> I have written an article about the complexities of companies
> contributing to open source projects:
>
> http://momjian.us/main/writings/pgsql/company_contributions/
>
> If you have any suggestions, please let me know. I am going t
On Tue, 2006-12-19 at 17:43 +, Simon Riggs wrote:
> On Tue, 2006-12-19 at 09:07 -0800, Jeff Davis wrote:
> > I have updated my Synchronized Scan patch and have had more time for
> > testing.
> >
> > Go to http://j-davis.com/postgresql/syncscan-results10.html
> > where you can download the patc
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Like to see some tests with 2 parallel threads, since that is the most
> common case. I'd also like to see some tests with varying queries,
> rather than all use select count(*). My worry is that these tests all
> progress along their scans at exactly th
On Tue, 2006-12-19 at 18:05 +, Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > Like to see some tests with 2 parallel threads, since that is the most
> > common case. I'd also like to see some tests with varying queries,
> > rather than all use select count(*). My worry
Joshua D. Drake wrote:
> On Tue, 2006-12-19 at 12:11 -0500, Bruce Momjian wrote:
> > I have written an article about the complexities of companies
> > contributing to open source projects:
> >
> > http://momjian.us/main/writings/pgsql/company_contributions/
> >
> > If you have any suggestions
On Tue, 2006-12-19 at 13:38 -0500, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > On Tue, 2006-12-19 at 12:11 -0500, Bruce Momjian wrote:
> > > I have written an article about the complexities of companies
> > > contributing to open source projects:
> > >
> > > http://momjian.us/main/writings
On 12/20/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Thanks for the feedback, sectioning fixed.
Spelling mistake:
because they have gone though a company process
to
because they have gone *through* a company process
Regards,
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] gmail | hotmail | yahoo
Fixed, thanks.
---
Gurjeet Singh wrote:
> On 12/20/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> > Thanks for the feedback, sectioning fixed.
> >
>
> Spelling mistake:
>
> because they have gone though a company proce
On 12/20/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Fixed, thanks.
Follwing statement seems to be a bit mangled:
then when company('s?) needs diverge, going *it*(?) alone, then returning to
the community process at some later time.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] gmail | hotmail |
Gurjeet Singh wrote:
> On 12/20/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > Fixed, thanks.
> >
>
> Follwing statement seems to be a bit mangled:
>
> then when company('s?) needs diverge, going *it*(?) alone, then returning to
> the community process at some later time.
Thanks, clarified.
Hi,
I think another point you need to bring out more clearily is that the
community is also often "miffed" if they feel they have been left out of
the design and testing phases. This is sometimes just a reflex that is
not always based on technical reasoning. Its just that as you correctly
poi
Hello,
O.k. below are some comments. Your article although well written has a
distinct, from the community perspective ;) and I think there are some
points from the business side that are missed.
---
Employees working in open source communities have two bosses -- the
companies that employ them, a
Joshua D. Drake wrote:
O.k. in all Bruce I like your article but I must admit it seems to take
a "The community is god" perspective and that we must all bend to the
will of said community.
The community could learn a great deal from adopting some of the more
common business practices when it co
On 12/20/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
O.k. in all Bruce I like your article but I must admit it seems to take
a "The community is god" perspective and that we must all bend to the
will of said community.
I'm not really in a position to judge how a company thinks about
"donatin
Magnus Hagander wrote:
We need different macrosand possibly functions, yes.
I think I got enough patched at home last night to get it working with
this, I was just too focused on one set of macros at the time. It's not
enough to include them very late - because off_t is used in the shared
datastr
Andrew Dunstan wrote:
> Magnus Hagander wrote:
>> We need different macrosand possibly functions, yes.
>> I think I got enough patched at home last night to get it working with
>> this, I was just too focused on one set of macros at the time. It's not
>> enough to include them very late - because o
On Wed, 2006-12-20 at 09:51 +1300, Andrej Ricnik-Bay wrote:
> On 12/20/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
>
> > O.k. in all Bruce I like your article but I must admit it seems to take
> > a "The community is god" perspective and that we must all bend to the
> > will of said community.
On 12/20/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
I think my overall thought is the tone seems a bit non-gracious to
companies, when IMO the community should be actively courting companies
to give resources. If companies feel unwelcome, they won't give.
I appreciate that, but then Bruce'
Joshua D. Drake wrote:
I think my overall thought is the tone seems a bit non-gracious to
companies, when IMO the community should be actively courting companies
to give resources. If companies feel unwelcome, they won't give.
I have not been following closely. But IMNSHO we should be stre
On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
> Magnus Hagander wrote:
> > Is it possible to add an error hint to the message? Along the line of
> > "HINT: Did you perhaps get your casing wrong" (with better wording,
> > of course).
>
> Or how about we just make everything case-insens
On Wed, 2006-12-20 at 10:27 +1300, Andrej Ricnik-Bay wrote:
> On 12/20/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
>
> > I think my overall thought is the tone seems a bit non-gracious to
> > companies, when IMO the community should be actively courting companies
> > to give resources. If compa
On Tue, 2006-12-19 at 16:30 -0500, Andrew Dunstan wrote:
> Joshua D. Drake wrote:
> >
> > I think my overall thought is the tone seems a bit non-gracious to
> > companies, when IMO the community should be actively courting companies
> > to give resources. If companies feel unwelcome, they won't giv
On Tue, 2006-12-19 at 13:32 -0800, Joshua D. Drake wrote:
> On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
> > Magnus Hagander wrote:
> > > Is it possible to add an error hint to the message? Along the line of
> > > "HINT: Did you perhaps get your casing wrong" (with better wording,
> >
Joshua D. Drake wrote:
> On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
> > Magnus Hagander wrote:
> > > Is it possible to add an error hint to the message? Along the line of
> > > "HINT: Did you perhaps get your casing wrong" (with better wording,
> > > of course).
> >
> > Or how abou
On Tue, 2006-12-19 at 16:47 -0500, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
> > > Magnus Hagander wrote:
> > > > Is it possible to add an error hint to the message? Along the line of
> > > > "HINT: Did you perhaps get your casing w
Joshua D. Drake wrote:
> + #
> + # Any memory setting may use a shortened notation such as 1024MB or
> 1GB.
> + # Please take note of the case next to the unit size.
> + #
Well, if you add that, you should also list all the other valid units.
But it's quite redundant, because nearly all the para
On Tue, 2006-12-19 at 22:59 +0100, Peter Eisentraut wrote:
> Joshua D. Drake wrote:
> > + #
> > + # Any memory setting may use a shortened notation such as 1024MB or
> > 1GB.
> > + # Please take note of the case next to the unit size.
> > + #
>
> Well, if you add that, you should also list all the
Peter Eisentraut wrote:
> Joshua D. Drake wrote:
>> + #
>> + # Any memory setting may use a shortened notation such as 1024MB or
>> 1GB.
>> + # Please take note of the case next to the unit size.
>> + #
>
> Well, if you add that, you should also list all the other valid units.
> But it's quite r
Bruce Momjian wrote:
> The only value to being case-sensitive in this area is to allow
> upper/lower case with different meanings, but I don't see us using
> that, so why do we bother caring about the case?
Because the units are what they are.
In broader terms, we may one day want to have other u
> > In my mind, this is pretty silly. There is no reputable precedent
> > anywhere for variant capitalization in unit names.
>
> I am not suggestion variant capitalization. I am suggestion a simple
> document patch to help eliminate what may not be obvious.
Good lord... *suggesting*
Joshua D.
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Oh, you mean MB vs Mb. Man, it had to be that simple :)
>
> ISTM we had discussed whether guc.c should accept units strings in
> a case-insensitive manner, and the forces of pedantry won the first
> round. Sh
Magnus Hagander wrote:
> In most cases, I just assume they would just assume
> they can't use units on it because the default value in the file
> doesn't have units.
But the default value *does* have units.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---
Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> In most cases, I just assume they would just assume
>> they can't use units on it because the default value in the file
>> doesn't have units.
>
> But the default value *does* have units.
>
It does? Didn't in my file. I must've overwritten it wi
Lukas Kahwe Smith wrote:
> Hi,
>
> I think another point you need to bring out more clearily is that the
> community is also often "miffed" if they feel they have been left out of
> the design and testing phases. This is sometimes just a reflex that is
> not always based on technical reasoning.
On Tue, 2006-12-19 at 23:39 +0100, Magnus Hagander wrote:
> Peter Eisentraut wrote:
> > Magnus Hagander wrote:
> >> In most cases, I just assume they would just assume
> >> they can't use units on it because the default value in the file
> >> doesn't have units.
> >
> > But the default value *does
Joshua D. Drake wrote:
> I am not suggestion variant capitalization. I am suggestion a simple
> document patch to help eliminate what may not be obvious.
Perhaps it would be more effective to clarify the error message? Right
now it just says something to the effect of "invalid integer". I'd
im
When psql is running and CRTL + \ is pressed, a core dumped show up.
In first place I ran psql into gdb, saw the backtrace and I believed
it was a libc6 bug and I reported to my distro security team
https://launchpad.net/distros/ubuntu/+source/glibc/+bug/76437
Ubuntu edgy has got libc-2.4, a fri
"Kenneth Marshall" <[EMAIL PROTECTED]> writes:
> My one comment is that a little 'b' is used to indicate bits normally
> and a capital 'B' is used to indicate bytes. So
>kb = '1024 bits'
>kB = '1024 bytes'
> I do think that whether or not the k/m/g is upper case or lower case
> is
Mario wrote:
> When psql is running and CRTL + \ is pressed, a core dumped show up.
> In first place I ran psql into gdb, saw the backtrace and I believed
> it was a libc6 bug and I reported to my distro security team
> https://launchpad.net/distros/ubuntu/+source/glibc/+bug/76437
This isn't a bu
On 20/12/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
Mario wrote:
> When psql is running and CRTL + \ is pressed, a core dumped show up.
> In first place I ran psql into gdb, saw the backtrace and I believed
> it was a libc6 bug and I reported to my distro security team
> https://launchpad.n
Mario wrote:
> On 20/12/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
>> Mario wrote:
>> > When psql is running and CRTL + \ is pressed, a core dumped show up.
>> > In first place I ran psql into gdb, saw the backtrace and I believed
>> > it was a libc6 bug and I reported to my distro security t
Gregory Stark wrote:
>
> "Kenneth Marshall" <[EMAIL PROTECTED]> writes:
>
> > My one comment is that a little 'b' is used to indicate bits normally
> > and a capital 'B' is used to indicate bytes. So
> >kb = '1024 bits'
> >kB = '1024 bytes'
> > I do think that whether or not the k
Mario wrote:
Even if you get a core dumped every time you press CTRL+\ ? why?
Try ulimit -c 0, then run it (you should get no core dump)
Then ulimit -c 50, then run it (you should get a core dump)
SIGQUIT is supposed to dump core. Ulimit settings can suppress
generation of core files.
"Mario" <[EMAIL PROTECTED]> writes:
> On 20/12/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> >
> > This isn't a bug. It's working as designed.
>
> Even if you get a core dumped every time you press CTRL+\ ? why?
That's what C-\ does. Try it with any other program:
$ sleep 1
Quit (core d
Joshua D. Drake wrote:
> On Wed, 2006-12-20 at 09:51 +1300, Andrej Ricnik-Bay wrote:
> > On 12/20/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> >
> > > O.k. in all Bruce I like your article but I must admit it seems to take
> > > a "The community is god" perspective and that we must all bend to
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Perhaps it would be more effective to clarify the error message? Right
> now it just says something to the effect of "invalid integer". I'd
> imagine "invalid memory unit: TB" would be less confusing.
+1 on that, but I think we should just accept
The 8.2.0 release went well. We spent a month more in beta than we
planned, but that time helped to eliminate many bugs, and many that had
existed in previous PostgreSQL major releases as well. We have had very
few bug reports for 8.2.0, and will be doing a minor release in 1-2
weeks to get thos
On Wed, 20 Dec 2006, Philip Yarra wrote:
> Mario wrote:
> > Even if you get a core dumped every time you press CTRL+\ ? why?
>
> Try ulimit -c 0, then run it (you should get no core dump)
> Then ulimit -c 50, then run it (you should get a core dump)
>
> SIGQUIT is supposed to dump core. Ul
> > > > The community could learn a great deal from adopting some of the more
> > > > common business practices when it comes to development as well.
> > > >
> > > > In short, I guess I think it is important to recognize that both are
> > > > partners in the open source world and that to ignore on
On Tue, 2006-12-19 at 19:16 -0500, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Perhaps it would be more effective to clarify the error message? Right
> > now it just says something to the effect of "invalid integer". I'd
> > imagine "invalid memory unit: TB" would be less
Jeremy Drake wrote:
> On Wed, 20 Dec 2006, Philip Yarra wrote:
>
> > Mario wrote:
> > > Even if you get a core dumped every time you press CTRL+\ ? why?
> >
> > Try ulimit -c 0, then run it (you should get no core dump)
> > Then ulimit -c 50, then run it (you should get a core dump)
> >
>
Tom Lane wrote:
> Nor do I believe that we'd ever accept a future patch that made
> the distinction between "kb" and "kB" significant --- if you think
> people are confused now, just imagine what would happen then.
As I said elsewhere, I'd imagine future functionality like a units-aware
data type
Joshua D. Drake wrote:
> I compiled and installed, ran an initdb with 32mb (versus 32MB) and
> it seems to work correctly with a show shared_buffers;
Did it actually allocate 32 millibits of shared buffers?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---
Hi Asaba-san.
From: "Yoshiyuki Asaba"
Is it able to use fsetpos()/fgetpos() instead of ftell()/fseek()?
fpos_t is a 8byte type. I tested pg_dump/pg_restore with the attached
patch.
I'm sorry the response ..slowly...my machine reacts for the reasons of
poverty late. Last night.. I was actuall
Tom Lane wrote:
> +1 on that, but I think we should just accept the strings
> case-insensitively, too.
I think if we'd allow this to spread, documentation, example files and
other material would use it inconsistently, and even more people would
be confused and it would make us look silly.
It's
Alvaro Herrera wrote:
I don't, because there are always those that are knowledgeable enough to
know how to reduce space lost to padding. So it would be nice to have
2-byte enums on-disk, and resolve them based on the column's typid. But
then, I'm not familiar with the patch at all so I'm not su
On Wed, 2006-12-20 at 02:19 +0100, Peter Eisentraut wrote:
> Joshua D. Drake wrote:
> > I compiled and installed, ran an initdb with 32mb (versus 32MB) and
> > it seems to work correctly with a show shared_buffers;
>
> Did it actually allocate 32 millibits of shared buffers?
Funny :)
Joshua D. D
Peter Eisentraut wrote:
An objection to enums on the ground that foreign keys can accomplish the
same thing could be extended to object to any data type with a finite
domain.
Exactly. The extreme case is the boolean type, which could easily be
represented by a two-value enum. Or, if you were
On 12/19/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
This actually brings up an important distinction. Joshua is saying that
the community is painted as "god" in the article, and I agree there is a
basis for that, but I don't think you can consider the community and
company as equals either.
> Hello,
>
> Attached is a simple patch that replaces strcmp() with pg_strcasecmp().
> Thanks to AndrewS for pointing out that I shouldn't use strcasecp().
>
That should be AndrewD :)
J
> I compiled and installed, ran an initdb with 32mb (versus 32MB) and it
> seems to work correctly with a
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> I remember the president of Great Bridge
>> saying that the company needs the community, but not visa-vera --- if
>> the company dies, the community keeps going (as it did after Great
>> Bridge, without a hickup), but if the community dies, the compa
On Tue, 2006-12-19 at 22:04 -0500, Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> >> I remember the president of Great Bridge
> >> saying that the company needs the community, but not visa-vera --- if
> >> the company dies, the community keeps going (as it did after Great
> >> Br
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Nor do I believe that we'd ever accept a future patch that made
>> the distinction between "kb" and "kB" significant --- if you think
>> people are confused now, just imagine what would happen then.
> As I said elsewhere, I'd imagin
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> OK, if I understand correctly, instead of doing a buffer scan, write(),
> and fsync(), and recyle the WAL files at checkpoint time, you delay the
> scan/write part with the some delay.
Exactly. Actual behavior of checkpoint is not changed by the patch. C
Joshua D. Drake wrote:
> > I remember the president of Great Bridge
> > saying that the company needs the community, but not visa-vera --- if
> > the company dies, the community keeps going (as it did after Great
> > Bridge, without a hickup), but if the community dies, the company dies
> > too.
> In one fails swoop:
Sorry a beer and email just doesn't mix. The above should be one fell
swoop.
>
> Devrim, Alvaro, Darcy, Heikki, Bruce, Simon, Greg, Dave, Marc and I are
> all suddenly looking for employment...
>
> You don't think there would be an issue that could cause some grief to
> t
1 - 100 of 124 matches
Mail list logo
