Marko Kreen writes:
> On Wed, Aug 1, 2012 at 6:18 PM, Tom Lane wrote:
>> So I'm working from the first set of patches in your message
>> <20120721194907.ga28...@gmail.com>.
> Great!
Here's an updated draft patch. I've not looked at the docs yet so
this doesn't include that, but I'm reasonably
On Wed, Aug 1, 2012 at 6:18 PM, Tom Lane wrote:
> Marko Kreen writes:
>> * Is there better API than PQsetSingleRowMode()? New PQsend*
>> functions is my alternative.
>
> After thinking it over, I'm really unexcited about adding new versions
> of all the PQsend functions. If we had the prospec
Il 30/07/12 19:16, Gabriele Bartolini ha scritto:
And it can be also interchanged with "Array element Foreign Key".
As promised, we have sent a patch for the "Array ELEMENT foreign key"
support.
We are discontinuing this thread here and continue discussing the former
"Foreign Keys with Array
Hi,
please find attached version 1 of the patch introducing "Array
ELEMENT Foreign Keys" support. This new thread and related patch
substitute any previous discussion about "Support for foreign keys with
arrays", as anticipated in
http://archives.postgresql.org/pgsql-hackers/2012-07/msg01098.ph
On Wed, Aug 1, 2012 at 10:12 AM, Tom Lane wrote:
> I think you may be right that using __asm__ __volatile__ in gcc
> S_UNLOCK cases would be a big step forward, but it needs more research
> to see if that's the only fix needed.
Looking through the spinlock implementations in s_lock.h, we start
wi
On 1 August 2012 15:14, Amit Kapila wrote:
> I shall look into this aspect also(setting commit_delay based on raw sync).
> You also suggest if you want to run the test with different configuration.
Well, I was specifically interested in testing if half of raw sync
time was a widely useful setting
[ getting back to this now after assorted distractions ]
Marko Kreen writes:
> Just to show agreement: both PQgetRowData() and optimized PGresult
> do not belong to 9.2.
OK, we're all on board with leaving those for later.
> Only open questions are:
> * Is there better API than PQsetSingleRowM
On Wed, Aug 1, 2012 at 10:12 AM, Tom Lane wrote:
> Solving the problem for linux only, or gcc only, isn't going to get us
> to a place where we can stop volatile-izing call sites. We need to be
> sure it works for every single case supported by s_lock.h.
Yep, that's the problem all right.
> I t
> From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Geoghegan
> Sent: Sunday, July 29, 2012 9:09 PM
> I made what may turn out to be a useful observation during the
> development of the patch, which was that for both the tpc-b.sql and
> insert
Robert Haas writes:
> On Tue, Jul 31, 2012 at 4:06 PM, Tom Lane wrote:
>> I agree that volatile-izing everything in the vicinity is a sucky
>> solution, but the last time we looked at this there did not seem to
>> be a better one.
> Well, Linux has a barrier() primitive which is defined as a
> c
On Tue, Jul 31, 2012 at 4:06 PM, Tom Lane wrote:
> Robert Haas writes:
>> IMHO, the way we have it now is kind of a mess. SpinLockAcquire and
>> SpinLockRelease are required to be CPU barriers, but they are not
>> required to be compiler barriers. If we changed that so that they
>> were require
> From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org]
> On Behalf Of Tom Lane
> We've had a couple of complaints recently from people who were unhappy
because the
> syslogger's log_truncate_on_rotation logic does not fire during the first
log rotation > after it'
Dear PostgreSQL developers,
Plese find attached a patch so that:
Make "psql -1 < file.sql" work as with "-f"
Make psql --single-transaction option work on a non-interactive
standard input as well, so that "psql -1 < input.sql" behaves as
"psql -1 -f input.sql".
This saner/less
13 matches
Mail list logo
