Hi,I am trying to efficiently rollback a manually selectedd subset of committed SQL transactions by scanning an SQL transaction log. This feature is useful when a database administrator wants to rollback not the entire database system, but only particular SQL statements that affect a certai
On Sat, May 4, 2019 at 1:29 PM Tom Lane wrote:
> Thomas Munro writes:
> > On Sat, May 4, 2019 at 10:29 AM Tom Lane wrote:
> > + Tolerate EINVAL and ENOSYS
> > + error results, where appropriate, for fsync calls (Thomas Munro,
> > + James Sewell)
>
> > Nit-picking: ENOSYS is for sy
Em sex, 3 de mai de 2019 às 17:27, Robert Haas escreveu:
>
> HINT: Commit or roll back old prepared transactions, drop stale
> replication slots, or kill long-running sessions.
> Ensure that autovacuum is progressing, or run a manual database-wide VACUUM.
>
First of all, +1 for this patch. But af
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-05-03 22:41:11 -0400, Stephen Frost wrote:
> > I suppose it is a pretty big change in the base autovacuum launcher to
> > be something that's run per database instead and then deal with the
> > coordination between the two... but I
Hi,
On 2019-05-03 22:41:11 -0400, Stephen Frost wrote:
> I suppose it is a pretty big change in the base autovacuum launcher to
> be something that's run per database instead and then deal with the
> coordination between the two... but I can't help but feel like it
> wouldn't be that much *work*.
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-05-03 22:03:18 -0400, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> > > I am not sure exactly how to fix this,
> > > because the calculation we use to determine the XID that can be used
> > > to vacuum a spe
Hi,
On 2019-05-03 22:03:18 -0400, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > I am not sure exactly how to fix this,
> > because the calculation we use to determine the XID that can be used
> > to vacuum a specific table is pretty complex; how can the postmaster
> > kno
Hi,
On 2019-05-03 22:11:08 -0400, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > I don't think we necessarily need a new WAL record for what I'm
> > describing above (as XLOG_SMGR_TRUNCATE already carries information
> > about which forks are truncated, we could just have i
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> I don't think we necessarily need a new WAL record for what I'm
> describing above (as XLOG_SMGR_TRUNCATE already carries information
> about which forks are truncated, we could just have it acquire the
> exclusive lock), and I don't think w
Hi,
On 2019-05-03 21:36:24 -0400, Robert Haas wrote:
> On Fri, May 3, 2019 at 8:45 PM Andres Freund wrote:
> > Part of my opposition to just disabling it when close to a wraparound,
> > is that it still allows to get close to wraparound because of truncation
> > issues.
>
> Sure ... it would def
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> I am not sure exactly how to fix this,
> because the calculation we use to determine the XID that can be used
> to vacuum a specific table is pretty complex; how can the postmaster
> know whether it's going to be able to make any progress i
On Fri, May 03, 2019 at 03:56:41PM -0700, Paul Jungwirth wrote:
> Hello,
>
> I wrote an extension to add a range_agg function with similar behavior to
> existing *_agg functions, and I'm wondering if folks would like to have it
> in core? Here is the repo: https://github.com/pjungwir/range_agg
>
On Fri, May 3, 2019 at 8:45 PM Andres Freund wrote:
> Part of my opposition to just disabling it when close to a wraparound,
> is that it still allows to get close to wraparound because of truncation
> issues.
Sure ... it would definitely be better if vacuum didn't consume XIDs
when it truncates.
Thomas Munro writes:
> On Sat, May 4, 2019 at 10:29 AM Tom Lane wrote:
> + Tolerate EINVAL and ENOSYS
> + error results, where appropriate, for fsync calls (Thomas Munro,
> + James Sewell)
> Nit-picking: ENOSYS is for sync_file_range, EINVAL is for fsync.
Yeah, I didn't really th
On Sat, May 4, 2019 at 10:29 AM Tom Lane wrote:
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8b3bce2017b15e05f000c3c5947653a3e2c5a29f
>
> Please send any corrections by Sunday.
+ Tolerate EINVAL and ENOSYS
+ error results, where appropriate, for fsync calls (Thom
Hi,
On 2019-05-03 18:42:35 -0400, Robert Haas wrote:
> On Fri, May 3, 2019 at 4:47 PM Andres Freund wrote:
> > I'd actually say the proper fix would be to instead move the truncation
> > to *after* finishing updating relfrozenxid etc. If we truncate, the
> > additional cost of another in-place p
Hi,
I'm starting this thread mostly to keep track of patches developed in
response to issue [1] reported on pgsql-performance. The symptoms are
very simple - query performing a hash join ends up using much more
memory than expected (pretty much ignoring work_mem), and possibly
ending up with OOM.
On Thu, 2 May 2019 at 14:22, David Rowley wrote:
>
> On Thu, 2 May 2019 at 13:08, Tom Lane wrote:
> >
> > Not a blocker perhaps, but it's better if we can get new behavior to
> > be more or less right the first time.
>
> It's not really new behaviour though. The code in question is for
> ATTACH P
Hello,
I wrote an extension to add a range_agg function with similar behavior
to existing *_agg functions, and I'm wondering if folks would like to
have it in core? Here is the repo: https://github.com/pjungwir/range_agg
I'm also working on a patch for temporal foreign keys, and having
range
Robert Haas writes:
> I spent a significant chunk of today burning through roughly 2^31 XIDs
> just to see what would happen. ...
> 2. Once you get to the point where you start to emit errors when
> attempting to assign an XID, you can still run plain old VACUUM
> because it doesn't consume an XI
On Fri, May 3, 2019 at 4:47 PM Andres Freund wrote:
> I'd actually say the proper fix would be to instead move the truncation
> to *after* finishing updating relfrozenxid etc. If we truncate, the
> additional cost of another in-place pg_class update, to update relpages,
> is basically insignifica
See
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8b3bce2017b15e05f000c3c5947653a3e2c5a29f
Please send any corrections by Sunday.
regards, tom lane
On Fri, May 03, 2019 at 10:28:21PM +0200, Dmitry Dolgov wrote:
On Tue, Apr 9, 2019 at 5:21 PM Tomas Vondra
wrote:
So I personally would suggest to treat those patches as independent until
the very last moment, develop the costing improvements needed by each
of them, and then decide which of th
Hi,
On 2019-05-03 16:26:46 -0400, Robert Haas wrote:
> 2. Once you get to the point where you start to emit errors when
> attempting to assign an XID, you can still run plain old VACUUM
> because it doesn't consume an XID ... except that if it tries to
> truncate the relation, then it will take Ac
I spent a significant chunk of today burning through roughly 2^31 XIDs
just to see what would happen. My test setup consisted of
autovacuum=off plus a trivial prepared transaction plus a lot of this:
+BeginInternalSubTransaction("txid_burn");
+(void) GetCurrentTransactionId();
+
> On Tue, Apr 9, 2019 at 5:21 PM Tomas Vondra
> wrote:
>
> So I personally would suggest to treat those patches as independent until
> the very last moment, develop the costing improvements needed by each
> of them, and then decide which of them are committable / in what order.
I had the same id
On Fri, May 03, 2019 at 12:21:36PM -0400, Tom Lane wrote:
Alvaro Herrera writes:
Error reporting in extended statistics is inconsistent -- many messages
that are ereport() in mvdistinct.c are elog() in the other modules.
...
I think this should be cleaned up, while at the same time not giving t
Hi,
On 2019-05-03 10:08:59 -0700, Mark Wong wrote:
> Ok, I think I have gdb installed now...
Thanks! Any chance you could turn on force_parallel_mode for the other
branches it applies to too? Makes it easier to figure out whether
breakage is related to that, or independent.
Greetings,
Andres Fr
Mark Wong writes:
> On Thu, May 02, 2019 at 11:45:34AM -0400, Tom Lane wrote:
>> While we're looking at this --- Mark, if you could install gdb
>> on your buildfarm hosts, that would be really handy. I think that's
>> the only extra thing the buildfarm script needs to extract stack
>> traces from
On Thu, May 02, 2019 at 11:45:34AM -0400, Tom Lane wrote:
> Andres Freund writes:
> > Hm, I just noticed:
> >'HEAD' => [
> >'force_parallel_mode =
> > regress'
> >
On Thu, Apr 25, 2019 at 12:36 PM Oleksii Kliukin wrote:
> - Fallbacks to autovacuum parameters in another scope. Right now in the
> absence of the per-table and per-tablespace autovacuum parameters the code
> uses the ones from the global scope. However, if only some of the reloptions
> are set on
Alvaro Herrera writes:
> Error reporting in extended statistics is inconsistent -- many messages
> that are ereport() in mvdistinct.c are elog() in the other modules.
> ...
> I think this should be cleaned up, while at the same time not giving too
> much hassle for translators; for example, this m
Hello
Error reporting in extended statistics is inconsistent -- many messages
that are ereport() in mvdistinct.c are elog() in the other modules. I
think what happened is that I changed them from elog to ereport when
committing mvdistinct, but Tomas and Simon didn't follow suit when
committing th
Hi,
On 2019-05-03 09:37:07 +0200, Peter Eisentraut wrote:
> REINDEX CONCURRENTLY is still deadlock prone because of
> WaitForOlderSnapshots(), so this doesn't actually fix your test case,
> but that seems unrelated to this particular issue.
Right.
I've not tested the change, but it looks reasona
On Fri, May 3, 2019 at 12:46 AM Dilip Kumar wrote:
> I might be completely missing but (ptr - array_base) is only valid
> when first time you get the array, but qsort will swap the element
> around and after that you will never be able to make out which element
> was at lower index and which one w
On Fri, May 03, 2019 at 02:55:47PM +0200, Rafia Sabih wrote:
> On Mon, 22 Apr 2019 at 17:49, Justin Pryzby wrote:
> >
> > It's deliberate that \dt doesn't show toast tables.
> > \d shows them, but doesn't show their indices.
> >
> > It seems to me that their indices should be shown, without having
Greetings,
* Evangelos Karatarakis (baggeliskap...@gmail.com) wrote:
> I am interested in participating in GSoD 2019 and more specifically I am
> interested in working on the project of impooving the Introductory Tutorial
> for beginners PostgreSQL and in databases. I have a practical and
> theore
Greetings
I am interested in participating in GSoD 2019 and more specifically I am
interested in working on the project of impooving the Introductory Tutorial
for beginners PostgreSQL and in databases. I have a practical and
theoretical backround in PostgreSQL due to previous work. Thus I am not i
On Fri, May 3, 2019 at 3:53 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-05-02 20:03, Jeff Janes wrote:
> > It looks like it was designed for early checking, it just wasn't placed
> > early enough. So changing it is pretty easy, as check_file_clone does
> > not need to
On Mon, 22 Apr 2019 at 17:49, Justin Pryzby wrote:
>
> It's deliberate that \dt doesn't show toast tables.
> \d shows them, but doesn't show their indices.
>
> It seems to me that their indices should be shown, without having to think and
> know to query pg_index.
>
> postgres=# \d pg_toast.pg_toa
On Fri, May 3, 2019 at 2:56 PM Rajkumar Raghuwanshi <
rajkumar.raghuwan...@enterprisedb.com> wrote:
> Hi,
>
> On PG-head, Some of statistical aggregate function are not giving correct
> output when enable partitionwise aggregate while same is working on v11.
>
I had a quick look over this and obs
Hi,
On PG-head, Some of statistical aggregate function are not giving correct
output when enable partitionwise aggregate while same is working on v11.
below are some of examples.
CREATE TABLE tbl(a int2,b float4) partition by range(a);
create table tbl_p1 partition of tbl for values from (minval
On Fri, May 3, 2019 at 11:43 AM John Naylor wrote:
> On Thu, May 2, 2019 at 4:57 PM Amit Kapila wrote:
> > On Thu, May 2, 2019 at 12:39 PM John Naylor
> > wrote:
> > >
> > Can you please test/review?
>
> There isn't enough time. But since I already wrote some debugging
> calls earlier (attached
On 2019-05-02 20:03, Jeff Janes wrote:
> It looks like it was designed for early checking, it just wasn't placed
> early enough. So changing it is pretty easy, as check_file_clone does
> not need to be invented, and there is no additional code duplication
> over what was already there.
>
> This p
On Sat, 27 Apr 2019 at 06:18, David Fetter wrote:
>
> On Fri, Apr 26, 2019 at 04:22:18PM +0200, Rafia Sabih wrote:
> > On Fri, 26 Apr 2019 at 14:49, Rafia Sabih wrote:
> > >
> > > On Wed, 24 Apr 2019 at 10:30, Fabien COELHO wrote:
> > > >
> > > >
> > > > Hello David,
> > > >
> > > > >>> I notice
On 2019-05-02 10:44, Peter Eisentraut wrote:
>> so there's a lock upgrade hazard.
> Confirmed.
Here is a patch along the lines of your sketch. I cleaned up the
variable naming a bit too.
REINDEX CONCURRENTLY is still deadlock prone because of
WaitForOlderSnapshots(), so this doesn't actually fix
On 2019-05-02 22:42, Andres Freund wrote:
> RangeVarGetRelidExtended() can call the callback multiple times, if
> there are any concurrent schema changes. That's why it's unlocking the
> previously locked heap oid.
Ah that explains it then.
--
Peter Eisentraut http://www.2ndQuadrant
47 matches
Mail list logo
