On Wed, Jul 13, 2016 at 5:18 AM, Stephen Frost wrote:
> Attached is a patch to address this.
>
> After much consideration and deliberation, I went with the simpler
> solution to simply dump out the database privileges based on what a new
> creation of those privileges would yield, resulting in out
Hi all,
As of now UpdateMinRecoveryPoint() is using two arguments:
- lsn, to check if the minimum recovery point should be updated to that
- force, a boolean flag to decide if the update should be enforced or not.
However those two arguments are correlated. If lsn is
InvalidXlogRecPtr, the minimum
Hi all,
I just bumped into $subject, a variable that is never set and never used:
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -631,8 +631,6 @@ typedef struct XLogCtlData
TimeLineID replayEndTLI;
/* timestamp of last COMMIT/ABORT record replayed (or b
On Tue, Jul 12, 2016 at 12:22 PM, Amit Kapila wrote:
> I think updating minRecoveryPoint unconditionally can change it's
> purpose in some cases. Refer below comments in code:
>
> * minRecoveryPoint is updated to the latest replayed LSN whenever we
> * flush a data change during archive recovery.
On Wed, Jul 13, 2016 at 1:53 AM, Jeff Janes wrote:
> I've been having some adventures with pg_basebackup lately, and had
> some suggestions based on those.
And what I think is pg_baseback never remove the directory specified
by -D option even if execution is failed. initdb command behaves so.
I t
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 7/12/16 12:17 PM, Tom Lane wrote:
> > It's sounding to me like we have consensus on this proposal to further
> > change \df+ to replace the "Source code" column with "Internal name",
> > which is prosrc for C and internal-language fu
Peter Eisentraut wrote:
> I'm quite fond of having the full source code show in \df+ and I'm
> against removing it on short notice past beta2, discussed under a
> "false" subject heading.
How do you use it?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x
Merlin Moncure writes:
> On Mon, Jul 11, 2016 at 3:09 PM, Tom Lane wrote:
>> While we can certainly hack it by something along the lines of not
>> recognizing INTO when the first token was IMPORT, the whole thing
>> seems awfully messy and fragile. And it will certainly break again
>> the next t
On Mon, Jul 11, 2016 at 2:13 AM, Michael Paquier
wrote:
>
> On Mon, Jul 11, 2016 at 2:03 PM, Craig Ringer
wrote:
> > On 9 July 2016 at 01:57, Joshua Bay wrote:
> >> and where are this code is in the codebase?
> >
> > src/backend/replication/logical/*
> > src/backend/replication/walsender.c
> > s
Fabien COELHO writes:
> Ok. Here is an updated version, with a better suffix and a simplified
> comment.
Doesn't this break the handling of latency calculations, or at least make
the results completely different for the last metacommand than what they
would be for a non-last command? It looks l
I wrote:
> Andreas Seltenreich writes:
>> The infinite loop from the bug report was triggered. Further, two
>> previously unseen errors are logged:
>> ERROR: timestamp cannot be NaN
>> ERROR: getQuadrant: impossible case
>> The first is porbably as boring as it gets, the second one is from the
>
All,
* Noah Misch (n...@leadboat.com) wrote:
> On Wed, Jun 29, 2016 at 11:50:17AM -0400, Stephen Frost wrote:
> > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> > > Do this:
> > >
> > > CREATE DATABASE test1;
> > > REVOKE CONNECT ON DATABASE test1 FROM PUBLIC;
> > >
> > > Run pg_
I've noticed that pl/pgsql functions/do commands do not behave well
when the statement resolves and frees memory. To be clear:
FOR i in 1..100
LOOP
INSERT INTO foo VALUES (i);
END LOOP;
...runs just fine while
BEGIN
INSERT INTO foo VALUES (1);
INSERT INTO foo VALUES (2);
...
INSE
I wrote:
> I looked into the problem reported in bug #14238,
> https://www.postgresql.org/message-id/20160708151747.1426.60...@wrigleys.postgresql.org
> I think that probably the most reasonable answer is to replace all the
> raw "double" comparisons in this code with float8_cmp_internal() or
> som
On Tue, Jul 12, 2016 at 11:06:39AM -0700, Jeff Janes wrote:
> On Tue, Jul 12, 2016 at 10:48 AM, Peter Eisentraut
> wrote:
> > On 7/12/16 12:53 PM, Jeff Janes wrote:
> >> The --help message for pg_basebackup says:
> >>
> >> -Z, --compress=0-9 compress tar output with given compression level
> >
On Tue, Jul 12, 2016 at 10:48 AM, Peter Eisentraut
wrote:
> On 7/12/16 12:53 PM, Jeff Janes wrote:
>> The --help message for pg_basebackup says:
>>
>> -Z, --compress=0-9 compress tar output with given compression level
>>
>> But -Z0 is then rejected as 'invalid compression level "0"'. The rea
On 7/9/16 4:42 AM, Fabien COELHO wrote:
> number of transactions per client: 1000
> number of transactions actually processed: 1/1
> -latency average = 15.844 ms
> -latency stddev = 2.715 ms
> +latency average: 15.844 ms
> +latency stddev: 2.715 ms
> tps = 618.764555 (including connectio
Thank you for the feedback.
We had encountered this error message when allocating a record buf of 344
bytes. The message "record length 344 at %X/%X too long" along with the
comment /* We treat this as a "bogus data" condition */ masked the OOM
condition, implying an error in log record size cal
On 7/12/16 12:53 PM, Jeff Janes wrote:
> The --help message for pg_basebackup says:
>
> -Z, --compress=0-9 compress tar output with given compression level
>
> But -Z0 is then rejected as 'invalid compression level "0"'. The real
> docs do say 1-9, only the --help message has this bug. Triv
On 7/12/16 12:17 PM, Tom Lane wrote:
> It's sounding to me like we have consensus on this proposal to further
> change \df+ to replace the "Source code" column with "Internal name",
> which is prosrc for C and internal-language functions but NULL otherwise.
>
> If I've not heard objections by tomo
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Are we satisfied with telling people to use \sf to see the source code
> >> for a PL function? Or should there be another variant of \df that
> >> still provides source code?
>
> > I do
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Are we satisfied with telling people to use \sf to see the source code
>> for a PL function? Or should there be another variant of \df that
>> still provides source code?
> I don't see the point in having a \df variant be the same
I've been having some adventures with pg_basebackup lately, and had
some suggestions based on those.
The --help message for pg_basebackup says:
-Z, --compress=0-9 compress tar output with given compression level
But -Z0 is then rejected as 'invalid compression level "0"'. The real
docs do s
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Agreed. I don't have any issue with "Language", really, but I agree
> > that "Source code" makes the output pretty ridiculous. I also liked the
> > idea of changing the name to "internal name" or something along those
> > lines,
Andreas Seltenreich writes:
> Tom Lane writes:
>> More generally, this example makes me fearful that NaN coordinates in
>> geometric values are likely to cause all sorts of issues. It's too late
>> to disallow them, probably, but I wonder how can we identify other bugs
>> of this ilk.
> Sounds l
Peter Eisentraut writes:
> btree_gin uses SEQ_MINVALUE as a way to get the smallest int64 value.
> This is actually wrong because the smallest int64 value is
> SEQ_MINVALUE-1, so this might be slightly broken.
> The whole thing was done as a convenience when INT64_IS_BUSTED had to be
> considered
Stephen Frost writes:
> Agreed. I don't have any issue with "Language", really, but I agree
> that "Source code" makes the output pretty ridiculous. I also liked the
> idea of changing the name to "internal name" or something along those
> lines, rather than having it be "source code", if we kee
On Fri, Jul 8, 2016 at 1:52 PM, Andres Freund wrote:
> I'm a bit confused, why aren't we simply adding LSN interlock
> checks for toast? Doesn't look that hard? Seems like a much more
> natural course of fixing this issue?
I took some time trying to see what you have in mind, and I'm
really not
Hi
> amatv...@bitec.ru writes:
>> Is there any plan to implement "session per thread" or "shared
>> sessions between thread"?
> No, not really. The amount of overhead that would add --- eg, the need
> for locking on what used to be single-use caches --- makes the benefit
> highly questio
amatv...@bitec.ru writes:
> Is there any plan to implement "session per thread" or "shared
> sessions between thread"?
No, not really. The amount of overhead that would add --- eg, the need
for locking on what used to be single-use caches --- makes the benefit
highly questionable. Also,
Hi
Is there any plan to implement "session per thread" or "shared
sessions between thread"?
We have analyzed the ability to contribute pgSql to jvm bytecode compiler
but with
current thread model this idea is far from optimal.(Vm can be
different of course.
But currently we
On Mon, Jul 11, 2016 at 3:09 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> Currently pl/pgsql interprets the mandatory INTO of IMPORT FOREIGN
>> SCHEMA as INTO variable.
>
> Ugh, that's definitely a bug.
>
>> I estimate this to be minor oversight in
>> pl/pgsql parsing with respect to the intro
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Paquier writes:
> > On Tue, Jul 12, 2016 at 11:36 AM, Alvaro Herrera
> > wrote:
> >> So prosrc for internal/C and NULL for others? WFM.
>
> > And so we'd remove "Language" at the same time? That does not sound bad to
> > me.
>
> Hm, I wasn't th
Hi,
I noticed odd behavior in invalidating a cached plan with a foreign join
due to user mapping changes. Consider:
postgres=# create extension postgres_fdw;
postgres=# create server loopback foreign data wrapper postgres_fdw
options (dbname 'postgres');
postgres=# create user mapping for
On 07/09/2016 11:12 PM, Tom Lane wrote:
Alvaro Herrera writes:
the checkpoint_warning feature was added by commit 2986aa6a668bce3cfb836
in November 2002 when we didn't have any logging of checkpointing at
all. I propose to remove it: surely anyone who cares about analyzing
checkpointing beha
On Tue, Jul 12, 2016 at 3:32 AM, Craig Ringer wrote:
> On 11 July 2016 at 22:25, Stephen Frost wrote:
>
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> > Alvaro Herrera writes:
>> > > the checkpoint_warning feature was added by commit
>> 2986aa6a668bce3cfb836
>> > > in November 2002 when we didn't
Tom Lane writes:
> More generally, this example makes me fearful that NaN coordinates in
> geometric values are likely to cause all sorts of issues. It's too late
> to disallow them, probably, but I wonder how can we identify other bugs
> of this ilk.
Sounds like some fuzz testing with nan/infin
37 matches
Mail list logo
