- 15 6月, 2011 7 次提交
-
-
由 Peter Eisentraut 提交于
This has always been true, it was just never documented.
-
由 Bruce Momjian 提交于
the same file system, and that authentication should lock out normal users. Per suggestsion from #postgresql irc channel. Backpatch to 9.1.
-
由 Tom Lane 提交于
Apparently there is no buildfarm critter exercising this case after all, because it fails in several places. With this patch, build, install, check-world, and installcheck-world pass for me on OS X.
-
由 Peter Eisentraut 提交于
The variable became obsolete in commit 68739ba8, but only gcc 4.6 shows the warning.
-
由 Peter Eisentraut 提交于
We don't have to remove the column if no one is bothered, but it's useful to comment on it in case someone looks for it in newer standards versions.
-
由 Bruce Momjian 提交于
-
由 Alvaro Herrera 提交于
Per note from Tom
-
- 14 6月, 2011 12 次提交
-
-
由 Alvaro Herrera 提交于
... when talking about how good they are in replacement of bulk DELETE in partitioned setups. The original wording was a bit confusing. Per an observation from David Wheeler.
-
由 Robert Haas 提交于
Per a gripe from Tom Lane.
-
由 Heikki Linnakangas 提交于
renumbered the resource managers. This should fix the buildfarm..
-
由 Heikki Linnakangas 提交于
is added to the end, and existing resource managers keep their old ids. We're not going to guarantee on-disk compatibility for 2PC state files over major releases, but it seems better to avoid changing the ids them anyway. It will help anyone who might want to write external tools to inspect the state files to work with files from different versions, if nothing else. Per complaint from Tom Lane.
-
由 Peter Eisentraut 提交于
We have a SCM, so we don't need to keep old versions of files around.
-
由 Bruce Momjian 提交于
"must".
-
由 Alvaro Herrera 提交于
Spotted by Jaime Casanova
-
由 Alvaro Herrera 提交于
The previous wording wasn't explicit enough, which could misled readers into thinking that the locks acquired are more restricted in nature than they really are. The resulting optimism can be damaging to morale when confronted with reality, as has been observed in the field. Greg Smith
-
由 Robert Haas 提交于
This is more consistent with what we do elsewhere, and hopefully avoids creating the perception that current_schemas takes no arguments. As suggested by Brendan Jurd
-
由 Robert Haas 提交于
As suggested by Grzegorz Szpetkowski.
-
由 Robert Haas 提交于
Brendan Jurd
-
由 Robert Haas 提交于
Fujii Masao
-
- 13 6月, 2011 4 次提交
-
-
由 Robert Haas 提交于
Noted by Daniele Varrazzo.
-
由 Robert Haas 提交于
Fujii Masao
-
由 Robert Haas 提交于
Shigeru Hanada, with some additional wordsmithing by me
-
由 Heikki Linnakangas 提交于
Kevin Grittner
-
- 12 6月, 2011 4 次提交
-
-
由 Robert Haas 提交于
Shigeru Hanada, with a minor grammar correction.
-
由 Robert Haas 提交于
The old code creates three separate arrays when only one is needed, using two different shmem allocation functions for no obvious reason. It also strangely splits up the initialization of AuxilaryProcs between the top and bottom of the function to no evident purpose. Review by Tom Lane.
-
由 Robert Haas 提交于
These pertain to object types introduced in PostgreSQL 9.1, so back-patch. Josh Kupershmidt, with some kibitzing by me.
-
由 Tom Lane 提交于
-
- 11 6月, 2011 6 次提交
-
-
由 Bruce Momjian 提交于
called 'pid'.
-
由 Tom Lane 提交于
ReadRecord's habit of using both direct references to tmpRecPtr and references to *RecPtr (which is pointing at tmpRecPtr) triggers an optimization bug in gcc 4.6.0, which apparently has forgotten about aliasing rules. Avoid the compiler bug, and make the code more readable to boot, by getting rid of the direct references. Improve the comments while at it. Back-patch to all supported versions, in case they get built with 4.6.0. Tom Lane, with some cosmetic suggestions from Alex Hunsaker
-
由 Heikki Linnakangas 提交于
Even if a flag is modified only by the backend owning the transaction, it's not safe to modify it without a lock. Another backend might be setting or clearing a different flag in the flags field concurrently, and that operation might be lost because setting or clearing a bit in a word is not atomic. Make did-write flag a simple backend-private boolean variable, because it was only set or tested in the owning backend (except when committing a prepared transaction, but it's not worthwhile to optimize for the case of a read-only prepared transaction). This also eliminates the need to add locking where that flag is set. Also, set the did-write flag when doing DDL operations like DROP TABLE or TRUNCATE -- that was missed earlier.
-
由 Alvaro Herrera 提交于
-
由 Alvaro Herrera 提交于
"Blind writes" are a mechanism to push buffers down to disk when evicting them; since they may belong to different databases than the one a backend is connected to, the backend does not necessarily have a relation to link them to, and thus no way to blow them away. We were keeping those files open indefinitely, which would cause a problem if the underlying table was deleted, because the operating system would not be able to reclaim the disk space used by those files. To fix, have bufmgr mark such files as transient to smgr; the lower layer is allowed to close the file descriptor when the current transaction ends. We must be careful to have any other access of the file to remove the transient markings, to prevent unnecessary expensive system calls when evicting buffers belonging to our own database (which files we're likely to require again soon.) This commit fixes a bug in the previous one, which neglected to cleanly handle the LRU ring that fd.c uses to manage open files, and caused an unacceptable failure just before beta2 and was thus reverted.
-
由 Alvaro Herrera 提交于
-
- 10 6月, 2011 7 次提交
-
-
由 Heikki Linnakangas 提交于
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
Also do some desultory copy-editing on the notes.
-
由 Alvaro Herrera 提交于
This reverts commit 54d9e8c6, which caused a failure on the buildfarm. Not a good thing to have just before a beta release.
-
由 Alvaro Herrera 提交于
"Blind writes" are a mechanism to push buffers down to disk when evicting them; since they may belong to different databases than the one a backend is connected to, the backend does not necessarily have a relation to link them to, and thus no way to blow them away. We were keeping those files open indefinitely, which would cause a problem if the underlying table was deleted, because the operating system would not be able to reclaim the disk space used by those files. To fix, have bufmgr mark such files as transient to smgr; the lower layer is allowed to close the file descriptor when the current transaction ends. We must be careful to have any other access of the file to remove the transient markings, to prevent unnecessary expensive system calls when evicting buffers belonging to our own database (which files we're likely to require again soon.)
-