Use less cryptic variable names
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/005e5c30d162447da81d5d5e118a5ea4613dc944
Modified Files
--
src/bin/pg_basebackup/pg_basebackup.c | 74
1 files changed, 37 insertions(+), 37
Make pg_basebackup progress report translatable
Also fix a potential portability bug, because INT64_FORMAT is only
guaranteed to be available with snprintf, not fprintf.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/3b3f09351b48f3081021ce60964c92cec42b7c3d
Modifie
Thanks!
//Magnus
On Tue, Aug 16, 2011 at 10:30, Peter Eisentraut wrote:
> Make pg_basebackup progress report translatable
>
> Also fix a potential portability bug, because INT64_FORMAT is only
> guaranteed to be available with snprintf, not fprintf.
>
> Branch
> --
> master
>
> Details
> ---
Make pg_basebackup progress report translatable
Also fix a potential portability bug, because INT64_FORMAT is only
guaranteed to be available with snprintf, not fprintf.
Branch
--
REL9_1_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/be78374f160d4a3bb2357d38e3196f8dcd4ffcc1
Use less cryptic variable names
Branch
--
REL9_1_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/adbb764e5040b388c55bf1344cafa3c5fee7c14f
Modified Files
--
src/bin/pg_basebackup/pg_basebackup.c | 74
1 files changed, 37 insertions(
Fix bogus comment that claimed that the new BACKUP METHOD line in
backup_label was new in 9.0. Spotted by Fujii Masao.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/2877c67bc24510c30bca477c876f5de427c85588
Modified Files
--
src/backend/access/transam/xl
Any way to put David Byrne's name in here? He reported the bug and
sent a proposed fix.
Cheers,
David.
On Tue, Aug 16, 2011 at 02:40:19AM +, Bruce Momjian wrote:
> In pg_upgrade, avoid dumping orphaned temporary tables. This makes the
> pg_upgrade schema matching pattern match pg_dump/pg_dum
Adjust total size in pg_basebackup progress report when reality changes
When streaming including WAL, the size estimate will always be incorrect,
since we don't know how much WAL is included. To make sure the output doesn't
look completely unreasonable, this patch increases the total size whenever
Adjust total size in pg_basebackup progress report when reality changes
When streaming including WAL, the size estimate will always be incorrect,
since we don't know how much WAL is included. To make sure the output doesn't
look completely unreasonable, this patch increases the total size whenever
Log Message:
---
FIX: Support for PostGIS datatypes Geometry and Geography
Modified Files:
--
src/pl:
createRemoteSnapshot.pl (r1.11 -> r1.12)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/snapshot/src/pl/createRemoteSnapshot.pl?r1=1.11&r2=1.12)
dbiG
Fix race condition in relcache init file invalidation.
The previous code tried to synchronize by unlinking the init file twice,
but that doesn't actually work: it leaves a window wherein a third process
could read the already-stale init file but miss the SI messages that would
tell it the data is
Fix race condition in relcache init file invalidation.
The previous code tried to synchronize by unlinking the init file twice,
but that doesn't actually work: it leaves a window wherein a third process
could read the already-stale init file but miss the SI messages that would
tell it the data is
Fix race condition in relcache init file invalidation.
The previous code tried to synchronize by unlinking the init file twice,
but that doesn't actually work: it leaves a window wherein a third process
could read the already-stale init file but miss the SI messages that would
tell it the data is
Fix race condition in relcache init file invalidation.
The previous code tried to synchronize by unlinking the init file twice,
but that doesn't actually work: it leaves a window wherein a third process
could read the already-stale init file but miss the SI messages that would
tell it the data is
Fix race condition in relcache init file invalidation.
The previous code tried to synchronize by unlinking the init file twice,
but that doesn't actually work: it leaves a window wherein a third process
could read the already-stale init file but miss the SI messages that would
tell it the data is
Fix race condition in relcache init file invalidation.
The previous code tried to synchronize by unlinking the init file twice,
but that doesn't actually work: it leaves a window wherein a third process
could read the already-stale init file but miss the SI messages that would
tell it the data is
Preserve toast value OIDs in toast-swap-by-content for CLUSTER/VACUUM FULL.
This works around the problem that a catalog cache entry might contain a
toast pointer that we try to dereference just as a VACUUM FULL completes
on that catalog. We will see the sinval message on the cache entry when
we
Preserve toast value OIDs in toast-swap-by-content for CLUSTER/VACUUM FULL.
This works around the problem that a catalog cache entry might contain a
toast pointer that we try to dereference just as a VACUUM FULL completes
on that catalog. We will see the sinval message on the cache entry when
we
Preserve toast value OIDs in toast-swap-by-content for CLUSTER/VACUUM FULL.
This works around the problem that a catalog cache entry might contain a
toast pointer that we try to dereference just as a VACUUM FULL completes
on that catalog. We will see the sinval message on the cache entry when
we
Fix incorrect order of operations during sinval reset processing.
We have to be sure that we have revalidated each nailed-in-cache relcache
entry before we try to use it to load data for some other relcache entry.
The introduction of "mapped relations" in 9.0 broke this, because although
we update
Fix incorrect order of operations during sinval reset processing.
We have to be sure that we have revalidated each nailed-in-cache relcache
entry before we try to use it to load data for some other relcache entry.
The introduction of "mapped relations" in 9.0 broke this, because although
we update
Fix incorrect order of operations during sinval reset processing.
We have to be sure that we have revalidated each nailed-in-cache relcache
entry before we try to use it to load data for some other relcache entry.
The introduction of "mapped relations" in 9.0 broke this, because although
we update
Forget about targeting catalog cache invalidations by tuple TID.
The TID isn't stable enough: we might queue an sinval event before a VACUUM
FULL, and then process it afterwards, when the target tuple no longer has
the same TID. So we must invalidate entries on the basis of hash value
only. The
Forget about targeting catalog cache invalidations by tuple TID.
The TID isn't stable enough: we might queue an sinval event before a VACUUM
FULL, and then process it afterwards, when the target tuple no longer has
the same TID. So we must invalidate entries on the basis of hash value
only. The
Forget about targeting catalog cache invalidations by tuple TID.
The TID isn't stable enough: we might queue an sinval event before a VACUUM
FULL, and then process it afterwards, when the target tuple no longer has
the same TID. So we must invalidate entries on the basis of hash value
only. The
Revise sinval code to remove no-longer-used tuple TID from inval messages.
This requires adjusting the API for syscache callback functions: they now
get a hash value, not a TID, to identify the target tuple. Most of them
weren't paying any attention to that argument anyway, but plancache did
requ
David Fetter wrote:
> Any way to put David Byrne's name in here? He reported the bug and
> sent a proposed fix.
Do we report the reporter's name in commit messages? I can do that if
others are doing it. I don't think I can put it in now.
On Tue, Aug 16, 2011 at 10:17 PM, Bruce Momjian wrote:
> David Fetter wrote:
>> Any way to put David Byrne's name in here? He reported the bug and
>> sent a proposed fix.
>
> Do we report the reporter's name in commit messages?
I usually do; Tom, too, I think.
--
Robert Haas
EnterpriseDB: http
Robert Haas wrote:
> On Tue, Aug 16, 2011 at 10:17 PM, Bruce Momjian wrote:
> > David Fetter wrote:
> >> Any way to put David Byrne's name in here? ?He reported the bug and
> >> sent a proposed fix.
> >
> > Do we report the reporter's name in commit messages?
>
> I usually do; Tom, too, I think.
On Tue, Aug 16, 2011 at 10:17:21PM -0400, Bruce Momjian wrote:
> David Fetter wrote:
> > Any way to put David Byrne's name in here? He reported the bug and
> > sent a proposed fix.
>
> Do we report the reporter's name in commit messages? I can do that if
> others are doing it. I don't think I c
30 matches
Mail list logo
