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
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
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-forcing fixes
On Jun 4, 2014 8:52 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas wrote
On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane lt;
tgl@.pa
gt; 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,
On 06/04/2014 03:50 PM, Robert Haas wrote:
On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane t...@sss.pgh.pa.us 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
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 do
Andres Freund and...@2ndquadrant.com 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
On Wed, Jun 4, 2014 at 9:52 PM, Andres Freund and...@2ndquadrant.com 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
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
Greg Stark st...@mit.edu 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
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 course, if we do
On Wed, Jun 4, 2014 at 4:37 PM, Andrew Dunstan and...@dunslane.net wrote:
On 06/04/2014 03:50 PM, Robert Haas wrote:
On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control. And neither one
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 4, 2014 at 4:37 PM, Andrew Dunstan and...@dunslane.net 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
I wrote:
Robert Haas robertmh...@gmail.com 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
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 opens for pushing
David G Johnston david.g.johns...@gmail.com 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
Stephen Frost sfr...@snowman.net writes:
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost sfr...@snowman.net wrote:
Would this make sense as a configure-time check, rather than initdb, to
try blocking SIGSYS and checking for an ENOSYS from
On 2013-10-24 13:13:23 -0400, Tom Lane wrote:
Stephen Frost sfr...@snowman.net 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
On Thu, Oct 24, 2013 at 1:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Stephen Frost sfr...@snowman.net writes:
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost sfr...@snowman.net wrote:
Would this make sense as a configure-time check, rather than
On Tue, Oct 22, 2013 at 10:07 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 22, 2013 at 10:07 PM, Tom Lane t...@sss.pgh.pa.us 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
* 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
Stephen Frost sfr...@snowman.net 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
* 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,
On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost sfr...@snowman.net 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:
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost sfr...@snowman.net 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
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
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodondt=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.
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
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
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
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 of
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
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 to be
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 enough alone?
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 files
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,
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 of
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 no
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
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
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
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--
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)---
TIP
'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, tom lane
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'll
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
need
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
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 wrapping process
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
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:
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 only,
, 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 appears to be no way to avoid
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
*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
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 the only one
[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 psuedo count
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 to insert
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 advantage of this
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 your
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
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 ?
Then
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 that
[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 there'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 this
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 simply
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(*)
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 each row is
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 by
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
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 $column ORDER BY $column
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
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
76 matches
Mail list logo
