On Tue, Oct 22, 2013 at 5:16 PM, Alvaro Herrera
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 apply cleanly
anymore
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 go
On Thu, Nov 28, 2013 at 9:42 PM, Sawada Masahiko 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:
- is ,off => is of
Hello
it looks well, thank you
Regards
Pavel
2013/12/1 Dean Rasheed
> On 1 December 2013 07:32, Pavel Stehule wrote:
> >
> >
> >
> > 2013/11/30 Peter Eisentraut
> >>
> >> trailing whitespace
> >
> >
> > fixed,
> >
>
> Hi,
>
> I've been looking at this and I think it's mostly in good shape,
Hello
I waited to fix.
Now I marked patch as ready for committer
Regards
Pavel
2013/12/1 Peter Geoghegan
> On Sat, Nov 30, 2013 at 11:30 PM, Pavel Stehule
> wrote:
> > After this fix it should be ready for commit
>
> Version with trivial, single token fix attached. I'm not sure if you
> ju
* 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
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 fo
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost 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 some informati
* 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
On Sun, 2013-12-01 at 15:58 +0100, Dimitri Fontaine wrote:
> Jeff Davis 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 work on the
Andres Freund 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 (my time).
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.htm
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 n
On 2013-12-01 18:02:27 -0500, Tom Lane wrote:
> Andres Freund 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 n
Andres Freund 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.
> Unfortunately it's not ac
On 2013-12-01 15:54:41 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Tom Lane 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
On 2013-12-01 17:15:31 -0500, Tom Lane wrote:
> Andres Freund 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 increasin
Piotr Marcinczyk 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 time
> zone fo
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
Andres Freund 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 happen if it mana
Andres Freund writes:
> Tom Lane 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?
> Unfortunately not. The problem is that xl
Noah Misch 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
>connecting i
On Sat, Nov 30, 2013 at 11:30 PM, Pavel Stehule 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 now.
I defer to the jud
On 1 December 2013 07:32, Pavel Stehule wrote:
>
>
>
> 2013/11/30 Peter Eisentraut
>>
>> 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 couple of places --- "does
On Wed, Nov 27, 2013 at 9:40 AM, Jeff Janes 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
>> currentl
Tom Lane schrieb:
>Andres Freund 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 checkin
Andres Freund 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 a row needed to be
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
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 cur
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?
Gre
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
On Wed, Nov 27, 2013 at 9:12 AM, Robert Haas 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 few
instructions. I
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 namestrcpy(
Jeff Davis 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 be SECURITY
Jeff Davis 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 automating the
On Sun, Dec 1, 2013 at 4:59 PM, 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){.
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 gener
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 actual
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 did
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, co
40 matches
Mail list logo
