e?
+1
I agree that the ambiguity is pretty confusing, and unnecessarily so.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your su
Why have you removed the GetLastError() call? MSDN says that "The
return value is the calling thread's last-error code".
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-committers mailing list (p
.co.uk/docs/gccintro/gccintro_36.html
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
in that structure?
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
houldn't this commit have removed the 1.0 file from git altogether?
> It's quite useless if it's not going to get installed.
It's worth noting that the recent commit "Make EXPLAIN (BUFFERS) track
blocks dirtied, as well as those written" did not remove
pg_
On 2 May 2012 14:43, Thom Brown wrote:
> "in" looks like an unnecessary duplicate, but maybe someone who speaks
> Italian can confirm.
Gabriele Bartolini, a prominent contributor to the .it translation and
a colleague of mine, confirms privately that it's an error.
I think I figured out why these went unnoticed for so long:
http://i.imgur.com/TnwtZ.png
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes
not sure why we're pushing the responsibility to call
PostmasterIsAlive() onto latch clients. Why not just do it within
WaitLatchOrSocket just as the WL_POSTMASTER_DEATH bit is set? It's not
as if someone could conceivably care that the Postmaster might have
died, but not enough to want to
On 10 May 2012 19:35, Tom Lane wrote:
> Remove weasel wording about falsely-set result bits from
> WaitLatch's API contract.
Aren't those weasel words still applicable to the case where sock !=
PGINVALID_SOCKET ?
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL D
cky-entry decay, and indeed the very
idea of sticky entries.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
h
On 23 May 2012 15:12, Bruce Momjian wrote:
> Mention Peter Geoghegan as primary author of pg_stat_statements changes.
Thank you.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-committers mailing list (pg
commit is
non-destructively reverted on the staging branch.
I don't know that it's worth worrying about, nor if the turnaround on
having a commit not break the buildfarm would be generally acceptable
in this situation. It would be nice to keep commit history cleaner,
though.
--
Peter Geog
evisited), it will be reasonable to have the new GUC in units of
milliseconds. After all, we've already been switching to milliseconds
across various statistics views, including pg_stat_statements.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Traini
On 15 August 2012 05:15, Tom Lane wrote:
> Peter Geoghegan writes:
>> On 14 August 2012 21:26, Bruce Momjian wrote:
>>> Revert "commit_delay" change; just add comment that we don't have
>>> a microsecond specification.
>
>> I think
./../src/include/c.h:67,
from qsort.c:46:
/usr/include/features.h:314:4: warning: #warning _FORTIFY_SOURCE
requires compiling with optimization (-O) [-Wcpp]
...
[peter@peterlaptop port]$ gcc --version
gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)
...
--
Peter Geoghegan ht
On 22 February 2013 19:58, Alvaro Herrera wrote:
> Add pg_xlogdump contrib program
I feel slightly silly reporting this, but you probably should have
updated the copyright years to 2013 before committing.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pg
s
easy to imagine that DBAs are specifying a high value of work_mem to
compensate for the previous implementation's tendency to under
provision.
> * "Require superuser privileges to set commit_delay"
> Meaning of commit_delay has changed and users should review their
> settin
ion, but that's about it.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
warn against that.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
both the
commit message and the code comment. There is no
ucol_getKeywordsForLocale() function.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
addition of EXTENSION_DONT_CHECK_SIZE, this makes for a nicer
> implementation of EXTENSION_REALLY_RETURN_NULL.
You missed a remaining reference to EXTENSION_REALLY_RETURN_NULL
within _mdfd_getseg().
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
IndexBuildHeapRangeScan, index.c:2597
Time: 3.699 ms
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
((x >> 40) & UINT64CONST(0x0000ff00)) |
+ ((x >> 56) & UINT64CONST(0x00ff));
+}
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
return true;
>
> return false;
> }
Wouldn't this last "if" test, to cover the pg_upgrade case, be better
targeted by comparing *raw* xmin to FrozenTransactionId? You're using
the potentially distinct xmin value returned by
HeapTupleHeaderGetXmin() for the tes
On Tue, Oct 17, 2017 at 3:40 AM, Alvaro Herrera wrote:
> Peter Geoghegan wrote:
>
>> Wouldn't this last "if" test, to cover the pg_upgrade case, be better
>> targeted by comparing *raw* xmin to FrozenTransactionId? You're using
>> the
On Tue, Oct 17, 2017 at 12:23 PM, Peter Geoghegan wrote:
> On Tue, Oct 17, 2017 at 3:40 AM, Alvaro Herrera
> wrote:
>> Peter Geoghegan wrote:
>>
>>> Wouldn't this last "if" test, to cover the pg_upgrade case, be better
>>> targeted by compar
are you planning on committing this?
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
whether or not it is safe to
interrogate clog for a given heap tuple using a tool like amcheck.
And, it wasn't obvious that you couldn't have a codepath that failed
to account for pre-cutoff non-frozen tuples -- codepaths that call
TransactionIdDidCommit() despite it actually being unsaf
ases differently. It was buggy
even on its own terms. The FrozenTransactionId test used an xmin from
HeapTupleHeaderGetXmin(), not HeapTupleHeaderGetRawXmin().
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
7;m missing something here?
Can you be more specific about what you mean here? I think that I
understand where you're going with this, but I'm not sure.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
ains))
xmax_new_tuple = InvalidTransactionId;
else
xmax_new_tuple = HeapTupleHeaderGetRawXmax(oldtup.t_data);
My naive guess is that we have to create a new MultiXactId here in at
least some cases, just like FreezeMultiXactId() sometimes does.
--
Peter Geoghegan
--
Sent via pgsql-co
Tom Lane wrote:
Stamp 9.2.24.
Uh, I thought 9.2 was EOL.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Mon, Nov 6, 2017 at 2:47 PM, Michael Paquier
wrote:
> On Tue, Nov 7, 2017 at 7:39 AM, Tom Lane wrote:
>> Peter Geoghegan writes:
>>> Tom Lane wrote:
>>>> Stamp 9.2.24.
> 9.2.24 is the last of the 9.2-series, November being the last minor
> release after
T chains are sane, which is how the enhanced amcheck notices
the bug here in practice. (Before this bug was discovered, I would
have expected amcheck to catch problems like it slightly later, during
the Bloom filter probe for that HOT chain...but, in fact, it never
gets there with corruption from this bug
ng to make sense of what you said.
> It's the second
> vacuum. The reindex part was about $user trying to fix the problem...
> As you need two vacuums with appropriate cutoffs to hit the "rows
> revive" problem, that'll often in practice not happen immediately.
Thi
it might be some other HOT chain root following TID
recycling by VACUUM)?
Assuming that's what you meant: I would have thought that the
xmin/xmax matching within heap_get_root_tuples() makes the sanity
checking fairly reliable in practice.
--
Peter Geoghegan
--
Sent via pgsql-committers
ch for the principal point I raised, which is how much work we need to
> do to not further worsen the corruption.
You're right. Just trying to put the risk in context, and to understand the
extent of the concern that you have.
--
Peter Geoghegan
On Wed, Nov 11, 2015 at 7:35 AM, Magnus Hagander wrote:
>> Congratulations!
>>
>
> +1. That's an exciting milestone!
Congratulations, Robert.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to
On Wed, Nov 11, 2015 at 9:08 AM, Peter Geoghegan wrote:
> Congratulations, Robert.
I should certainly extend my congratulations to Amit too.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
h
On Wed, Jan 20, 2016 at 11:41 AM, Robert Haas wrote:
> Support parallel joins, and make related improvements.
Congratulations to all involved.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
h
On Mon, Feb 15, 2016 at 2:17 PM, Andres Freund wrote:
> On 2016-02-15 22:01:12 +, Andres Freund wrote:
>> Allow SetHintBits() to succeed if the buffer's LSN is new enough.
>
> Thanks, that works with my brand of annoying compiler...
Wrong commit message. :-)
--
Peter
On Thu, Mar 10, 2016 at 1:22 PM, Andres Freund wrote:
> Yeha!
Fantastic effort, particularly from Masahiko. Well done.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailp
On Thu, Apr 7, 2016 at 4:09 AM, Simon Riggs wrote:
> Load FK defs into relcache for use by planner
I gather this is infrastructure for the "use foreign keys to improve
join estimates" patch. A more worked out commit message would be nice,
though.
--
Peter Geoghegan
--
S
al
decoding are also a concern; there could be significant issues there,
but that analysis just didn't happen. I had significant
misunderstandings about the patch as recently as this week.
This should be reverted.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@po
On Wed, May 11, 2016 at 1:20 PM, Tom Lane wrote:
> Fix assorted missing infrastructure for ON CONFLICT.
What does this mean?
+ /* XXX broken */
if (attno < 0)
elog(ERROR, "system column in index");
--
Peter Geoghegan
--
Sent via
not supported, and we should
throw an error (granted, a less ugly one), or they are supported, and
inference should succeed.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
g
index is total garbage.
This tells us a lot about how many people use hash indexes in
production, of course. 9.5 has been out for months.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgre
ed to perform the update) and it's hard to see why it should not be
> treated as an error. It's a release-note-worthy change though.
There is a reference to this right at the end of the executor README
that was missed.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (p
ilures that are probably harmless, but not
really fixable within LogicalTapeRewind() itself). Might be best to
get ahead of that now; my problem with using LogicalTapeRewind()
suggests to me that not using LogicalTapeRewind() to simply free
preload memory could be good *general* future-proofing.
T
On Wed, Oct 19, 2016 at 6:58 AM, Peter Eisentraut wrote:
> Make getrusage() output a little more readable
BTW, trace_sort is a user-visible, documented GUC, so I guess that
means that this will need a release note item.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pg
here the new limit is applied. Also
suggest that the subsequent USEMEM() call have
"state->read_buffer_size * numInputTapes" as its argument, rather than
state->availMem, just to be neat.
Thanks
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-commi
On Thu, Dec 8, 2016 at 1:07 PM, Heikki Linnakangas wrote:
> D'oh, you're right, of course. Fixed, thanks for the vigilance!
I've made exactly the same mistake myself before. :-)
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.or
On Thu, Dec 22, 2016 at 8:45 AM, Heikki Linnakangas
wrote:
> Simplify tape block format.
>
> No more indirect blocks. The blocks form a linked list instead.
There is still one remaining reference to indirect blocks that you
missed in comments above LogicalTapeRewindForWrite().
ir weight. They're justified as documentation. If the
assertion ever does fail, preventing someone from pushing buggy code,
then so much the better.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Sat, Mar 25, 2017 at 3:55 PM, Thomas Munro
wrote:
> This is a huge achievement. Congratulations!
I also think it's excellent. Well done to all involved.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subs
I see now that references to "queryid" in the documentation say
"querid" in one or two places. Whoops.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
didn't bother unlinking on startup, and so the file with query texts
was always on the PGDATA filesystem. What's the difference?
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
otally orthogonal to our security model.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
if things are timed just right. I do see it in the wild, albeit very
infrequently.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
r this patch in particular?
You'll need to serialize the file at least once before seeing it, but
then it's there for good (on old versions, before Magnus got annoyed
that that affected basebackups).
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgres
call
query after another query's parse analysis, but before its execution
finishes. That's one obvious way. But you don't even need a reset - a
badly timed entry_dealloc() could do it too.
I don't see what hash collisions have to do with it, though.
--
Peter Geoghegan
--
S
nk it's incongruous that you chose to make your opinion known at
this time and in this way. You knew about this patch several months
ago; are your surprised that it does what it was prominently
advertised to do?
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committe
ers
+and a hugepage size of 2kb of you will need at least 3156 huge pages.
I think that this should say 2MiB rather than 2kb. Or 2M, if you prefer.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
h
generally, as with pg_stat_statements, which doesn't
include planning time in total_time, while we aren't even explicit
about that in the documentation. But even still, seeing the two
side-by-side, with planning time > total runtime did give me pause.
--
Peter Geoghegan
--
Sent
On Sun, Feb 2, 2014 at 8:13 AM, Tom Lane wrote:
> Perhaps s/Total runtime/Execution time/ ?
+1
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Tue, Feb 18, 2014 at 11:39 AM, Alvaro Herrera
wrote:
> Is there are reason this wasn't back-patched to 9.3? I think it should
> be.
+1.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscri
ers couldn't run pg_controldata
even if they'd heard of it...
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Sat, May 3, 2014 at 8:16 PM, Bruce Momjian wrote:
> Initial version of Postgres 9.4 release notes
Did you forget to "git add release-9.4.sgml"?
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subsc
ller user-passed lookup array once has to
be cheaper than searching through the entire jsonb perhaps elem_count
times per call.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Thu, Aug 21, 2014 at 3:29 PM, Andres Freund wrote:
> Add pinning_backends column to the pg_buffercache extension.
Minor point: "Existence" is misspelled.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your
t are at the beginning of some unused
range, and so do other people, so this happens more often than you
might think.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
What I suggest is that this be changed to match the first suggestion
here (the intended message), since the "ON CONSTRAINT ... " variant is
really just an escape hatch that I don't expect will see much use. I
tried to encourage use of the conventional inference mechanism
everywhere.
perator to perform "field
assignment" for JSON objects. The inability to do that is a complaint
that people have with jsonb, and this ought to be positioned as the
solution to that problem.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.
On Fri, Jun 26, 2015 at 11:55 AM, Robert Haas wrote:
> release notes: Add entry for commit 5ea86e6e6.
s/Extend the infrastructure allow sorting/Extend the infrastructure that allows/
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To m
On Tue, Jun 30, 2015 at 12:00 PM, Andres Freund wrote:
> Improve 9.5 release notes.
Noticed a typo:
"compact and cheap to to update by"
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subsc
the connection
might not be the same as the intended corresponding database user.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
occurred to me that this usage is even non-traditional. I am
a native English speaker born in Ireland in the 1980s.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Sat, Oct 3, 2015 at 1:37 AM, Magnus Hagander wrote:
> Should we consider backpatching this further into the stable branches?
> Arguably it's a bugfix given the state of pgfoundry.
+1
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.o
too.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Mon, Oct 5, 2015 at 4:55 AM, Stephen Frost wrote:
> Apply SELECT policies in INSERT/UPDATE+RETURNING
If we've changed this now, where does that leave the excluded.* pseudo-relation?
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
80 matches
Mail list logo
