>
>
> In the end, I suspect that teaching all the backslash commands to do
> nothing after absorbing their arguments is likely to be the least messy
> way to tackle this, even if it makes for a rather bulky patch.
>
>
Perhaps, but just glancing at \connect makes me think that for some
commands
Hi,
Am Freitag, den 17.03.2017, 20:46 +0900 schrieb Michael Paquier:
> On Fri, Mar 17, 2017 at 7:18 PM, Michael Banck
> wrote:
> > Am Freitag, den 17.03.2017, 10:50 +0900 schrieb Michael Paquier:
> >> The comment block format is incorrect. I would think as well that
On 16 March 2017 at 18:18, Ashutosh Bapat
wrote:
> + * Check if we are already finished plans from parallel append. This
> + * can happen if all the subplans are finished when this worker
> + * has not even started returning tuples.
> +
I gave this patch a quick skim. At first I was confused by the term
"catalog"; I thought it meant we stored options in a system table. But
that's not what is meant at all; instead, what we do is build these
"catalogs" in memory. Maybe a different term could have been used, but
I'm not sure it's
Hello Tom,
ISTM that I've tried to suggest to work around that complexity by:
- document that \if-related commands should only occur at line start
(and extend to eol).
- detect and complain when this is not the case.
I think this is a lousy definition, and would never be considered
>
>
> command.c:38:25: fatal error: conditional.h: No such file or directory
> #include "conditional.h"
>
Odd, it's listed as a new file in git status. Anyway, my point of posting
the WIP patch was to give people a reference point and spark discussion
about the next step, and it succeeded at
On Thu, Mar 16, 2017 at 10:34 PM, Craig Ringer wrote:
> On 17 March 2017 at 08:10, Stas Kelvich wrote:
>> While working on this i’ve spotted quite a nasty corner case with aborted
>> prepared
>> transaction. I have some not that great ideas how
While reviewing Ashutosh Bapat's partitionwise join code, I noticed
he'd run up against the problem that adjust_relid_set() is defined as
static in two different source files, and he wanted to call it from a
third file. I didn't much like his solution to that problem, which
was to rename one of
Hi Giuseppe,
Thanks for the response. I have provided the GRANTS and other PostgreSQL
setup scripts below as it includes what you have suggested:
ROLE
-
CREATE ROLE WITH NOLOGIN NOSUPERUSER INHERIT NOCREATEDB
NOCREATEROLE NOREPLICATION;
USER
--
CREATE USER WITH PASSWORD ''
On Fri, Mar 17, 2017 at 11:42 AM, Tom Lane wrote:
> Fabien COELHO writes:
> >> I also fear that there are corner cases where the behavior would still
> >> be inconsistent. Consider
> >>
> >> \if ...
> >> \set foo `echo \endif should not appear here`
>
>
Robert Haas writes:
> The relevant code is in neqsel(). It estimates the fraction of rows
> that will be equal, and then does 1 - that number. Evidently, the
> query planner thinks that l1.l_suppkey = l2.l_suppkey would almost
> always be true, and therefore l1.l_suppkey
Hi John,
Thanks for your response. From my experience as a Software Developer, I
don't think QGIS can logon to my database/schema/table with a dedicated
user as they need authentication to do so. What you described about using a
dedicated user in applications is only possible because that user
Petr Jelinek writes:
> Now the documentation for WSAEventSelect says "The FD_WRITE network
> event is handled slightly differently. An FD_WRITE network event is
> recorded when a socket is first connected with a call to the connect,
> ConnectEx, WSAConnect,
On 3/17/17 11:06, Alvaro Herrera wrote:
> I don't get anything with my compiler (gcc (Debian 4.9.2-10) 4.9.2) and
> I don't see anything in the few logs I looked at (clang, 9.6) from
> buildfarm either. What are you seeing specifically?
cc -Wall -Wmissing-prototypes -Wpointer-arith
Hi Osahon,
2017-03-17 15:54 GMT+01:00 Osahon Oduware :
> Hi All,
>
> I created a "Read-only" User in PostgreSQL via a Role with "SELECT" ONLY
> privilege on all tables in a schema as shown below:
>
> GRANT SELECT ON ALL TABLES IN SCHEMA [schema_name] TO [role_name]
>
Andres Freund writes:
> [ latest patches ]
I looked through 0001 (the composite-type-dependencies one). Although
I agree that it'd be good to tighten things up in that area, I do not
think we want this specific patch: it tightens things too much. Consider
this variant of
I wrote:
> The problem here appears to be that we don't have any MCV list for
> the "twothousand" column (because it has a perfectly flat distribution),
> and the heuristic that eqjoinsel_semi is using for the no-MCVs case
> is falling down badly.
Oh ... wait. eqjoinsel_semi's charter is to
On 17 March 2017 at 01:37, Robert Haas wrote:
> - You've added a GUC (which is good) but not documented it (which is
> bad) or added it to postgresql.conf.sample (also bad).
>
> - You've used a loop inside a spinlock-protected critical section,
> which is against project
Petr Jelinek writes:
> On 17/03/17 17:28, Tom Lane wrote:
>> Yeah, I'm afraid we had better do something more or less like this.
>> It's interesting to speculate about whether WaitEventSet could keep
>> additional state that would avoid the need for a dummy send()
Peter Eisentraut wrote:
> On 3/16/17 11:56, Alvaro Herrera wrote:
> > Michael Paquier wrote:
> >
> >> What are you using as CFLAGS? As both typenames should be normally
> >> set, what about initializing those fields with NULL and add an
> >> assertion like the attached?
> >
> > Actually, my
While I do not know QGIS, I'm wondering if it's similar to some of our
applications where they always use the same system login for the database
while each user provides a unique login to the application. Have you ever
set log_connections in your postgresql.conf file? That would show you which
Hi all,
2017-03-17 17:09 GMT+01:00 John Scalia :
> While I do not know QGIS, I'm wondering if it's similar to some of our
> applications where they always use the same system login for the database
> while each user provides a unique login to the application. Have you
On Fri, Mar 17, 2017 at 1:54 AM, Thomas Munro
wrote:
> SELECT *
>FROM lineitem l1
> WHERE EXISTS (SELECT *
> FROM lineitem l2
> WHERE l1.l_orderkey = l2.l_orderkey);
>
> -> estimates 59986012 rows, actual rows 59,986,052
On 17/03/17 17:28, Tom Lane wrote:
> Petr Jelinek writes:
>> Now the documentation for WSAEventSelect says "The FD_WRITE network
>> event is handled slightly differently. An FD_WRITE network event is
>> recorded when a socket is first connected with a call to the
Hello Tom,
I also fear that there are corner cases where the behavior would still
be inconsistent. Consider
\if ...
\set foo `echo \endif should not appear here`
In this instance, ISTM that there is no problem. On "\if true", set is
executed, all is well. On "\if false", the whole line
While trying to figure out some bloating in the newly logged hash indexes,
I'm looking into the type of each page in the index. But I get an error:
psql -p 9876 -c "select hash_page_type(get_raw_page('foo_index_idx',x))
from generate_series(1650,1650) f(x)"
ERROR: page is not a hash page
Andrew Dunstan writes:
> I have confirmed on jacana Petr's observation that adding a timeout to
> the WaitLatchOrSocket cures the problem.
Does anyone have a theory as to why that cures the problem?
What length of timeout is being suggested here? Would a long
>
>
> I am sending the review of this patch
I found the following
v Use tage in documentation
v Don’t modified existing test case add new one instead
v Comment in pg_constraint.c is extended make it short
v Error message can be more guider if it tells about general rule
v Wrong result
Hi,
On 2017-03-17 11:36:30 -0400, Tom Lane wrote:
> Having said all that, I think that 0001 is contributing very little to the
> goals of this patch set. Andres stated that he wanted it so as to drop
> some of the one-time checks that execQual.c currently does for Vars, but
> I'm not really
Corey Huinker writes:
> I think Fabien was arguing that inside a false block there would be no
> syntax rules beyond "is the first non-space character on this line a '\'
> and if so is it followed with a if/elif/else/endif?". If the answer is no,
> skip the line. To me
Andres Freund writes:
> That said, it seems this is something that has to wait for a later
> release, I'm putting back in similar logic as there was before (not a
> branch, but change the opcode to a non-checking variant).
Yeah, I was wondering if changing the opcode would be
Corey Huinker writes:
>> In the end, I suspect that teaching all the backslash commands to do
>> nothing after absorbing their arguments is likely to be the least messy
>> way to tackle this, even if it makes for a rather bulky patch.
> Perhaps, but just glancing at
A handful of rather surprising errors showed up in our log extract this
morning, along the lines of:
2017-03-17 05:01:55 CDT [5400]: [1-1] @ FATAL: 57P01: terminating
connection due to administrator command
After a moment of more than a little astonishment, a look at the full log
revealed
Fabien COELHO writes:
>> I also fear that there are corner cases where the behavior would still
>> be inconsistent. Consider
>>
>> \if ...
>> \set foo `echo \endif should not appear here`
> In this instance, ISTM that there is no problem. On "\if true", set is
> executed,
On 17/03/17 16:07, Tom Lane wrote:
> Andrew Dunstan writes:
>> I have confirmed on jacana Petr's observation that adding a timeout to
>> the WaitLatchOrSocket cures the problem.
>
> Does anyone have a theory as to why that cures the problem?
>
I now have theory
Hi Kevin,
On 2017-03-17 15:17:33 -0500, Kevin Grittner wrote:
> Why do we warn of a hazard here instead of eliminating said hazard
> with a static inline function declaration in executor.h?
Presumably because it was written long before we started relying on
inline functions :/
> /*
> *
2017-03-16 22:01 GMT+01:00 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
> > 2017-03-15 17:21 GMT+01:00 Stephen Frost :
> > > I started looking through this to see if it might be ready to commit
> and
> > > I don't believe it
On Sunday 12 March 2017 01:58 AM, Jim Nasby wrote:
On 3/10/17 8:29 AM, Alexander Korotkov wrote: >> That's cool idea. But I would say more. Sometimes it's useful to >> transform "intcol between x and y" into
"intcol <@ 'x,y'::int4range". >> btree_gin supports "intcol between x and y" as
On Friday 10 March 2017 07:59 PM, Alexander Korotkov wrote:
Hi, Pritam! > > I've assigned to review this patch. > > On Thu, Feb 23, 2017 at 2:17 AM, Pritam Baral wrote: > > The topic has been previously discussed[0] on the -performance mailing list, > about four
On Fri, Mar 17, 2017 at 3:23 PM, Andres Freund wrote:
> On 2017-03-17 15:17:33 -0500, Kevin Grittner wrote:
>> Why do we warn of a hazard here instead of eliminating said hazard
>> with a static inline function declaration in executor.h?
>
> Presumably because it was written
Kevin Grittner writes:
> Why do we warn of a hazard here instead of eliminating said hazard
> with a static inline function declaration in executor.h?
> /*
> * ExecEvalExpr was formerly a function containing a switch statement;
> * now it's just a macro invoking the function
Why do we warn of a hazard here instead of eliminating said hazard
with a static inline function declaration in executor.h?
/*
* ExecEvalExpr was formerly a function containing a switch statement;
* now it's just a macro invoking the function pointed to by an ExprState
* node. Beware of
On 3/16/17 21:10, Robert Haas wrote:
> The changes to pg_standby seem to completely break the logic to wait
> until the file has attained the correct size. I don't know how to
> salvage that logic off-hand, but just breaking it isn't acceptable.
I think we would have to extend restore_command
I wrote:
> * You're not bothering to insert any inputcollid into the generated
> comparison operator nodes. I'm not sure why that fails to fall over
> for text comparisons (if indeed it does fail ...) but it's wrong.
> Use the range type's collation there.
Oh ... looking at this again, I realize
On 3/17/17 16:20, Peter Eisentraut wrote:
> On 3/16/17 21:10, Robert Haas wrote:
>> The changes to pg_standby seem to completely break the logic to wait
>> until the file has attained the correct size. I don't know how to
>> salvage that logic off-hand, but just breaking it isn't acceptable.
>
>
Peter Eisentraut writes:
> On 3/17/17 16:20, Peter Eisentraut wrote:
>> I think we would have to extend restore_command with an additional
>> placeholder that communicates the segment size, and add a new pg_standby
>> option to accept that size somehow. And
Robert Haas writes:
> While reviewing Ashutosh Bapat's partitionwise join code, I noticed
> he'd run up against the problem that adjust_relid_set() is defined as
> static in two different source files, and he wanted to call it from a
> third file. I didn't much like his
On Fri, Mar 17, 2017 at 1:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> While reviewing Ashutosh Bapat's partitionwise join code, I noticed
>> he'd run up against the problem that adjust_relid_set() is defined as
>> static in two different source
>
>
> > \set x 'arg1 arg2'
>
> > \if false
> > \cmd_that_takes_exactly_two_args :x
> > \endif
>
> Yeah, throwing errors for bad arguments would also need to be suppressed.
>
> regards, tom lane
>
Ok, barring other feedback, I'm going to take my marching orders as "make
On Fri, Mar 17, 2017 at 10:54 PM, Jeff Janes wrote:
> While trying to figure out some bloating in the newly logged hash indexes,
> I'm looking into the type of each page in the index. But I get an error:
>
> psql -p 9876 -c "select
On 3/17/17 13:39, Alvaro Herrera wrote:
> Oh yeah, buildfarm member sitella shows that. Does the attached patch
> fix it? (pretty much the same thing Michael attached, but we also need
> to handle typeoids)
Yes, that makes the warning go away.
--
Peter Eisentraut
On Fri, Mar 17, 2017 at 1:14 PM, Tom Lane wrote:
> After a bit more thought, it seems like the bug here is that "the
> fraction of the LHS that has a non-matching row" is not one minus
> "the fraction of the LHS that has a matching row". In fact, in
> this example, *all* LHS
Andrew Dunstan writes:
> On 03/17/2017 12:28 PM, Tom Lane wrote:
>> I'll add some comments and push this. Does everyone agree that
>> this had better get back-patched, too?
> Confirmed that this fixes the problem on jacana.
> +1 for backpatching.
I've pushed
On 3/17/17 13:24, Jeff Janes wrote:
> And isn't it unhelpful to have the pageinspect module throw errors,
> rather than returning a dummy value to indicate there was an error?
Even if one agreed with that premise, it would be hard to satisfy
reliably, because the user-facing pageinspect functions
Peter Eisentraut wrote:
> cc -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
> -Wformat-security -fno-strict-aliasing -fwrapv
> -fexcess-precision=standard -g -O2 -I../../../src/include
> -D_FORTIFY_SOURCE=2 -DLINUX_OOM_ADJ
Robert Haas writes:
> On Fri, Mar 17, 2017 at 1:14 PM, Tom Lane wrote:
>> It would not be too hard to convince me that neqjoinsel should
>> simply return 1.0 for any semijoin/antijoin case, perhaps with
>> some kind of discount for nullfrac. Whether or
Ashutosh Sharma writes:
> Basically, when we started working on WAL for hash index, we found
> that WAL routine 'XLogReadBufferExtended' does not expect a page to be
> completely zero page else it returns Invalid Buffer. To fix this, we
> started initializing freed overflow
On 3/13/17 11:35, Aleksander Alekseev wrote:
> Here is a new patch. I tried to make as little changes as possible. This
> is no doubt not the most beautiful patch on Earth but it removes all
> warnings. I anyone could suggest an approach that would be significantly
> better please don't hesitate
By the way, it would be very good if you could review some patches, too.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Wed, Mar 15, 2017 at 07:26:45PM -0700, Andres Freund wrote:
> On 2017-03-15 16:31:11 -0400, Robert Haas wrote:
> > On Wed, Mar 15, 2017 at 3:54 PM, Ashutosh Sharma
> > wrote:
> > > Changed as per suggestions. Attached v9 patch. Thanks.
> >
> > Wow, when do you sleep?
>
On Fri, Mar 17, 2017 at 9:15 AM, Ashutosh Bapat
wrote:
> This set of patches fixes both of those things.
0001 changes the purpose of a function and then 0007 renames it. It
would be better to include the renaming in 0001 so that you're not
taking multiple whacks
On Fri, Mar 17, 2017 at 10:12 AM, Amit Khandekar wrote:
> Yeah, I was in double minds as to whether to do the
> copy-to-array-and-qsort thing, or should just write the same number of
> lines of code to manually do an insertion sort. Actually I was
> searching if we already
Hi,
It looks we're creeping towards agreement in
http://archives.postgresql.org/message-id/20161206034955.bh33paeralxbtluv%40alap3.anarazel.de
It'd be fairly easy to add a hook in its ExecInstantiateExpr(), which'd
allow extensions to provide newer (presumably faster) ways to evaluate
On Sat, Mar 18, 2017 at 11:49 AM, Thomas Munro
wrote:
> On Sat, Mar 18, 2017 at 6:14 AM, Tom Lane wrote:
>> After a bit more thought, it seems like the bug here is that "the
>> fraction of the LHS that has a non-matching row" is not one minus
>>
On Fri, Mar 17, 2017 at 5:50 PM, Michael Meskes wrote:
>> Thank you for pointing out.
>> Yeah, I agree that the twophase regression test should not be
>> performed by default as long as the default value of
>> max_prepared_transactions is 0. Similar to this, the isolation
On 3/17/17 16:56, Tom Lane wrote:
> Tools could get the segment size out of
> XLogLongPageHeaderData.xlp_seg_size in the first page of the segment.
OK, then pg_standby would have to wait until the file is at least
XLOG_BLCKSZ, then look inside and get the expected final size. A bit
more
Hi,
On 03/17/2017 05:23 PM, Peter Eisentraut wrote:
I'm struggling to find a good way to share code between
bt_page_items(text, int4) and bt_page_items(bytea).
If we do it via the SQL route, as I had suggested, it makes the
extension non-relocatable, and it will also create a bit of a mess
On Sat, Mar 18, 2017 at 6:14 AM, Tom Lane wrote:
> After a bit more thought, it seems like the bug here is that "the
> fraction of the LHS that has a non-matching row" is not one minus
> "the fraction of the LHS that has a matching row". In fact, in
> this example, *all* LHS
On Fri, Mar 17, 2017 at 6:11 PM, Peter Eisentraut
wrote:
> On 3/17/17 16:56, Tom Lane wrote:
>> Tools could get the segment size out of
>> XLogLongPageHeaderData.xlp_seg_size in the first page of the segment.
>
> OK, then pg_standby would have to wait until the
On Tue, Mar 14, 2017 at 8:03 AM, Thomas Munro
wrote:
> On Mon, Mar 13, 2017 at 8:40 PM, Rafia Sabih
> wrote:
>> In an attempt to test v7 of this patch on TPC-H 20 scale factor I found a
>> few regressions,
>> Q21: 52 secs on HEAD and
Studying logrep yielded some more improvements to the comments in
snapbuild.c
(to be applied to master)
thanks,
Erik Rijekrs
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-03-18 06:37, Erik Rijkers wrote:
Studying logrep yielded some more improvements to the comments in
snapbuild.c
(to be applied to master)
Attached the actual file
thanks,
Erik Rijekrs
--- src/backend/replication/logical/snapbuild.c.orig 2017-03-18 05:02:28.627077888 +0100
+++
On 03/08/2017 08:29 PM, Andrew Dunstan wrote:
>
> On 03/08/2017 08:33 AM, Peter Eisentraut wrote:
>> On 3/6/17 09:38, Peter Eisentraut wrote:
>>> On 3/4/17 01:45, Petr Jelinek wrote:
If that's the case, the attached should fix it, but I have no way of
testing it on windows, I can only
> Thank you for pointing out.
> Yeah, I agree that the twophase regression test should not be
> performed by default as long as the default value of
> max_prepared_transactions is 0. Similar to this, the isolation check
> regression test does same thing. Attached patch removes sql/twophase
> from
Hi All,
I created a "Read-only" User in PostgreSQL via a Role with "SELECT" ONLY
privilege on all tables in a schema as shown below:
GRANT SELECT ON ALL TABLES IN SCHEMA [schema_name] TO [role_name]
GRANT [role_name] TO [user_name]
Next, I test this by trying to UPDATE a column in a table (same
I have committed the page_checksum function, will work on the bt stuff next.
I left in the superuser check, because I was not confident how well
pg_checksum_page() would handle messed up data.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
On Fri, Mar 17, 2017 at 6:13 PM, Amit Kapila wrote:
> On Fri, Mar 17, 2017 at 12:27 PM, Ashutosh Sharma
> wrote:
>> On Fri, Mar 17, 2017 at 8:20 AM, Amit Kapila wrote:
>>
>> As I said in my previous e-mail, I think you
I'm struggling to find a good way to share code between
bt_page_items(text, int4) and bt_page_items(bytea).
If we do it via the SQL route, as I had suggested, it makes the
extension non-relocatable, and it will also create a bit of a mess
during upgrades.
If doing it in C, it will be a bit
Hi,
Currently, clients wishing to know when the server exits hot standby
have to resort to polling, which is often suboptimal.
This adds the new "in_hot_standby" GUC variable that is reported via a
ParameterStatus message. This allows the clients to:
(a) know right away that they are
Heikki Linnakangas writes:
> Fix and simplify check for whether we're running as Windows service.
This seems to have broken narwhal:
Creating library file: libpostgres.a
../../src/port/libpgport_srv.a(win32security_srv.o)(.text+0x109): In function
`pgwin32_is_admin':
With some intensive crash-recovery testing, I've run into a situation where
I get some bad table bloat. There will be large swaths of the table which
are empty (all results from heap_page_items other than lp are either zero
or NULL), but have zero available space in the fsm, and are marked as
On 03/17/2017 12:28 PM, Tom Lane wrote:
> Petr Jelinek writes:
>> Now the documentation for WSAEventSelect says "The FD_WRITE network
>> event is handled slightly differently. An FD_WRITE network event is
>> recorded when a socket is first connected with a call to
I wrote:
> Petr Jelinek writes:
>> Thanks, now that I look at it again I think we might need to do cycle
>> with the occurred_events and returned_events and not return on first
>> find since theoretically there can be multiple sockets if this gets
>> called directly
>
> Nikhil, do you mind if I try something like that? As we already know
> what is the first XID when beginning redo via
> ShmemVariableCache->nextXid it is possible to discard 2PC files that
> should not be here.
Yeah, that is ok.
> What makes me worry is the control of the maximum
> number
At Mon, 13 Mar 2017 10:42:05 -0400, David Steele wrote in
<1e8297fd-f7f2-feab-848d-5121e45c8...@pgmasters.net>
> It has been a while since this thread has received any comments or a new
> patch. The general consensus seems to be that this feature is too large
> a rewrite of
At Fri, 10 Mar 2017 12:15:52 +0300, Nikita Glukhov
wrote in <48f6934b-b994-4aa2-b6ad-aaa4f5a12...@postgrespro.ru>
> On 10.03.2017 02:13, Tels wrote:
>
> > I can't comment on the code, but the grammar on the comments caught my
> > eye:
> >> +/* Can any range from
On Sun, Mar 12, 2017 at 8:11 AM, Robert Haas wrote:
> On Fri, Mar 10, 2017 at 7:39 PM, Amit Kapila wrote:
>> I agree that more analysis can help us to decide if we can use subxids
>> from PGPROC and if so under what conditions. Have you considered
On Fri, Mar 17, 2017 at 9:03 AM, Amit Kapila wrote:
> On Thu, Mar 16, 2017 at 1:15 PM, Ashutosh Sharma
> wrote:
>> Hi,
>>
>> Attached is the patch that allows WAL consistency tool to mask
>> 'LH_PAGE_HAS_DEAD_TUPLES' flag in hash index. The flag
On 2017/03/16 22:16, Robert Haas wrote:
> On Thu, Mar 16, 2017 at 6:03 AM, Amit Langote
> wrote:
>> I think we'll need to store *somewhere* the mapping of which inh=false
>> partitioned table RTE is the child of which inh=true (IOW, parent)
>> partitioned table RTE.
On Tue, Mar 14, 2017 at 1:35 AM, Michael Meskes wrote:
>> Previous 002 patch lacked to add describing PREPARE TRANSACTION.
>> Attached updated 002 patch.
>
> I just committed both patches and a backport of the bug fix itself.
> Thanks again for finding and fixing.
On 2017/03/17 10:38, Robert Haas wrote:
On Fri, Mar 10, 2017 at 2:46 AM, vinayak
wrote:
Thank you for reviewing the patch.
The attached patch incorporated Michael and Amit comments also.
I reviewed this tonight.
Thank you for reviewing the patch.
+
On Fri, Mar 17, 2017 at 8:20 AM, Amit Kapila wrote:
> On Thu, Mar 16, 2017 at 9:39 PM, Ashutosh Sharma
> wrote:
>>>
>>> Don't you think, we should also clear it during the replay of
>>> XLOG_HASH_DELETE? We might want to log the clear of
>
> >
> > I don't think this will work. We cannot replace pg_twophase with shmem
> > entries + WAL pointers. This is because we cannot expect to have WAL
> entries
> > around for long running prepared queries which survive across
> checkpoints.
>
> But at the beginning of recovery, we can mark
>
> >
> > Ok, we can do that and then yes, RecoverPreparedTransaction() can just
> have
> > one loop going through the shmem entries. BUT, we cannot ignore
> > "inredo"+"ondisk" entries. For such entries, we will have to read and
> > recover from the corresponding 2PC files.
>
> Yes. About other
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa,
> Takayuki
> I made this ready for committer. The patch applied except for catversion.h,
> the patch content looks good, and the target test passed as follows:
Sorry, I reverted this to
On Thu, Mar 16, 2017 at 1:18 PM, Michael Paquier
wrote:
> On Wed, Mar 15, 2017 at 9:14 PM, Kuntal Ghosh
> wrote:
>> I've attached the updated patches.
>
> Thanks for the new versions. This begins to look really clear.
Thanks again for the
On 03/17/2017 12:21 AM, MauMau wrote:
From: Heikki Linnakangas
So, I think we still need the check for Local System.
Thanks, fixed and confirmed that the error message is output in the
event log.
Committed, thanks!
- Heikki
--
Sent via pgsql-hackers mailing list
Hello,
Thank you for your comments, I will post an updated patch soon.
On Fri, Mar 17, 2017 at 6:40 AM, Robert Haas wrote:
>
>
> +assign_wal_segment_size(int newval, void *extra)
>
> Why does a PGC_INTERNAL GUC need an assign hook? I think the GUC
> should only be there
Hello David,
Repost from bugs.
This patch does not apply at cccbdde:
Indeed. It should not. The fix is for the 9.6 branch. The issue has been
fixed by some heavy but very welcome restructuring in master.
Marked as "Waiting for Author".
I put it back to "Needs review".
--
Fabien.
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Ashutosh Bapat
> The scope of this work has expanded, since last time I reviewed and marked
> it as RFC. Right now I am busy with partition-wise joins and do not have
> sufficient time to take a
1 - 100 of 139 matches
Mail list logo