Robert Haas writes:
> After some study, I think the best thing to do here is change the way
> we handle the case where we reach a step that the use of a connection
> that is currently blocked on a lock. Right now, we handle that by
> declaring the permutation invalid; I'd like to change that so t
Robert Haas wrote:
> On Fri, Aug 14, 2015 at 2:57 PM, Alvaro Herrera
> wrote:
> > Hmm, clearly you couldn't attach the info to the step itself, because a
> > step that blocks in one permutation doesn't necessarily block in every
> > permutation. You could attach it to each step that needed it in
2015-08-15 0:55 GMT-03:00 Tom Lane :
> I don't think we should accept a patch along this line, because it assigns
> a very specific meaning to "semester" that does not square all that well
> with real-world usage.
I agree that "semester" was not nice, the real meaning is "half" or
"halfyear" as me
"David G. Johnston" writes:
> On Friday, August 14, 2015, Dickson S. Guedes wrote:
>> The term is used in a school or college to represent a half-year.
> I quite dislike semester because of its connotations in education and the
> fact that actual semesters do not align with calendar halves.
It'
On Fri, Aug 14, 2015 at 2:40 PM, Andres Freund wrote:
> To pick up on the general discussion and on the points you made here:
>
> I actually think the split came out to work far better than I'd
> anticipated. Having a slimmed-down version of lock.h for code that just
> needs to declare/pass lockmo
On Fri, Aug 14, 2015 at 8:40 PM, David G. Johnston
wrote:
> Tbh, "quarter in (1,2)" does not seem that problematic...
Yeah. It's so easy to compute the half from the quarter (or even from
the month) that I can't see adding this.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Ente
On Fri, Aug 14, 2015 at 6:11 PM, Dickson S. Guedes
wrote:
> 2015-08-14 21:40 GMT-03:00 David G. Johnston :
> > On Friday, August 14, 2015, Dickson S. Guedes
> wrote:
> >>
> >>
> >> The term is used in a school or college to represent a half-year.
> >> Actually it could be evaluated from a date
On Fri, Aug 14, 2015 at 5:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> Commit f14a6bbedb79adce2298d0d4f5e2abe8563e0eca added an isolation
>> test, alter-table-1.spec, which reads in part:
>
>> session "s2"
>> setup { BEGIN; }
>> step "rx1" { SELECT * FROM b WHERE a_id = 1 LIMIT
On 8/14/15 12:11 AM, Jim Nasby wrote:
I favor splitting the regression tests to add "all the time" and
"before commit" targets as you describe. I think that once the
facility is there, we can determine over time how expansive that
second category gets to be.
I don't know how many folks work in
2015-08-14 21:40 GMT-03:00 David G. Johnston :
> On Friday, August 14, 2015, Dickson S. Guedes wrote:
>>
>>
>> The term is used in a school or college to represent a half-year.
>> Actually it could be evaluated from a date using some math with
>> 'quarter' but could not be extracted from date sinc
On 15/08/15 13:06, Dickson S. Guedes wrote:
2015-08-14 21:32 GMT-03:00 Gavin Flower :
...
So semesters don't appear to align with normal half year boundaries.
Interesting links, thanks!
Which sounds better for a native English: 'half', 'halfyear'?
For example:
SELECT date_trunc('halfyear',
2015-08-14 21:32 GMT-03:00 Gavin Flower :
...
> So semesters don't appear to align with normal half year boundaries.
Interesting links, thanks!
Which sounds better for a native English: 'half', 'halfyear'?
For example:
> SELECT date_trunc('halfyear', current_date);
date_trunc
---
On Friday, August 14, 2015, Dickson S. Guedes wrote:
>
> The term is used in a school or college to represent a half-year.
> Actually it could be evaluated from a date using some math with
> 'quarter' but could not be extracted from date since the API to define
> a "reserved word" for EXTRACT is
On 15/08/15 11:58, Dickson S. Guedes wrote:
Hello hackers,
* Description
This patch is a proposal to allow the use of word 'semester' to
extract it from date in functions like EXTRACT, DATE_PART, etc and
adds the letter 'S' to format the date output in to_char.
** Example
SELECT EXTRACT(semes
2015-08-14 20:58 GMT-03:00 Dickson S. Guedes :
> Hello hackers,
>
> * Description
>
> This patch is a proposal
Now patch attached, sorry.
--
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://github.com/guedes - http://guedesoft.net
http://www.postgresql.org.br
allow_sem
Hello hackers,
* Description
This patch is a proposal to allow the use of word 'semester' to
extract it from date in functions like EXTRACT, DATE_PART, etc and
adds the letter 'S' to format the date output in to_char.
** Example
SELECT EXTRACT(semester FROM DATE '2015-07-07');
date_part
--
Robert Haas writes:
> Commit f14a6bbedb79adce2298d0d4f5e2abe8563e0eca added an isolation
> test, alter-table-1.spec, which reads in part:
> session "s2"
> setup { BEGIN; }
> step "rx1" { SELECT * FROM b WHERE a_id = 1 LIMIT 1; }
> step "wx" { INSERT INTO b VALUES (0); }
> ste
Bear Giles writes:
> Hi, I'm working on a FDW for the unix/linux user database - think
> /etc/passwd and /etc/group although I'm actually using system calls that
> could be quietly redirected to LDAP or other backends. It's easy to create
> the FDW and a table associated with it, something like
>
Commit f14a6bbedb79adce2298d0d4f5e2abe8563e0eca added an isolation
test, alter-table-1.spec, which reads in part:
session "s2"
setup { BEGIN; }
step "rx1" { SELECT * FROM b WHERE a_id = 1 LIMIT 1; }
step "wx" { INSERT INTO b VALUES (0); }
step "rx1" { SELECT * FROM b WHER
Hi, I'm working on a FDW for the unix/linux user database - think
/etc/passwd and /etc/group although I'm actually using system calls that
could be quietly redirected to LDAP or other backends. It's easy to create
the FDW and a table associated with it, something like
CREATE TABLE passwd (
name
Robert Haas wrote:
> Thanks for the reply. It appears that this is to some degree a
> semantically relevant restriction. We assume that a step never
> unblocks except when we run a future step, which is false in the case
> of the deadlock detector. However, once one step is waiting, we run
> fu
Hi,
On 2015-08-06 12:43:06 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
>
> > > Ah, but that's because you cheated and didn't remove the include from
> > > namespace.h ...
> >
> > Well, it's not included from frontend code, so I didn
On 08/14/2015 02:10 PM, Peter Geoghegan wrote:
On Fri, Aug 14, 2015 at 10:28 AM, Tom Lane wrote:
Yeah. The painful issues you're going to face are not that. They are
memory management (C++ "new" does not talk to palloc or vice versa)
and error handling ("throw" does not interoperate with PG
On 08/14/2015 12:42 PM, Tom Lane wrote:
In commit 0fc94a5ba I wrote:
+* ... It's okay to update the [ session-wide ]
+* hash table with the new tree because all plpgsql functions within a
+* given transaction share the same simple_eval_estate.
Um. Well, that's true for actual fun
On 2015-08-14 11:10:14 -0700, Peter Geoghegan wrote:
> On Fri, Aug 14, 2015 at 10:28 AM, Tom Lane wrote:
> > Yeah. The painful issues you're going to face are not that. They are
> > memory management (C++ "new" does not talk to palloc or vice versa)
> > and error handling ("throw" does not inter
On Fri, Aug 14, 2015 at 10:28 AM, Tom Lane wrote:
> Yeah. The painful issues you're going to face are not that. They are
> memory management (C++ "new" does not talk to palloc or vice versa)
> and error handling ("throw" does not interoperate with PG_TRY()).
It's worse than that. Any use of lon
On Fri, Aug 14, 2015 at 10:14 AM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> I had the idea that it would be useful to have some regression tests
>> that verify that the deadlock checker works as advertised, because we
>> currently have just about zero test coverage for it. And it's easy
>> en
Andres Freund writes:
> On 2015-08-14 18:38:36 +0200, jacques klein wrote:
>> However I coudn't find any doc. about how to solve the problem of linking
>> C++ code and libs into the .so of my extension,
>> and nothing to solve the runtime-loading problem of the c++ specific .so
>> files ( for ex.
Hi,
On 2015-08-14 18:38:36 +0200, jacques klein wrote:
> However I coudn't find any doc. about how to solve the problem of linking
> C++ code and libs into the .so of my extension,
> and nothing to solve the runtime-loading problem of the c++ specific .so
> files ( for ex. to make work a simple us
Hello, I want to write a "BackgroundWorker" in C++ (have lots of C++
code and libs to reuse).
I found " 35.9.13 Using C++ for Extensibility " in the 9.3/4
documentation who says it's possible and gives some guidelines for
source-code writing.
Compiling is not too difficult if one understand
Hi,
On 2015-08-14 11:20:39 +0200, Andres Freund wrote:
> when building with optimizations clang-3.7, probably some older
> compilers as well, fail with a funny error:
>
> fatal error: error in backend: Cannot select: intrinsic
> %llvm.x86.sse42.crc32.64.64
>
> turns out that is because configur
In commit 0fc94a5ba I wrote:
+* ... It's okay to update the [ session-wide ]
+* hash table with the new tree because all plpgsql functions within a
+* given transaction share the same simple_eval_estate.
Um. Well, that's true for actual functions, but plpgsql DO blocks use
their own
Hi,
On 2015-08-14 15:35:45 +0300, Heikki Linnakangas wrote:
> >But we've played that whack-a-mole game in a bunch of configure tests
> >now, and it seems likely that more are coming with compilers getting
> >better. I'd not be surprised if some tests actually always succeed, we
> >just don't notic
I had the idea that it would be useful to have some regression tests
that verify that the deadlock checker works as advertised, because we
currently have just about zero test coverage for it. And it's easy
enough to write a regression test that causes a simple 2-way deadlock.
But you can't test an
Robert Haas wrote:
> I had the idea that it would be useful to have some regression tests
> that verify that the deadlock checker works as advertised, because we
> currently have just about zero test coverage for it. And it's easy
> enough to write a regression test that causes a simple 2-way dead
Alexander Korotkov writes:
> On Thu, Aug 6, 2015 at 1:01 PM, Ildus Kurbangaliev <
> i.kurbangal...@postgrespro.ru> wrote:
>> This is why I think we shoudn't place wait event into PgBackendStatus. It
>> could be placed into PGPROC or even separate data structure with different
>> concurrency model
On Thu, Aug 6, 2015 at 1:01 PM, Ildus Kurbangaliev <
i.kurbangal...@postgrespro.ru> wrote:
> On 08/05/2015 09:33 PM, Robert Haas wrote:
>
>> On Wed, Aug 5, 2015 at 1:10 PM, Ildus Kurbangaliev
>> wrote:
>>
>>> About `memcpy`, PgBackendStatus struct already have a bunch of multi-byte
>>> variables,
On 08/14/2015 09:27 AM, Robert Haas wrote:
On Thu, Aug 13, 2015 at 2:11 PM, Alvaro Herrera wrote:
So I added the brin isolation test back. Because it needs the
pageinspect module, it can only work under "make check", not
installcheck. The problem is that this means buildfarm will not run it
On 08/14/2015 09:27 AM, Andrew Dunstan wrote:
On 08/14/2015 03:32 AM, Noah Misch wrote:
On Thu, Aug 13, 2015 at 11:17:40AM -0400, Andrew Dunstan wrote:
here's what I propose.
This changes more than the tapcheck name and the suites it could
run. Would
you write up the changes you chose to
On 08/14/2015 03:32 AM, Noah Misch wrote:
On Thu, Aug 13, 2015 at 11:17:40AM -0400, Andrew Dunstan wrote:
here's what I propose.
This changes more than the tapcheck name and the suites it could run. Would
you write up the changes you chose to include? That will help guide review.
I don't
On Thu, Aug 13, 2015 at 2:11 PM, Alvaro Herrera wrote:
> So I added the brin isolation test back. Because it needs the
> pageinspect module, it can only work under "make check", not
> installcheck. The problem is that this means buildfarm will not run it,
> because it only runs installcheck :-(
On 08/14/2015 12:20 PM, Andres Freund wrote:
Hi,
when building with optimizations clang-3.7, probably some older
compilers as well, fail with a funny error:
fatal error: error in backend: Cannot select: intrinsic
%llvm.x86.sse42.crc32.64.64
turns out that is because configure chose to use the
On 13 August 2015 at 00:31, Robert Haas wrote:
> On Wed, Aug 12, 2015 at 7:20 PM, Tom Lane wrote:
> > FWIW, I've objected in the past to tests that would significantly
> > increase the runtime of "make check", unless I thought they were
> > especially valuable (which enumerating every minor beha
On Thu, May 7, 2015 at 9:17 PM, Fabien COELHO wrote:
>
> Hello,
>
> Some comments/bug report about the commitfest web app which just bite me:-)
>
> When creating a patch with the commitfest app, if the thread does not
> exist the application seems to reject the creation, so you may resubmit
> bec
On Fri, Aug 14, 2015 at 9:32 PM, Rahul Majumdar/TVM/TCS
wrote:
> Hello Everyone,
>
> I have a problem related to query in PostgreSQL.Some queries are not
> running.Please help me to find out a solution.
Hi!
You've reached the Postgres hackers mailing list where Postgres
internals are discussed.
Hello Everyone,
I have a problem related to query in PostgreSQL.Some queries are not
running.Please help me to find out a solution.
Thanks
Rahul
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged in
Hi,
when building with optimizations clang-3.7, probably some older
compilers as well, fail with a funny error:
fatal error: error in backend: Cannot select: intrinsic
%llvm.x86.sse42.crc32.64.64
turns out that is because configure chose to use the crc32 instruction,
without the according compi
On 2015-08-14 11:09:38 +0200, Shulgin, Oleksandr wrote:
> Yes, but the options list you pass to START_REPLICATION ... LOGICAL, not to
> CREATE_REPLICATION_SLOT.
I know, but we might want to extend that at some point.
- Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Fri, Aug 14, 2015 at 9:54 AM, Andres Freund wrote:
> On 2015-08-14 16:44:44 +0900, Michael Paquier wrote:
> > Commit 6fcd8851, which is the result of this thread, is not touching
> > the replication protocol at all. This looks like an oversight to me:
> > we should be a maximum consistent betw
On 2015-08-14 16:44:44 +0900, Michael Paquier wrote:
> Commit 6fcd8851, which is the result of this thread, is not touching
> the replication protocol at all. This looks like an oversight to me:
> we should be a maximum consistent between the SQL interface and the
> replication protocol if possible
On Wed, Aug 12, 2015 at 8:20 AM, Andres Freund wrote:
> On 2015-08-11 15:59:59 -0700, Gurjeet Singh wrote:
>> In your version, I don't see a comment that refers to the fact that it
>> works on the currently active (global variable) slot.
>
> Hm?
>
> /*
> * Reserve WAL for the currently active slo
On Thu, Aug 13, 2015 at 11:17:40AM -0400, Andrew Dunstan wrote:
> here's what I propose.
This changes more than the tapcheck name and the suites it could run. Would
you write up the changes you chose to include? That will help guide review.
--
Sent via pgsql-hackers mailing list (pgsql-hacker
52 matches
Mail list logo