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 subscription:
http
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 (pgsql-committers
-theory.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
pointers 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
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_stat_statements--1.0.sql either.
--
Peter Geoghegan
On 2 May 2012 14:43, Thom Brown t...@linux.com 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.
--
Peter Geoghegan
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
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 be sure.
--
Peter Geoghegan
On 10 May 2012 19:35, Tom Lane t...@sss.pgh.pa.us 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
to managing sticky-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
On 23 May 2012 15:12, Bruce Momjian br...@momjian.us 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
-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 Geoghegan http://www
), 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, Training and Services
On 15 August 2012 05:15, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan pe...@2ndquadrant.com writes:
On 14 August 2012 21:26, Bruce Momjian br...@momjian.us wrote:
Revert commit_delay change; just add comment that we don't have
a microsecond specification.
I think that if we eventually
../../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 http
On 22 February 2013 19:58, Alvaro Herrera alvhe...@alvh.no-ip.org 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
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
settings, if used
+1
--
Peter Geoghegan
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
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
, pg_stat_statements
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
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
constants
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
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@postgresql.org)
To make changes
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
--
Sent via pgsql-committers mailing
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-committers@postgresql.org
with 6GB shared buffers
+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
, 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 via pgsql-committers mailing list (pgsql
On Sun, Feb 2, 2014 at 8:13 AM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Feb 18, 2014 at 11:39 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
of our users 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 br...@momjian.us 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 subscription
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 and...@anarazel.de 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
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
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.
--
Peter Geoghegan
--
Sent via pgsql
operator 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.org)
To make changes
On Fri, Jun 26, 2015 at 11:55 AM, Robert Haas rh...@postgresql.org 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
On Tue, Jun 30, 2015 at 12:00 PM, Andres Freund and...@anarazel.de 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 subscription:
http
On Wed, Nov 11, 2015 at 7:35 AM, Magnus Hagander <mag...@hagander.net> wrote:
>> Congratulations!
>>
>
> +1. That's an exciting milestone!
Congratulations, Robert.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
On Sat, Oct 3, 2015 at 1:37 AM, Magnus Hagander <mag...@hagander.net> 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 (pgsq
required extensions 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
lazy.
It never 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
t initiated 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
On Mon, Oct 5, 2015 at 4:55 AM, Stephen Frost <sfr...@snowman.net> 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-c
ses, because the resulting
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 subscr
On Wed, Jan 20, 2016 at 11:41 AM, Robert Haas <rh...@postgresql.org> 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 change
On Mon, Feb 15, 2016 at 2:17 PM, Andres Freund <and...@anarazel.de> 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 mes
On Thu, Mar 10, 2016 at 1:22 PM, Andres Freund <and...@anarazel.de> 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 subscript
On Thu, Apr 7, 2016 at 4:09 AM, Simon Riggs <si...@2ndquadrant.com> 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.
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-committ
gnore the index? Either they're 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 sub
On Wed, May 11, 2016 at 1:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Fix assorted missing infrastructure for ON CONFLICT.
What does this mean?
+ /* XXX broken */
if (attno < 0)
elog(ERROR, "system column in index");
--
Peter Ge
on failures 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.
On Wed, Oct 19, 2016 at 6:58 AM, Peter Eisentraut <pete...@gmx.net> 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-c
ould 's/Min/Max/' where 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-com
On Thu, Dec 8, 2016 at 1:07 PM, Heikki Linnakangas <hlinn...@iki.fi> 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@postg
comments above LogicalTapeRewindForWrite().
--
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
<thomas.mu...@enterprisedb.com> 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
ling their 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
ValuesForLocale() in 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
esides allowing for
> the 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 l
table "t"
LOCATION: 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
x00ff)) |
+ ((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
r the test here. I think we should be
directly targeting tuples frozen on or before 9.4 (prior to
pg_upgrade) instead.
Have I missed something?
--
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, Oct 17, 2017 at 3:40 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org> 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
>
On Tue, Oct 17, 2017 at 12:23 PM, Peter Geoghegan <p...@bowt.ie> wrote:
> On Tue, Oct 17, 2017 at 3:40 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org>
> wrote:
>> Peter Geoghegan wrote:
>>
>>> Wouldn't this last "if" test, to cover the pg_upgrade cas
ething 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/ma
On Mon, Nov 6, 2017 at 2:47 PM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> On Tue, Nov 7, 2017 at 7:39 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Peter Geoghegan <p...@bowt.ie> writes:
>>> Tom Lane <t...@sss.pgh.pa.us> wrote:
>>>>
t those two cases 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 subscr
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 unsafe.
If I'm not mis
HOT 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 bu
ly.
This explanation clears things up, though.
--
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
e
actual root (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-comm
d, 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
mp;& !locker_remains))
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
--
S
Tom Lane <t...@sss.pgh.pa.us> 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
this should do
> it.
When 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
77 matches
Mail list logo
