David G Johnston writes:
> If we are planning on keeping this rule, which it seems like at least a few
> people feel is too stringent, maybe we can consider releasing an Alpha
> version and communicate the expectation that an initdb will be required to
> go from the alpha to beta1. Then hopefully
Stefan Kaltenbrunner wrote
> On 06/04/2014 08:56 PM, Joshua D. Drake wrote:
>>
>> On 06/04/2014 11:52 AM, Tom Lane wrote:
>>
>>> I think we could possibly ship 9.4 without fixing this, but it would be
>>> imprudent. Anyone think differently?
>>>
>>> Of course, if we do fix this then the door ope
I wrote:
> Robert Haas writes:
>> I think that's worth considering. Another idea is: suppose we set up
>> a PostgreSQL database somewhere that contained information about what
>> controldata layout corresponded to what control version:
> That seems possibly workable.
BTW, a possibly-easier-to-i
Robert Haas writes:
> On Wed, Jun 4, 2014 at 4:37 PM, Andrew Dunstan wrote:
>> I agree it's scary but in a few minutes thinking about it I haven't been
>> able to come up with a good way of checking it. Maybe we could build
>> sizeof(ControlData) into the version number, so instead of 937 we'd ha
On Wed, Jun 4, 2014 at 4:37 PM, Andrew Dunstan wrote:
> On 06/04/2014 03:50 PM, Robert Haas wrote:
>> On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane wrote:
>>> I just noticed that we had not one, but two commits in 9.4 that added
>>> fields to pg_control. And neither one changed PG_CONTROL_VERSION.
>>
On Wed, Jun 04, 2014 at 09:16:36PM +0200, Stefan Kaltenbrunner wrote:
> On 06/04/2014 08:56 PM, Joshua D. Drake wrote:
> > On 06/04/2014 11:52 AM, Tom Lane wrote:
> >> I think we could possibly ship 9.4 without fixing this, but it would be
> >> imprudent. Anyone think differently?
> >>
> >> Of cou
Greg Stark writes:
> Fwiw I tried to use the pg_lsn data type the other day and pretty much
> immediately ran into the lack of the btree operator class. Pretty much
> the first thing I did when I loaded the data was "select ... order by
> lsn".
Agreed, now that we're going to force an initdb anyw
On 2014-06-04 17:03:52 -0400, Tom Lane wrote:
> Actually, that statement makes me realize that if we fix
> PG_CONTROL_VERSION then it's a good idea to *also* do some regular catalog
> changes, or at least bump catversion. Otherwise pg_upgrade won't be able to
> cope with upgrading non-default tabl
On Wed, Jun 4, 2014 at 9:52 PM, Andres Freund wrote:
> Other things I'd like to change in that case:
Fwiw I tried to use the pg_lsn data type the other day and pretty much
immediately ran into the lack of the btree operator class. Pretty much
the first thing I did when I loaded the data was "sel
Andres Freund writes:
> On 2014-06-04 14:52:35 -0400, Tom Lane wrote:
>> I think we could possibly ship 9.4 without fixing this, but it would be
>> imprudent. Anyone think differently?
> Agreed. Additionally I also agree with Stefan that the price of a initdb
> during beta isn't that high these
Hi,
On 2014-06-04 14:52:35 -0400, Tom Lane wrote:
> I think we could possibly ship 9.4 without fixing this, but it would be
> imprudent. Anyone think differently?
Agreed. Additionally I also agree with Stefan that the price of a initdb
during beta isn't that high these days.
> Of course, if we
On 06/04/2014 03:50 PM, Robert Haas wrote:
On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane wrote:
I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control. And neither one changed PG_CONTROL_VERSION.
This is inexcusable sloppiness on the part of the committers invol
Robert Haas wrote
> On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane <
> tgl@.pa
> > wrote:
>> I just noticed that we had not one, but two commits in 9.4 that added
>> fields to pg_control. And neither one changed PG_CONTROL_VERSION.
>> This is inexcusable sloppiness on the part of the committers involv
On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane wrote:
> I just noticed that we had not one, but two commits in 9.4 that added
> fields to pg_control. And neither one changed PG_CONTROL_VERSION.
> This is inexcusable sloppiness on the part of the committers involved,
> but the question is what do we do
On Jun 4, 2014 8:52 PM, "Tom Lane" wrote:
>
> I just noticed that we had not one, but two commits in 9.4 that added
> fields to pg_control. And neither one changed PG_CONTROL_VERSION.
> This is inexcusable sloppiness on the part of the committers involved,
> but the question is what do we do now?
On 06/04/2014 08:56 PM, Joshua D. Drake wrote:
>
> On 06/04/2014 11:52 AM, Tom Lane wrote:
>
>> I think we could possibly ship 9.4 without fixing this, but it would be
>> imprudent. Anyone think differently?
>>
>> Of course, if we do fix this then the door opens for pushing other
>> initdb-forci
On 06/04/2014 11:52 AM, Tom Lane wrote:
I think we could possibly ship 9.4 without fixing this, but it would be
imprudent. Anyone think differently?
Of course, if we do fix this then the door opens for pushing other
initdb-forcing fixes into 9.4beta2, such as the LOBLKSIZE addition
that I was
I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control. And neither one changed PG_CONTROL_VERSION.
This is inexcusable sloppiness on the part of the committers involved,
but the question is what do we do now?
Quick experimentation says that you don't really ge
On Thu, Oct 24, 2013 at 1:13 PM, Tom Lane wrote:
> Stephen Frost writes:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>>> On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost wrote:
Would this make sense as a configure-time check, rather than initdb, to
try blocking SIGSYS and checking f
On 2013-10-24 13:13:23 -0400, Tom Lane wrote:
> Stephen Frost writes:
> The above patch ignores SIGSYS throughout initdb. We could narrow the
> possible side-effects by only disabling SIGSYS around the shm_open call,
> but I'm not sure there's any value in that. It seems likely to me that
> the
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost wrote:
>>> Would this make sense as a configure-time check, rather than initdb, to
>>> try blocking SIGSYS and checking for an ENOSYS from shm_open()? Seems
>>> preferrable to
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost wrote:
> > Would this make sense as a configure-time check, rather than initdb, to
> > try blocking SIGSYS and checking for an ENOSYS from shm_open()? Seems
> > preferrable to do that in a configure che
On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I agree with Robert that it's odd and obnoxious that the call doesn't just
>> return with errno = ENOSYS. However, looking in the archives turns up
>> this interesting historical info:
>> http://www
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I agree with Robert that it's odd and obnoxious that the call doesn't just
> return with errno = ENOSYS. However, looking in the archives turns up
> this interesting historical info:
> http://www.postgresql.org/message-id/25564.962066...@sss.pgh.pa.us
Wow,
Stephen Frost writes:
> I'm going to guess this idea is a non-starter, but any hope there's some
> other system call which would tell us we're on a platform where
> shm_open() will hit us with SIGSYS? What happens when shm_unlink() is
> called on this platform? Or mmap()?
For context's sake, th
* Robert Haas (robertmh...@gmail.com) wrote:
> I don't think a configure-time test is a good idea because there's no
> guarantee that the configure-time machine and the run-time machine
> have the same behavior. But having initdb fork a child process to run
> the test seems like a reasonable way f
Robert Haas writes:
> On Tue, Oct 22, 2013 at 10:07 PM, Tom Lane wrote:
>> selecting dynamic shared memory implementation ... Bad system call(coredump)
> Well, geez. That's obnoxious.
I quite agree :-(. If it were just this old HPUX version, maybe we could
write it off as something we don't c
On Tue, Oct 22, 2013 at 10:07 PM, Tom Lane wrote:
> initdb.c quoth:
>
> * ... but the fact that a platform has shm_open
> * doesn't guarantee that that call will succeed when attempted.
>
> Indeed:
>
> $ initdb
> The files belonging to this database system will be owned by user "postgres".
> Thi
initdb.c quoth:
* ... but the fact that a platform has shm_open
* doesn't guarantee that that call will succeed when attempted.
Indeed:
$ initdb
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will
I wrote:
> It looks like the MSVC build scripts are cheating by not copying
> parser/gram.h into the include tree where it should be. I'm not
> entirely sure why that has worked at all in the past, but it's
> not working any more.
On further consideration, it's probably not a good idea to let
plp
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodon&dt=2009-04-19%2019:00:00
It looks like the MSVC build scripts are cheating by not copying
parser/gram.h into the include tree where it should be. I'm not
entirely sure why that has worked at all in the past, but it's
not working any more.
Andrew,
> I'd consider replacing them with something clearer, perhaps @< and @> ?
> (i.e. (a @< b) would mean "a is contained by b" and (a @> b) would mean
> "a contains b")
Ltree uses those operators in that way, I believe.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---
On 2005-06-27, Tom Lane <[EMAIL PROTECTED]> wrote:
> I just noticed that these two modules define operator @ as "contains"
> and operator ~ as "contained by", which is opposite to the meanings used
> by every other datatype.
These operators are fundamentally confusing because they give no visual
i
Robert Treat wrote:
> On Sunday 26 June 2005 21:23, Tom Lane wrote:
> > I just noticed that these two modules define operator @ as "contains"
> > and operator ~ as "contained by", which is opposite to the meanings used
> > by every other datatype.
> >
> > Is it better to fix this or leave well enou
On Sunday 26 June 2005 21:23, Tom Lane wrote:
> I just noticed that these two modules define operator @ as "contains"
> and operator ~ as "contained by", which is opposite to the meanings used
> by every other datatype.
>
> Is it better to fix this or leave well enough alone?
>
ISTM it will have t
On Sun, 26 Jun 2005, Tom Lane wrote:
I just noticed that these two modules define operator @ as "contains"
and operator ~ as "contained by", which is opposite to the meanings used
by every other datatype.
Is it better to fix this or leave well enough alone?
I'd say for consistencies sake, it
I just noticed that these two modules define operator @ as "contains"
and operator ~ as "contained by", which is opposite to the meanings used
by every other datatype.
Is it better to fix this or leave well enough alone?
regards, tom lane
---(end o
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Okay, I've repackaged it, and temporarily put everything into
> /pub/source/v7.3.6_1 ... if ppl can confirm that I haven't somehow missed
> something again (I rm -rf'd the old build tree and re-cvs exported it, so
> it started clean), I'll move those
Steve Crawford wrote:
Please, don't call it 7.3.6. Streamlining releases is terrible.
7.3.7 or 7.3.6.1 or SOMETHING other than 7.3.6, and just let
7.3.6 be a brown paper bag release (like 6.4.1 was).
There were no code-change differences in this rewrap, so I see no
real need to change the version
On Thursday 04 March 2004 7:28 pm, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Please, don't call it 7.3.6. Streamlining releases is terrible.
> > 7.3.7 or 7.3.6.1 or SOMETHING other than 7.3.6, and just let
> > 7.3.6 be a brown paper bag release (like 6.4.1 was).
>
> There were
On Friday 05 March 2004 09:50 am, Mark Gibson wrote:
> How about in future, packaging it all up as a release candidate,
> (ie. 7.4.2-rc1) for a week or so before official final release,
We do this already for major versions. Maybe we should consider this for
minors too.
--
Lamar Owen
Director o
Tom Lane wrote:
Lamar Owen <[EMAIL PROTECTED]> writes:
Please, don't call it 7.3.6. Streamlining releases is terrible. 7.3.7 or
7.3.6.1 or SOMETHING other than 7.3.6, and just let 7.3.6 be a brown paper
bag release (like 6.4.1 was).
There were no code-change differences in this rewrap,
It looks to me like there are now *two* copies of the built manpages in
the 7.3.6 tarball, as well as some extraneous .md5 files:
Only in postgresql-7.3.6/doc: man-7.3.tar.gz
Only in postgresql-7.3.6/doc: man.tar.gz
Only in postgresql-7.3.6/doc: postgres.tar.gz
Only in postgresql-7.3.6: postgresql
> On Thursday 04 March 2004 10:28 pm, Tom Lane wrote:
> > There were no code-change differences in this rewrap, so I see no real
> > need to change the version number.
>
> > The lesson I'd prefer to see us take away from this is that Marc needs
> > to automate his release wrapping process more. T
Lamar Owen wrote:
> On Thursday 04 March 2004 10:28 pm, Tom Lane wrote:
> > There were no code-change differences in this rewrap, so I see no real
> > need to change the version number.
>
> > The lesson I'd prefer to see us take away from this is that Marc needs
> > to automate his release wrappin
On Thursday 04 March 2004 10:28 pm, Tom Lane wrote:
> There were no code-change differences in this rewrap, so I see no real
> need to change the version number.
> The lesson I'd prefer to see us take away from this is that Marc needs
> to automate his release wrapping process more. These sorta m
Lamar Owen <[EMAIL PROTECTED]> writes:
> Please, don't call it 7.3.6. Streamlining releases is terrible. 7.3.7 or
> 7.3.6.1 or SOMETHING other than 7.3.6, and just let 7.3.6 be a brown paper
> bag release (like 6.4.1 was).
There were no code-change differences in this rewrap, so I see no real
On Thursday 04 March 2004 07:45 pm, Marc G. Fournier wrote:
> Okay, I've repackaged it, and temporarily put everything into
> /pub/source/v7.3.6_1 ... if ppl can confirm that I haven't somehow missed
> something again (I rm -rf'd the old build tree and re-cvs exported it, so
> it started clean), I'
'k, replaced with the good ones ...
On Thu, 4 Mar 2004, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > don't know what happen with that last one, but this one looks good:
>
> It looks good to me too, at least the main tar.gz seems correct.
>
> regards,
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> don't know what happen with that last one, but this one looks good:
It looks good to me too, at least the main tar.gz seems correct.
regards, tom lane
---(end of broadcast)---
don't know what happen with that last one, but this one looks good:
svr1# tar tvzpf postgresql-7.3.6.tar.gz | grep postgres.tar.gz
-rw-r--r-- pgsql/wheel 954585 Mar 4 21:33 2004 postgresql-7.3.6/doc/postgres.tar.gz
svr1# tar tvypf postgresql-7.3.6.tar.bz2 | grep postgres.tar.gz
-rw-r--r-- pgsql
k, trying again and trapping all the configure/make output, but other then
putting the files in the _1 directory, the script i the same ...
On Thu, 4 Mar 2004, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > Okay, I've repackaged it, and temporarily put everything into
> > /
Okay, I've repackaged it, and temporarily put everything into
/pub/source/v7.3.6_1 ... if ppl can confirm that I haven't somehow missed
something again (I rm -rf'd the old build tree and re-cvs exported it, so
it started clean), I'll move those files over to 7.3.6 ...
On Thu, 4 Mar 2004, Tom Lan
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Select count(*) could be evaluated against any available index
> sub-tables, since all that is required is to count the rows. That would
> be significantly faster than a full file scan and accurate too.
PostgreSQL stores MVCC information in heap tuples o
ark Kirkwood
Sent: Monday, December 29, 2003 08:36
To: Randolf Richardson
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] *sigh*
*growl* - it sounds like the business...and I was all set to code it,
however after delving into Pg's aggregation structure a bit, it suffers
a fatal flaw :
There
Could certainly do that - a scalar function that returns reltuples from
pg_class. I was hoping to do 2 additional things:
i) provide better accuracy than the last ANALYZE
ii) make it behave like an aggregate
So I wanted to be able to use estimated_count as you would use count, i.e:
SELECT estima
*growl* - it sounds like the business...and I was all set to code it,
however after delving into Pg's aggregation structure a bit, it suffers
a fatal flaw :
There appears to be no way to avoid visiting every row when defining an
aggregate (even if you do nothing on each one) -- which defeats th
"[EMAIL PROTECTED] (Mark Kirkwood)" wrote in
comp.databases.postgresql.hackers:
[sNip]
> How about:
>
> Implement a function "estimated_count" that can be used instead of
> "count". It could use something like the algorithm in
> src/backend/commands/analyze.c to get a reasonably accurate psued
"Christopher Browne <[EMAIL PROTECTED]>" wrote in
comp.databases.postgresql.hackers:
> Martha Stewart called it a Good Thing when Randolf Richardson <[EMAIL PROTECTED]>
> wrote:
[sNip]
>> What about queueing all these updates for a separate
>> low-priority thread? The thread would be t
Shridhar Daithankar wrote:
Something like select reltuples from pg_class where relname='foo'?
Shridhar
[chuckles] - I had envisaged something more accurate that the last
ANALYZE, "estimate_count" would effectively *do* acquire_sample_rows()
then and there for you...
regards
Mark
---
>> The count(*) information can be revisioned too, am I wrong ? I'm able
>> to create a trigger that store the count(*) information in a special
>> table, why not implement the same in a way "builded in" ?
>
> Then every insert or delete would have to lock that count. Nobody else
> would be able t
On Wednesday 03 December 2003 13:59, Mark Kirkwood wrote:
> How about:
>
> Implement a function "estimated_count" that can be used instead of
> "count". It could use something like the algorithm in
> src/backend/commands/analyze.c to get a reasonably accurate psuedo count
> quickly.
>
> The advanta
Fairly good idea IMHO, especially considering Christopher's point
about the unlikeliness of needing an exact count anyway.
Regards, Christoph
>
> How about:
>
> Implement a function "estimated_count" that can be used instead of
> "count". It could use something like the algorithm in
> src/
How about:
Implement a function "estimated_count" that can be used instead of
"count". It could use something like the algorithm in
src/backend/commands/analyze.c to get a reasonably accurate psuedo count
quickly.
The advantage of this approach is that "count" still means (exact)count
(for yo
Martha Stewart called it a Good Thing when Randolf Richardson <[EMAIL PROTECTED]>
wrote:
>>> The count(*) information can be revisioned too, am I wrong ? I'm able
>>> to create a trigger that store the count(*) information in a special
>>> table, why not implement the same in a way "builded in" ?
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> The count(*) information can be revisioned too, am I wrong ? I'm able to
> create a trigger that store the count(*) information in a special table,
> why not implement the same in a way "builded in" ?
Then every insert or delete would have to lock th
Oops! [EMAIL PROTECTED] (Gaetano Mendola) was seen spray-painting on a wall:
> Doug McNaught wrote:
>> Randolf Richardson <[EMAIL PROTECTED]> writes:
>>
>>> What about adding a "total number of rows" value to the
>>> internal header of each table which gets incremented/decremented
>>> after eac
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> Doug McNaught wrote:
>> Because different sessions have a (validly) different concept of what
>> that number should be, due to MVCC.
>
> The count(*) information can be revisioned too, am I wrong ? I'm able to
> create a trigger that store the count(*
Doug McNaught wrote:
Randolf Richardson <[EMAIL PROTECTED]> writes:
What about adding a "total number of rows" value to the internal
header of each table which gets incremented/decremented after each row is
INSERT/DELETE has been committed. This way, a generic "count(*)" by itself
could s
Randolf Richardson <[EMAIL PROTECTED]> writes:
> What about adding a "total number of rows" value to the internal
> header of each table which gets incremented/decremented after each row is
> INSERT/DELETE has been committed. This way, a generic "count(*)" by itself
> could simply return
[sNip]
>> I would add that this is not a bug as much as a feature request.
>> count() works. It may not be as feature
>> filled as we would like (e.g; it won't use an index) but it does work.
>
> count will use an index just fine where it's useful. If you say "select
> count(*) where foo = ?" and
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Greg Stark wrote:
>
> >Thomas Zehetbauer <[EMAIL PROTECTED]> writes:
> >
> >
> >>Also will the BUG which causes postgresql to execute a sequential scan
> >>when using min()/max()/count() ever be fixed? min()/max() can be
> >>rewritten as SELECT $col
Greg Stark wrote:
Thomas Zehetbauer <[EMAIL PROTECTED]> writes:
Also will the BUG which causes postgresql to execute a sequential scan
when using min()/max()/count() ever be fixed? min()/max() can be
rewritten as SELECT $column ORDER BY $column ASC/DESC LIMIT 1 but this
should be done by the d
Thomas Zehetbauer <[EMAIL PROTECTED]> writes:
> Also will the BUG which causes postgresql to execute a sequential scan
> when using min()/max()/count() ever be fixed? min()/max() can be
> rewritten as SELECT $column ORDER BY $column ASC/DESC LIMIT 1 but this
> should be done by the database, NOT
Thomas Zehetbauer writes:
> psql cannot \i a file which name contains a blank character.
\i 'blah blah blah'
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
psql cannot \i a file which name contains a blank character. Why doesn't
it take the rest of the command line as the name of the file?!? Why
doesn't it use any of the standard command line parsing libraries which
respect "quoting" and \e\s\c\a\p\i\n\g?!? psql \i even does autocomplete
to the file n
76 matches
Mail list logo
