in name.c file in source code of postgresql
I find some fuctions that I don't know where did use them?
the functions are:
int namecpy(Name n1, Name n2){..}
int namecat(Name n1, Name n2){..}
int namecmp(Name n1, Name n2){..}
int namestrcpy(Name name, const char *str){..}
int namestrcat(Name name,
On Sat, Nov 30, 2013 at 03:21:08PM -0800, Kevin Grittner wrote:
If your argument is that you want pg_upgrade to work even if the
user already turned on default_transaction_read_only in the *new*
cluster, I would humbly disagree with that goal, for pretty much
the same reasons I didn't
On 2013-11-27 14:53:27 -0500, Noah Misch wrote:
How would you characterize the chances of this happening with default
*vacuum_freeze_*_age settings? Offhand, it seems you would need to encounter
this bug during each of ~10 generations of autovacuum_freeze_max_age before
the old rows actually
On 2013-12-01 13:33:42 +0100, Andres Freund wrote:
On 2013-11-27 14:53:27 -0500, Noah Misch wrote:
How would you characterize the chances of this happening with default
*vacuum_freeze_*_age settings? Offhand, it seems you would need to
encounter
this bug during each of ~10 generations
On Sun, Dec 1, 2013 at 4:59 PM, mohsen soodkhah mohammadi
mohsensoodk...@gmail.com wrote:
in name.c file in source code of postgresql
I find some fuctions that I don't know where did use them?
the functions are:
int namecpy(Name n1, Name n2){..}
int namecat(Name n1, Name n2){..}
int
Jeff Davis pg...@j-davis.com writes:
I don't see why we are trying to accommodate a case where the author
doesn't offer enough full SQL scripts and offers broken downgrade
scripts; or why that case is different from offering broken upgrade
scripts.
That's fair enough I guess. I will work on
Jeff Davis pg...@j-davis.com writes:
So maybe we should have “SECURITY DEFINER” and “SECURITY INVOKER”
extension templates, the default being “SECURITY DEFINER”?
That doesn't seem to answer Heikki's stated concern, because a malicious
non-superuser would just declare the trojan extension to
On 12/01/2013 02:59 AM, mohsen soodkhah mohammadi wrote:
in name.c file in source code of postgresql
I find some fuctions that I don't know where did use them?
the functions are:
int namecpy(Name n1, Name n2){..}
int namecat(Name n1, Name n2){..}
int namecmp(Name n1, Name n2){..}
int
On Wed, Nov 27, 2013 at 9:12 AM, Robert Haas robertmh...@gmail.com wrote:
This is a performance patch, so it should come with benchmark results
demonstrating that it accomplishes its intended purpose. I don't see
any.
Yes, this is a performance patch, but as the subject says, it saves a
On Sun, Dec 01, 2013 at 01:55:45PM +0100, Andres Freund wrote:
On 2013-12-01 13:33:42 +0100, Andres Freund wrote:
On 2013-11-27 14:53:27 -0500, Noah Misch wrote:
How would you characterize the chances of this happening with default
*vacuum_freeze_*_age settings? Offhand, it seems you
On 2013-12-01 12:49:40 -0500, Noah Misch wrote:
This system had multiple problems, a missing pg_subtrans file and a missing
TOAST chunk for pg_attribute. I don't see a pg_clog problem connecting it to
the freeze bug at hand.
Those all sound like possible problems caused by the bug, no?
Hi there!
I've been reading several threads debating about the format of
postgresql.conf and improvements to it (like Overhauling GUCS [1] or
Proposal for Allow postgresql.conf values to be changed via SQL [2]).
Trying to summarize that in my own opinion, I think that the
On Sun, Dec 01, 2013 at 06:56:10PM +0100, Andres Freund wrote:
On 2013-12-01 12:49:40 -0500, Noah Misch wrote:
This system had multiple problems, a missing pg_subtrans file and a missing
TOAST chunk for pg_attribute. I don't see a pg_clog problem connecting it
to
the freeze bug at hand.
Andres Freund and...@2ndquadrant.com writes:
The VACUUM implementation in 9.3 had several bugs: It removed multixact
xmax values without regard of the importance of contained xids, it did
not remove multixacts if the contained xids were too old and it relied
on hint bits when checking whether
Tom Lane t...@sss.pgh.pa.us schrieb:
Andres Freund and...@2ndquadrant.com writes:
The VACUUM implementation in 9.3 had several bugs: It removed
multixact
xmax values without regard of the importance of contained xids, it
did
not remove multixacts if the contained xids were too old and it
On Wed, Nov 27, 2013 at 9:40 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Wed, Nov 13, 2013 at 8:49 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Here's another part of my crusade against xlog cleanup routines. This
series of patches gets rid of the gin_cleanup() function, which is
On 1 December 2013 07:32, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/11/30 Peter Eisentraut pete...@gmx.net
trailing whitespace
fixed,
Hi,
I've been looking at this and I think it's mostly in good shape, but I
spotted a few minor issues:
* There's a typo in the notice text in a
On Sat, Nov 30, 2013 at 11:30 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
After this fix it should be ready for commit
Version with trivial, single token fix attached. I'm not sure if you
just forgot to mark this ready for committer in the commitfest app,
but if not you'll want to do so
Noah Misch n...@leadboat.com schrieb:
On Sun, Dec 01, 2013 at 06:56:10PM +0100, Andres Freund wrote:
On 2013-12-01 12:49:40 -0500, Noah Misch wrote:
This system had multiple problems, a missing pg_subtrans file and a
missing
TOAST chunk for pg_attribute. I don't see a pg_clog problem
Andres Freund and...@2ndquadrant.com writes:
Tom Lane t...@sss.pgh.pa.us schrieb:
Uh ... what does the last have to do with it? Surely we don't run
VACUUM on replicas. Or are you talking about what might happen when
VACUUM is run on a former replica that's been promoted to master?
Andres Freund and...@2ndquadrant.com writes:
* Fix possible data corruptions due to incomplete vacuuming (Andres Freund,
Heikki Linnakangas)
Due to this bug (auto-)vacuum could sometimes treat a partial vacuum as
a full table vacuum mistakenly increasing relfrozenxid as a result. This
could
Hi,
I would like to implement item from TODO list: Improve TIMESTAMP WITH
TIME ZONE subtraction to be DST-aware.
To compute interval properly, we need time zone. Currently in timestamp
we don't have time zone information, so I would use actual session time
zone for computations. This can cause
Piotr Marcinczyk pmarc...@gmail.com writes:
I would like to implement item from TODO list: Improve TIMESTAMP WITH
TIME ZONE subtraction to be DST-aware.
To compute interval properly, we need time zone. Currently in timestamp
we don't have time zone information, so I would use actual session
On 2013-12-01 17:15:31 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
* Fix possible data corruptions due to incomplete vacuuming (Andres Freund,
Heikki Linnakangas)
Due to this bug (auto-)vacuum could sometimes treat a partial vacuum as
a full table vacuum
On 2013-12-01 15:54:41 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Tom Lane t...@sss.pgh.pa.us schrieb:
Uh ... what does the last have to do with it? Surely we don't run
VACUUM on replicas. Or are you talking about what might happen when
VACUUM is run on a former
Andres Freund and...@2ndquadrant.com writes:
On 2013-12-01 17:15:31 -0500, Tom Lane wrote:
Is there really a significant risk of clog access errors due to this bug?
IIUC, the risk is that tuples in pages that vacuum skips due to being
all-visible might not be frozen when intended.
On 2013-12-01 18:02:27 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-12-01 17:15:31 -0500, Tom Lane wrote:
Is there really a significant risk of clog access errors due to this bug?
IIUC, the risk is that tuples in pages that vacuum skips due to being
I've put up draft notes at
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=23e796de15567e9d31e8f9e8661828179f24a7be
and they should be visible on the docs website at
http://www.postgresql.org/docs/devel/static/release-9-3-2.html
in half an hour or so, after guaibasaurus does its
On 2013-12-01 18:56:19 -0500, Tom Lane wrote:
I've put up draft notes at
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=23e796de15567e9d31e8f9e8661828179f24a7be
and they should be visible on the docs website at
http://www.postgresql.org/docs/devel/static/release-9-3-2.html
Andres Freund and...@2ndquadrant.com writes:
On 2013-12-01 18:56:19 -0500, Tom Lane wrote:
I'd like to do any required editing on the notes at this stage,
before I start extracting relevant subsets for the older branches.
When do you plan to backpatch the documentation?
Tomorrow afternoon
On Sun, 2013-12-01 at 15:58 +0100, Dimitri Fontaine wrote:
Jeff Davis pg...@j-davis.com writes:
Either of those solution are fine to me, with or without the automated
SET ROLE when a superuser is installing an extension from a template
owned by a non-superuser.
Tell me your preference, I'll
* Jeff Davis (pg...@j-davis.com) wrote:
To throw another idea out, also based on the premise that it's a
namespace problem: if a non-superuser creates an extension template,
then we force a prefix of that user's username. So a superuser can
create an base extension template with no prefix, but
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Stephen Frost sfr...@snowman.net writes:
Without that, all of the information about a given extension is already in
the database in our dependency system. As you pointed out, there was
That's not entirely true. We would still be missing
Jeff,
* Jeff Davis (pg...@j-davis.com) wrote:
I see where you're coming from, but after some thought, and looking at
the patch, I think we really do want a catalog representation for (at
least some) extensions.
Perhaps I'm missing something- but we already *have* a catalog
representation for
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
# Why do we want extensions to manage PL user code?
Having a management system for sets of objects is a *great* idea- and
one which we already have through schemas. What we don't have is any
kind of versioning system built-in or other metadata
Hello
I waited to fix.
Now I marked patch as ready for committer
Regards
Pavel
2013/12/1 Peter Geoghegan p...@heroku.com
On Sat, Nov 30, 2013 at 11:30 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
After this fix it should be ready for commit
Version with trivial, single token fix
Hello
it looks well, thank you
Regards
Pavel
2013/12/1 Dean Rasheed dean.a.rash...@gmail.com
On 1 December 2013 07:32, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/11/30 Peter Eisentraut pete...@gmx.net
trailing whitespace
fixed,
Hi,
I've been looking at this
On Thu, Nov 28, 2013 at 9:42 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
I attached new version patch which have modify typos and added
documentation patch.
The documentation part of patch is implemented by Samrat Revagade.
Thanks for the new version. The documentation still has some typo:
Hi all,
The data replication bug causing data corruption on hot slaves found
lately (http://wiki.postgresql.org/wiki/Nov2013ReplicationIssue) is
causing a certain amount of damage among the users of Postgres, either
companies or individuals, and impacts a lot of people. So perhaps it
would be a
On Tue, Oct 22, 2013 at 5:16 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Hi,
There has been some interest in keeping track of timestamp of
transaction commits. This patch implements that.
Hi,
Sorry for the delay on the review.
First, because of the recent fixes the patch doesn't
40 matches
Mail list logo
