Hi all,
As CVE-2016-5424 has put recently in light, using LF and CR in
database and role names can lead to unexpected problems in the way
they are handled in logical backups or generated command lines. There
is as well a comment in the code mentioning a potential restriction
for that, precisely in
On 8/11/16 4:54 PM, Tom Lane wrote:
which probably contributes to Jim's confusion. I think what is happening
in the trouble case is that since IS has lower precedence than Op, the
grammar decides it ought to resolve || as a postfix operator, and then
it effectively has
('x' ||) IS ...
On 8/11/16 10:59 AM, Jeff Janes wrote:
On Thu, Aug 11, 2016 at 8:32 AM, Amit Kapila wrote:
On Thu, Aug 11, 2016 at 2:09 AM, Jeff Janes wrote:
I wanted to create a new relopt named something like
autovacuum_vacuum_pagevisible_factor which would cause autovacuum to
vacuum a table once less than
On Thu, Aug 11, 2016 at 8:44 PM, Thomas Munro
wrote:
> In contrast, this proposal leaves it up to client code to get that
> right, similarly to the way you need to do things in a certain order
> when waiting for state changes with latches. You could say that it's
> more error prone: I think there
On Thu, Aug 11, 2016 at 6:37 PM, Peter Geoghegan wrote:
> I notice that you acquire a spinlock within the implementation of
> condition variables. Is it worth any effort to consolidate the number
> of spinlock acquisitions? In other words, maybe the most common idioms
> should be baked into the Co
On Thu, Aug 11, 2016 at 6:12 PM, Tom Lane wrote:
>> But if we replace the io_in_progress locks with
>> condition variables, then that doesn't happen any more. Nobody is
>> "holding" the condition variable, so it doesn't get "released" when
>> the process doing I/O aborts. Instead, they just keep
On Fri, Aug 12, 2016 at 9:47 AM, Robert Haas wrote:
> https://en.wikipedia.org/wiki/Monitor_(synchronization)#Condition_variables_2
>
> Basically, a condition variable has three operations: you can wait for
> the condition variable; you can signal the condition variable to wake
> up one waiter; or
On Fri, Aug 12, 2016 at 12:51 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 8/11/16 6:04 AM, Aleksander Alekseev wrote:
>>> Suggested patch introduces an %r substitution in psql's prompt. This
>>> substitution allows to display whether user is connected to master or
>>> replica right in a
Michael Paquier writes:
> In short, autovacuum will need to scan by itself the VM of each
> relation and decide based on that.
That seems like a worthwhile approach to pursue. The VM is supposed to be
small, and if you're worried it isn't, you could sample a few pages of it.
I do not think any o
On Thu, Aug 11, 2016 at 01:04:19PM +0300, Aleksander Alekseev wrote:
> Hello.
>
> Suggested patch introduces an %r substitution in psql's prompt. This
> substitution allows to display whether user is connected to master or
> replica right in a prompt.
This is a neat idea, but there are some issue
On Thu, Aug 11, 2016 at 4:21 PM, Michael Paquier
wrote:
> On Thu, Aug 11, 2016 at 3:29 PM, Michael Paquier
> wrote:
>> On Thu, Aug 11, 2016 at 5:39 AM, Jeff Janes wrote:
>>> I wanted to create a new relopt named something like
>>> autovacuum_vacuum_pagevisible_factor which would cause autovacuum
On Thu, Aug 11, 2016 at 2:47 PM, Robert Haas wrote:
> Another approach to the problem is to use a latch wait loop. That
> almost works. Interrupts can be serviced, and you can recheck shared
> memory to see whether the condition for proceeding is satisfied after
> each iteration of the loop. Th
Robert Haas writes:
> I had what I think is a better idea, which is to introduce a notion of
> condition variables.
Interesting proposal.
> ... Using condition variables here seems to
> have a couple of advantages. First, it means that a backend waiting
> for buffer I/O to complete is interrupt
"David E. Wheeler" writes:
> On Aug 11, 2016, at 2:11 PM, Jim Nasby wrote:
>> SELECT 'x'||is();
>> ERROR: syntax error at or near "("
> Why does it need quotation marks in this case?
It doesn't, if you do something like
regression=# select is();
ERROR: function is() does not exist
LINE 1: se
Hi,
Some of my EnterpriseDB colleagues and I have been working on various
parallel query projects, all of which have been previously disclosed
here:
https://wiki.postgresql.org/wiki/EnterpriseDB_database_server_roadmap
One issue we've encountered is that it's not very easy for one process
in a g
On Aug 11, 2016, at 2:11 PM, Jim Nasby wrote:
> CREATE FUNCTION pg_temp.is() RETURNS text LANGUAGE sql AS $$SELECT
> 'x'::text$$;
> SELECT 'x'||is();
> ERROR: syntax error at or near "("
> LINE 1: SELECT 'x'||is();
>
> I was finally able to figure out this was because "is" needs to be quoted;
This is awesome. I will build it to start using and testing it in my
development environment. Thank you so much for making this change.
On Thu, Aug 11, 2016 at 11:33 AM Tom Lane wrote:
> In
> https://www.postgresql.org/message-id/15293.1466536...@sss.pgh.pa.us
> I speculated that it might not ta
Simon Riggs wrote:
> Good catch.
>
> I've updated Julien's patch to reflect Michael's suggestion.
>
> Looks good to apply immediately.
>
> 14e8803f1 was only a partial patch for the syncrep code, so I don't
> see any reason to keep the code as it currently is in 9.5/9.6.
>
> Any objections to
CREATE FUNCTION pg_temp.is() RETURNS text LANGUAGE sql AS $$SELECT
'x'::text$$;
SELECT 'x'||is();
ERROR: syntax error at or near "("
LINE 1: SELECT 'x'||is();
I was finally able to figure out this was because "is" needs to be
quoted; is there a way this could be hinted?
FWIW, the real-world
On 8/5/16 1:14 PM, Tom Lane wrote:
> No, I don't think it's sufficient after a multiplication by 10. That
> would be enough to shift some bits clear out of the word, but there's
> no certainty that the new sign bit would be 1.
>
> The scheme used in scanint8 is safe. But I think it was written t
Robert Haas writes:
> On Thu, Aug 11, 2016 at 11:35 AM, Tom Lane wrote:
>> Well, if it's unqueryable they won't be able to query it no matter how
>> hard they try ;-).
> Sure, but as this thread already demonstrates, they may also complain
> forcefully about having lost that capability. You arg
Kevin Grittner writes:
> On Wed, Aug 10, 2016 at 5:14 PM, Tom Lane wrote:
>> In short, I do not see a good reason to expose ampredlocks at the SQL
>> level, and I think there needs to be a darn good reason to expose any of
>> this stuff, not just "maybe some DBA will think he needs to query this"
In
https://www.postgresql.org/message-id/15293.1466536...@sss.pgh.pa.us
I speculated that it might not take too much to replace all the variants
of GIN array_ops with a single polymorphic opclass over anyarray.
Attached is a proposed patch that does that.
There are two bits of added functionality
On 08/11/2016 10:46 AM, Kevin Grittner wrote:
On Wed, Aug 10, 2016 at 5:14 PM, Tom Lane wrote:
Kevin Grittner writes:
But a DBA who has a problem doesn't care what the truth will be in
a year or two -- the interest is in *right now* on one particular
cluster.
If you are a DBA wanting to k
On Thu, Jul 28, 2016 at 6:51 PM, Thomas Munro
wrote:
> That version didn't actually make LWLock any smaller, because of the
> additional offset stored in proclist_head when initialising the list.
> Here is a new version that requires callers to provide it when
> accessing the list, bringing sizeof
On Wed, Aug 10, 2016 at 5:14 PM, Tom Lane wrote:
> Kevin Grittner writes:
>> Where [whether the AM supports predicate locking at a
>> granularity finer than the provided default of index relation]
>> would be interesting to know is [ ... ] (when there is more than
>> just btree supported, so it
On Thu, Aug 11, 2016 at 11:07 AM, Jim Nasby wrote:
> On 8/10/16 12:48 PM, Claudio Freire wrote:
>>
>> On Tue, Aug 9, 2016 at 11:39 PM, Jim Nasby
>> wrote:
>>>
>>> On 8/9/16 6:44 PM, Claudio Freire wrote:
Since we can lookup all occurrences of k1=a index=0 and k2=a index=0,
and
On Thu, Aug 11, 2016 at 4:22 AM, Palle Girgensohn wrote:
> But in your strxfrm code in PostgreSQL, the keys are cached, and represented
> as int64:s if I remember correctly, so perhaps there is still a benefit
> using the abbreviated keys? More testing is required, I guess...
ICU's ucol_nextSortK
On Thu, Aug 11, 2016 at 10:42 AM, Ryan Pedela
wrote:
> On Thu, Aug 11, 2016 at 9:27 AM, Oleg Bartunov
> wrote:
>
>> On Tue, Aug 9, 2016 at 9:59 PM, Ryan Pedela
>> wrote:
>> >
>> >
>>
>> > I would say that it is worth it to have a "phrase slop" operator
>> (Apache
>> > Lucene terminology). Prox
On Thu, Aug 11, 2016 at 9:27 AM, Oleg Bartunov wrote:
> On Tue, Aug 9, 2016 at 9:59 PM, Ryan Pedela
> wrote:
> >
> >
>
> > I would say that it is worth it to have a "phrase slop" operator (Apache
> > Lucene terminology). Proximity search is extremely useful for improving
> > relevance and phras
On Thu, Aug 11, 2016 at 5:24 PM, Robert Haas wrote:
> You argue against
> these things on the grounds that they might change later, but the
> overwhelming evidence from posts on this list is that people would
> prefer to have access to APIs that might not be stable rather than
> have no access a
On Thu, Aug 11, 2016 at 11:35 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 10, 2016 at 6:14 PM, Tom Lane wrote:
>>> In short, I do not see a good reason to expose ampredlocks at the SQL
>>> level, and I think there needs to be a darn good reason to expose any of
>>> this stuff, not j
On Thu, Aug 11, 2016 at 8:32 AM, Amit Kapila wrote:
> On Thu, Aug 11, 2016 at 2:09 AM, Jeff Janes wrote:
>> I wanted to create a new relopt named something like
>> autovacuum_vacuum_pagevisible_factor which would cause autovacuum to
>> vacuum a table once less than a certain fraction of the relat
Peter Eisentraut writes:
> On 8/11/16 6:04 AM, Aleksander Alekseev wrote:
>> Suggested patch introduces an %r substitution in psql's prompt. This
>> substitution allows to display whether user is connected to master or
>> replica right in a prompt.
> In the near future, there will (probably) be a
On 8/11/16 6:04 AM, Aleksander Alekseev wrote:
> Suggested patch introduces an %r substitution in psql's prompt. This
> substitution allows to display whether user is connected to master or
> replica right in a prompt.
In the near future, there will (probably) be a lot more variants about
what it
Robert Haas writes:
> On Wed, Aug 10, 2016 at 6:14 PM, Tom Lane wrote:
>> In short, I do not see a good reason to expose ampredlocks at the SQL
>> level, and I think there needs to be a darn good reason to expose any of
>> this stuff, not just "maybe some DBA will think he needs to query this".
On 8/5/16 11:25 AM, Peter Eisentraut wrote:
> On 8/4/16 2:21 PM, Tom Lane wrote:
>> Forgot to mention: seems like you should have added a location
>> argument to makeDefElem.
>
> I was hesitating to do that lest it break extensions or something, but I
> guess we break bigger things than that all t
On Thu, Aug 11, 2016 at 2:09 AM, Jeff Janes wrote:
> I wanted to create a new relopt named something like
> autovacuum_vacuum_pagevisible_factor which would cause autovacuum to
> vacuum a table once less than a certain fraction of the relation's
> pages are marked allvisible.
>
Why would it more
On Tue, Aug 9, 2016 at 9:59 PM, Ryan Pedela wrote:
>
>
> I would say that it is worth it to have a "phrase slop" operator (Apache
> Lucene terminology). Proximity search is extremely useful for improving
> relevance and phrase slop is one of the tools to achieve that.
>
It'd be great if you exp
> I have found a basic use case which is supported by the xml2 module,
> but is unsupported by the new XML API.
> It is not possible to correctly extract text
Indeed. I came accross this shortcomming some months ago myself but still
manage an item on my ToDo list to report it here as the depreca
Hi,
On 11/08/16 13:34, Stas Kelvich wrote:
* max_logical_replication_workers mentioned everywhere in docs, but guc.c
defines
variable called max_logical_replication_processes for postgresql.conf
Ah changed it in code but not in docs, will fix.
* Since pg_subscription already shared across
On Thu, Aug 11, 2016 at 1:22 PM, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
2) The driver can use safepoints and autorollback to the good "right before
> failure" state in case of a known failure. Here's the implementation:
> https://github.com/pgjdbc/pgjdbc/pull/477
>
As far as I can
On 8/10/16 12:48 PM, Claudio Freire wrote:
On Tue, Aug 9, 2016 at 11:39 PM, Jim Nasby wrote:
On 8/9/16 6:44 PM, Claudio Freire wrote:
Since we can lookup all occurrences of k1=a index=0 and k2=a index=0,
and in fact we probably did so already as part of the update logic
That's a change fro
On Thu, Aug 11, 2016 at 3:24 AM, Peter Eisentraut
wrote:
> On 8/7/16 9:44 PM, Michael Paquier wrote:
This is not a good
>> idea, and the idea of putting a wait argument in get_controlfile does
>> not seem a good interface to me. I'd rather see get_controlfile be
>> extended wit
Shay>As I said, an error is going to kill the ongoing transaction, how can
this be solved without application logic?
1) At least, some well-defined error code should be created for that kind
of matter.
2) The driver can use safepoints and autorollback to the good "right before
failure" state in c
On Thu, Aug 11, 2016 at 2:11 AM, Venkata Balaji N wrote:
>
> [...]
> committing all the previously open transactions
> [...]
>
"All"? There can only ever be at most one open transaction at any given
time...
I don't have a fundamental issue with saying "when turning auto-commit on
you are a
> On 05 Aug 2016, at 18:00, Petr Jelinek wrote:
>
> Hi,
>
> as promised here is WIP version of logical replication patch.
Great!
Proposed DDL about publication/subscriptions looks very nice to me.
Some notes and thoughts about patch:
* Clang grumbles at following pieces of code:
apply.c:13
> 11 aug. 2016 kl. 11:15 skrev Palle Girgensohn :
>
>>
>> 11 aug. 2016 kl. 03:05 skrev Peter Geoghegan :
>>
>> On Wed, Aug 10, 2016 at 1:42 PM, Palle Girgensohn
>> wrote:
>>> They've been used for the FreeBSD ports since 2005, and have served us
>>> well. I have of course updated them regula
On Thu, Aug 11, 2016 at 8:39 AM, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> Shay:
>
>> Prepared statements can have very visible effects apart from the speedup
>> they provide (e.g. failure because of schema changes) It's not that
>> these effects can't be worked around - they can
Hello.
Suggested patch introduces an %r substitution in psql's prompt. This
substitution allows to display whether user is connected to master or
replica right in a prompt.
Usage example:
```
$ cat ~/.psqlrc
\set PROMPT1 '%p (%r) =# '
$ psql -p 5432
psql (9.6beta4)
Type "help" for help.
20638
Hello,
On 14.07.2016 12:16, Pavel Stehule wrote:
last point was discussed in thread related to to_date_valid function.
Regards
Pavel
Thank you.
Here is my patch. It is a proof of concept.
Date/Time Formatting
There are changes in date/time formatting rules:
- now to
> 11 aug. 2016 kl. 03:05 skrev Peter Geoghegan :
>
> On Wed, Aug 10, 2016 at 1:42 PM, Palle Girgensohn wrote:
>> They've been used for the FreeBSD ports since 2005, and have served us well.
>> I have of course updated them regularly. In this latest version, I've
>> removed support for other en
On 11/08/16 8:48 AM, Michael Paquier wrote:
On Thu, Aug 11, 2016 at 8:09 AM, Marko Tiikkaja wrote:
On 2016-08-11 12:09 AM, Alvaro Herrera wrote:
BTW this is not a regression, right? It's been broken all along. Or am
I mistaken?
You're probably right. I just hadn't realized I could run ou
Shay:
> Prepared statements can have very visible effects apart from the speedup
> they provide (e.g. failure because of schema changes) It's not that these
> effects can't be worked around - they can be - but programmers can be
> surprised by these effects, which can cause difficult-to-diagnose
Vladimir wrote:
Shay> As Tom said, if an application can benefit from preparing, the
> developer has the responsibility (and also the best knowledge) to manage
> preparation, not the driver. Magical behavior under the hood causes
> surprises, hard-to-diagnose bugs etc.
>
> Why do you do C# then?
>
On Thu, Aug 11, 2016 at 3:29 PM, Michael Paquier
wrote:
> On Thu, Aug 11, 2016 at 5:39 AM, Jeff Janes wrote:
>> I wanted to create a new relopt named something like
>> autovacuum_vacuum_pagevisible_factor which would cause autovacuum to
>> vacuum a table once less than a certain fraction of the r
56 matches
Mail list logo
