On Tue, Oct 6, 2015 at 12:41 AM, Oleksii Kliukin wrote:
> pg_rewind -D postgresql0 --source-server="host=127.0.0.1 port=5433
> dbname=postgres"
> The servers diverged at WAL position 0/360 on timeline 1.
> could not open file "data/postgresql0/pg_xlog/00010002":
> No such file
On Tue, Oct 6, 2015 at 10:56 AM, Haribabu Kommi
wrote:
> Here I attached an updated version of the patch with the following changes.
I found some problems related to providing multi-tenancy on a system
catalog view.
This is because, system catalog view uses the owner that is created
the user inst
On Sun, Oct 4, 2015 at 1:18 AM, Andres Freund wrote:
> Hi,
>
> I quickly read through the patch, trying to understand what exactly is
> happening here. To me the way the patch is split doesn't make much sense
> - I don't mind incremental patches, but right now the steps don't
> individually make s
Hello,
At Thu, 01 Oct 2015 01:36:51 +0200, Tomas Vondra
wrote in <560c7213.3010...@2ndquadrant.com>
> > Good point. I think we may simply point indexrinfos to the existing
> > list
> > of restrictions in that case - we don't need to copy it. So no
> > additional memory / CPU consumption, and it
Hello, KaiGai-san.
Thank you for your comment, and sorry for late response.
> If inner-scan of the join under the append node has param_info, its qualifier
> shall be implicitly attached to the scan node. So, if it is legal, I'd like
> to have this approach because it is less invasive than enha
Zhaomo,
* Zhaomo Yang (zmp...@gmail.com) wrote:
> I just tried a little bit your patch for applying SELECT policies to
> DELETE/UPDATE. It is consistent with the GRANT system so it looks
> really good. I'll test it more thoroughly later.
Great! Glad to hear it.
> Also, I guess we don't need to
Stephen,
I just tried a little bit your patch for applying SELECT policies to
DELETE/UPDATE. It is consistent with the GRANT system so it looks
really good. I'll test it more thoroughly later.
Also, I guess we don't need to worry about the syntax of "restrictive
policies" you mentioned in the upt
On Wed, Apr 29, 2015 at 03:48:04PM -0400, Bruce Momjian wrote:
> On Tue, Apr 28, 2015 at 09:15:49AM -0400, Bruce Momjian wrote:
> > > It seems to me that waiting for 9.6 for what's arguably a bug fix is too
> > > much. It's not like this is a new feature. Why don't we just make sure
> > > it is a
On Fri, Sep 11, 2015 at 7:50 AM, Joe Conway wrote:
> On 09/01/2015 11:25 PM, Haribabu Kommi wrote:
>> If any user is granted any permissions on that object then that user
>> can view it's meta data of that object from the catalog tables.
>> To check the permissions of the user on the object, inste
Hello.
There is patch that adds some editing routines for tsvector type.
tsvector delete(tsvector, text)
removes entry from tsvector by lexeme name
set unnest(tsvector)
expands a tsvector to a set of rows. Each row has following columns:
lexeme, postings, weights.
text[] to_array
Andrew Dunstan wrote:
> I'm rather tired of having to update two sets of output files every time we
> change the json and jsonb regression tests. Also, other committers
> occasionally fall over this trap and fail to update json_1.out and
> jsonb_1.out, as do almost all other patch authors. I propos
> On 05 Oct 2015, at 18:04, Bruce Momjian wrote:
>
> On Mon, Oct 5, 2015 at 05:41:07PM +0200, Oleksii Kliukin wrote:
>> Hello,
>>
>> I'm trying to find out how to rewind a cluster that was not shut down
>> cleanly, in order to implement pg_rewind support in patroni (an
>> automated failover sy
On 10/05/2015 01:53 PM, Tom Lane wrote:
Andrew Dunstan writes:
I'm rather tired of having to update two sets of output files every time
we change the json and jsonb regression tests. Also, other committers
occasionally fall over this trap and fail to update json_1.out and
jsonb_1.out, as do a
Andrew Dunstan writes:
> I'm rather tired of having to update two sets of output files every time
> we change the json and jsonb regression tests. Also, other committers
> occasionally fall over this trap and fail to update json_1.out and
> jsonb_1.out, as do almost all other patch authors. I p
On Mon, Oct 5, 2015 at 10:32 AM, Andrew Dunstan wrote:
> I'm rather tired of having to update two sets of output files every time we
> change the json and jsonb regression tests. Also, other committers
> occasionally fall over this trap and fail to update json_1.out and
> jsonb_1.out, as do almost
On Mon, Oct 5, 2015 at 8:50 AM, Tom Lane wrote:
> That's certainly something worth looking at, but I think it's probably
> more complicated than that. If you just write "WHERE x IN (1,2,3,4)",
> that gets folded to a ScalarArrayOp with a single array constant, which
> the existing code would deal
I'm rather tired of having to update two sets of output files every time
we change the json and jsonb regression tests. Also, other committers
occasionally fall over this trap and fail to update json_1.out and
jsonb_1.out, as do almost all other patch authors. I propose that we
remove those tes
Peter,
On Monday, October 5, 2015, Peter Geoghegan wrote:
> 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?
>
Away from my keyboard at the moment,
>
> > So you would suggest changing my message chain to send Bind right after
> > Execute, right? This would yield the following messages:
>
> > P1/P2/D1/B1/E1/D2/B2/E2/S (rather than the current
> > P1/D1/B1/P2/D2/B2/E1/C1/E2/C2/S)
>
> > This would mean that I would switch to using named statement
On Mon, Oct 5, 2015 at 11:03 PM, Fujii Masao wrote:
> On Fri, Oct 2, 2015 at 8:14 PM, Masahiko Sawada wrote:
>>> +#define Anum_pg_class_relallfrozen12
>>> Why is pg_class.relallfrozen necessary? ISTM that there is no user of it
>>> now.
>>
>> The relallfrozen would be useful for user to
On Mon, Oct 5, 2015 at 05:41:07PM +0200, Oleksii Kliukin wrote:
> Hello,
>
> I'm trying to find out how to rewind a cluster that was not shut down
> cleanly, in order to implement pg_rewind support in patroni (an
> automated failover system, https://github.com/zalando/patroni).
>
> At the moment
Alvaro Herrera writes:
> Andrew Dunstan wrote:
>> FWIW, (a) and (b) but not (c) is probably the right description for my
>> client who has been seeing problems here.
> I think the fact that long IN lists are fingerprinted differently
> according to the number of elements in the list makes the sce
Hello,
I'm trying to find out how to rewind a cluster that was not shut down
cleanly, in order to implement pg_rewind support in patroni (an
automated failover system, https://github.com/zalando/patroni).
At the moment, pg_rewind limits itself to only cleanly shut down
clusters. This works nicely
Andrew Dunstan wrote:
>
> On 10/05/2015 11:15 AM, Tom Lane wrote:
> >Peter Geoghegan writes:
> >>I'm annoyed and disappointed that the patch committed does not even
> >>begin to address the underlying problem -- it just adds an escape
> >>hatch, and fixes another theoretical issue that no one was
Andres Freund wrote:
> But more seriously: Given the upstream support policies from
> https://www.openssl.org/policies/releasestrat.html :
> "
> Support for version 0.9.8 will cease on 2015-12-31. No further releases of
> 0.9.8 will be made after that date. Security fixes only will be applied to
Nathan Wagner wrote:
> 1: Can a bug be more than "open" or "closed"?
>
> I think yes. At least we probably want to know why a bug is closed. Is it
> not
> a bug at all, not our bug, a duplicate submission, a duplicate of another bug,
> something we won't fix for some reason (e.g. a bug against
On 2015-10-05 12:16:05 -0300, Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
>
> > In short, pgcrypto actually used to use the EVP functions, but was changed
> > to *not* use them, because in older versions of OpenSSL, some key lengths
> > and/or padding options that pgcrypto supports were not
On 10/05/2015 11:15 AM, Tom Lane wrote:
Peter Geoghegan writes:
I'm annoyed and disappointed that the patch committed does not even
begin to address the underlying problem -- it just adds an escape
hatch, and fixes another theoretical issue that no one was affected
by. Honestly, next time I w
Heikki Linnakangas wrote:
> In short, pgcrypto actually used to use the EVP functions, but was changed
> to *not* use them, because in older versions of OpenSSL, some key lengths
> and/or padding options that pgcrypto supports were not supported by the EVP
> API. That was fixed in OpenSSL 0.9.7, h
Peter Geoghegan writes:
> I'm annoyed and disappointed that the patch committed does not even
> begin to address the underlying problem -- it just adds an escape
> hatch, and fixes another theoretical issue that no one was affected
> by. Honestly, next time I won't bother.
The problem as I see it
Hi hackers, some odd behavior has been reported with Npgsql and I wanted to
get your help.
Npgsql supports sending multiple SQL statements in a single packet via the
extended protocol. This works fine, but when the second query SELECTs a
value modified by the first's UPDATE, I'm getting a result a
I don't have the original message for this thread, so I arbitrarily picked a
message to reply to.
Since what has been asked for is a bug *tracker*, and we already have a bugs
mailing list, I put together something.
I downloaded the archives for pgsql-bugs, and fed them into a database. This
part
On Mon, Oct 5, 2015 at 5:32 AM, Magnus Hagander wrote:
>
>
> On Mon, Oct 5, 2015 at 12:42 AM, Nathan Wagner
> wrote:
>>
>> I don't have the original message for this thread, so I arbitrarily picked
>> a
>> message to reply to.
>>
>> Since what has been asked for is a bug *tracker*, and we already
On 10/05/2015 06:02 AM, Heikki Linnakangas wrote:
> There was prior discussion on the EVP API in this old thread from 2007:
> http://www.postgresql.org/message-id/flat/46a5e284.7030...@sun.com#46a5e284.7030...@sun.com
>
>
> In short, pgcrypto actually used to use the EVP functions, but was
> chan
On 10 September 2015 at 01:58, Andres Freund wrote:
> On 2015-09-04 23:35:42 +0100, Simon Riggs wrote:
> > This looks OK. You saw that I was proposing to solve this problem a
> > different way ("Summary of plans to avoid the annoyance of Freezing"),
> > suggesting that we wait for a few CFs to se
* Andres Freund (and...@anarazel.de) wrote:
> On 2015-10-05 08:01:00 -0400, Stephen Frost wrote:
> > Peter, all,
> > I had intended to address with policies what is addressed through
> > permissions with 7d8db3e, but the coverage for INSERT+RETURNING was only
> > done when ON CONFLICT was in use.
>
Thanks for your answer:)
>This is introduced by the commit 5a991ef, which allows logical
>decoding via walsender interface. The paramter replication has
>been there far from the commit intentionary as an 'undocumented
>paramter'. This is, I suppose, because it is treated as a part of
>the replicat
On Fri, Oct 2, 2015 at 8:14 PM, Masahiko Sawada wrote:
>> +#define Anum_pg_class_relallfrozen12
>> Why is pg_class.relallfrozen necessary? ISTM that there is no user of it now.
>
> The relallfrozen would be useful for user to estimate time to vacuum
> freeze or anti-wrapping vacuum before
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I had intended to address with policies what is addressed through
> > permissions with 7d8db3e, but the coverage for INSERT+RETURNING was only
> > done when ON CONFLICT was in use.
>
> > I've fixed that by applying the SELECT poli
Andres Freund writes:
> On 2015-10-05 09:39:58 -0400, Tom Lane wrote:
>> How about "Setting autovacuum_freeze_max_age to very small values
>> is unwise since it will force frequent vacuuming."
> Well, you still can't really set it to a very small value - the lower
> limits are still 100k/10k for
On 2015-10-05 09:39:58 -0400, Tom Lane wrote:
> Andres Freund writes:
> > How about simply removing that sentence? I.e. something like
> > autovacuum_freeze_max_age larger than the system-wide
> > setting
> > - (it can only be set smaller). Note that while you can set
> > - autovacu
Stephen Frost writes:
> I had intended to address with policies what is addressed through
> permissions with 7d8db3e, but the coverage for INSERT+RETURNING was only
> done when ON CONFLICT was in use.
> I've fixed that by applying the SELECT policies as WCOs for both the
> INSERT and UPDATE RETUR
Andres Freund writes:
> On 2015-09-24 12:39:54 -0300, Alvaro Herrera wrote:
>> I'm surprised the error has survived this long. Without checking I
>> can't say what's the best solution either, but I would opt for
>> documenting the limits we have -- if we want to change them back to 0 I
>> say tha
pgcrypto uses the old, deprecated, "low-level" functions for symmetric
encryption, with algorithm-specific functions like AES_ecb_encrypt(),
DES_ecb3_encrypt() and so forth. The recommended new API is the
so-called EVP API, which has functions for initializing a "context"
using a specific algor
On Sun, Oct 4, 2015 at 10:21 AM, Amit Kapila
wrote:
>
> On Sat, Oct 3, 2015 at 11:35 PM, Robert Haas
wrote:
> >
> > On Fri, Oct 2, 2015 at 11:44 PM, Amit Kapila
wrote:
> > > On Thu, Oct 1, 2015 at 7:41 PM, Robert Haas
wrote:
> > >> Does heap_parallelscan_nextpage really need a pscan_finished ou
Andres,
On Monday, October 5, 2015, Andres Freund wrote:
> On 2015-10-05 08:01:00 -0400, Stephen Frost wrote:
> > Peter, all,
> > I had intended to address with policies what is addressed through
> > permissions with 7d8db3e, but the coverage for INSERT+RETURNING was only
> > done when ON CONFLI
On 2015-10-05 08:01:00 -0400, Stephen Frost wrote:
> Peter, all,
> I had intended to address with policies what is addressed through
> permissions with 7d8db3e, but the coverage for INSERT+RETURNING was only
> done when ON CONFLICT was in use.
>
> I've fixed that by applying the SELECT policies as
Thanks for the help Tom and the others, I'll modify my sequence and report
if I encounter any further issues.
On Sun, Oct 4, 2015 at 7:36 PM, Tom Lane wrote:
> Shay Rojansky writes:
> >> To my mind there is not a lot of value in performing Bind until you
> >> are ready to do Execute. The only
Peter, all,
* Peter Geoghegan (p...@heroku.com) wrote:
> I see now that commit 4f3b2a8883 changed things for UPDATE and DELETE
> statements, but not INSERT statements. I guess my unease is because
> that isn't entirely consistent with INSERT + RETURNING and the GRANT
> system. Logically, the only
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> >> Also, these were added in 9.4, so introducing this many differences
> >> between 9.4 and 9.5+ will make back-patching harder.
>
> > That's certainly true, but we don't want cur
On Mon, Oct 5, 2015 at 12:42 AM, Nathan Wagner
wrote:
> I don't have the original message for this thread, so I arbitrarily picked
> a
> message to reply to.
>
> Since what has been asked for is a bug *tracker*, and we already have a
> bugs
> mailing list, I put together something.
>
FWIW, I th
On Sat, Oct 3, 2015 at 3:41 AM, Robert Haas wrote:
> On Fri, Oct 2, 2015 at 11:23 AM, Alvaro Herrera
> wrote:
>>> + /* all-frozen information is also cleared at the same time */
>>> PageClearAllVisible(page);
>>> + PageClearAllFrozen(page);
>>
>> I wonder if
Hello,
At Fri, 2 Oct 2015 23:13:24 +0900, Takashi Ohnishi wrote
in
> I found that it can be set like 'replication = true' in connection
> parameter as documentation says in "50.3. Streaming Replication Protocol",
> but this parameter is not denoted in "31.1.2. Parameter Key Words".
This is in
On 2015-09-24 12:39:54 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2015-09-24 10:37:33 -0400, Tom Lane wrote:
> > > Andres Freund writes:
>
> > > Should this patch not have also touched the per-table limits in
> > > reloptions.c?
> >
> > Hm. I guess that'd make sense. It's not rea
On 2015/09/29 16:36, Etsuro Fujita wrote:
For the foreign table case (scanrelid>0), I imagined an approach
different than yours. In that case, I thought the issue would be
probably addressed by just modifying the remote query performed in
RefetchForeignRow, which would be of the form "SELECT cti
On Mon, Oct 5, 2015 at 2:08 AM, Nathan Wagner wrote:
> On Sun, Oct 04, 2015 at 04:30:49PM -0700, Josh Berkus wrote:
> > That would be the key part, wouldn't it? Nice that you have [code to
> > store and parse email messages].
>
> Yeah. It actually made most of the work pretty easy. It's availa
On Mon, Oct 5, 2015 at 3:08 AM, Nathan Wagner wrote:
> On Sun, Oct 04, 2015 at 04:30:49PM -0700, Josh Berkus wrote:
> > That would be the key part, wouldn't it? Nice that you have [code to
> > store and parse email messages].
>
> Yeah. It actually made most of the work pretty easy. It's availa
I think "best_inner_indexscan()" in the following comment in tidpath.c
is obsolete.
* There is currently no special support for joins involving CTID; in
* particular nothing corresponding to best_inner_indexscan(). Since it's
* not very useful to store TIDs of one table in another table, there
58 matches
Mail list logo
