2012-04-09 19:32 keltezéssel, Robert Haas írta:
On Sun, Apr 8, 2012 at 9:37 PM, Robert Haas wrote:
Robert, the Assert triggering with the above procedure
is in your "fast path" locking code with current GIT.
Yes, that sure looks like a bug. It seems that if the top-level
transaction is aborti
On 10.04.2012 03:32, Jeff Janes wrote:
The To Do wiki says not to add things to the page with discussing here.
So here are some things to discuss. Assuming the discussion is a
brief yup or nope, it seems to make sense to lump them into one email:
Vacuuming a table with a large GIN index is pai
I cannot see your task manager, may be you can send it as .bmp attached with
this mail.
As there is only one postgres process, it seems your postgres server itself
is not started.
>>For the second I have little experience with computers, you could help me
write the correct command.
a.G
On Mon, 2012-04-09 at 22:47 -0700, Jeff Davis wrote:
> but other similar paths do:
>
> if (!proclock)
> {
> AbortStrongLockAcquire();
>
> I don't think it's necessary outside of LockErrorCleanup(), right?
I take that back, it's necessary for the dontwait case, too.
Regards,
Jeff
On Mon, 2012-04-09 at 13:32 -0400, Robert Haas wrote:
> I looked at this more. The above analysis is basically correct, but
> the problem goes a bit beyond an error in LockWaitCancel(). We could
> also crap out with an error before getting as far as LockWaitCancel()
> and have the same problem.
On 10/04/12 04:20, Tom Lane wrote:
Don't know if anybody noticed bug #6559
http://archives.postgresql.org/pgsql-bugs/2012-03/msg00180.php
I've confirmed that the given test case works in 9.0 but fails in
9.1 and HEAD.
I find this code pretty unreadable, though, and know nothing to
speak of abou
On Mon, Apr 9, 2012 at 7:38 PM, Robert Haas wrote:
> On Mon, Apr 9, 2012 at 6:23 PM, Noah Misch wrote:
>> But objective rules do not require a just judge, and they have a
>> different advantage: predictability. If I know that a clock starts ticking
>> the moment I get my first review, I'll shape
Don't know if anybody noticed bug #6559
http://archives.postgresql.org/pgsql-bugs/2012-03/msg00180.php
I've confirmed that the given test case works in 9.0 but fails in
9.1 and HEAD. It's not terribly sensitive to the details of the
SQL: any non-null value for the composite column fails, for inst
The To Do wiki says not to add things to the page with discussing here.
So here are some things to discuss. Assuming the discussion is a
brief yup or nope, it seems to make sense to lump them into one email:
Vacuuming a table with a large GIN index is painfully slow, because
the index is vacuume
Robert Haas writes:
> At any rate, I think your comments are driving at a good point, which
> is that CommitFests are a time for patches that are done or very
> nearly done to get committed, and a time for other patches to get
> reviewed if they haven't been already. If we make it clear that the
On Mon, Apr 9, 2012 at 6:23 PM, Noah Misch wrote:
> But objective rules do not require a just judge, and they have a
> different advantage: predictability. If I know that a clock starts ticking
> the moment I get my first review, I'll shape my personal plan accordingly.
> That works even if I don
On Mon, 2012-04-09 at 17:42 -0500, Jim Nasby wrote:
> Dumb question... should operations in the various StrongLock functions
> take place in a critical section? Or is that already ensure outside of
> these functions?
Do you mean CRITICAL_SECTION() in the postgres sense (that is, avoid
error paths
On 4/9/12 12:32 PM, Robert Haas wrote:
I looked at this more. The above analysis is basically correct, but
the problem goes a bit beyond an error in LockWaitCancel(). We could
also crap out with an error before getting as far as LockWaitCancel()
and have the same problem. I think that a correc
On Mon, Apr 09, 2012 at 09:25:36AM -0400, Robert Haas wrote:
> On Mon, Apr 9, 2012 at 1:38 AM, Noah Misch wrote:
> > http://wiki.postgresql.org/wiki/Running_a_CommitFest suggests marking a
> > patch
> > Returned with Feedback after five consecutive days of Waiting on Author.
> > ?That
> > was a
On Mon, 2012-04-09 at 16:11 -0400, Robert Haas wrote:
> > I wonder though whether
> > you actually need a *count*. What if it were just a flag saying "do not
> > take any fast path locks on this object", and once set it didn't get
> > unset until there were no locks left at all on that object?
>
On lör, 2012-04-07 at 16:51 -0400, Robert Haas wrote:
> Even before this CommitFest, it's felt to me like this hasn't been a
> great cycle for reviewing. I think we have generally had fewer people
> doing reviews than we did during the 9.0 and 9.1 cycles. I think we
> had a lot of momentum with t
On Mon, Apr 9, 2012 at 2:42 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 9, 2012 at 1:49 PM, Tom Lane wrote:
>>> Haven't looked at the code, but maybe it'd be better to not bump the
>>> strong lock count in the first place until the final step of updating
>>> the lock tables?
>
>> We
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of lun abr 09 15:38:21 -0300 2012:
>> What exactly would you do with it there that you couldn't do more easily
>> and clearly with plain timestamp comparisons? I'm willing to be
>> convinced, but I want to see a case where it really is the
Encoding names are currently sometimes quoted (encoding \"%s\"),
sometimes not (encoding %s). Which one should we settle on?
In favor of quoting is that we do this for everything else. But since
the possible encoding names are known in advance, we know we don't have
to do the quoting to avoid am
Excerpts from Peter Eisentraut's message of vie abr 06 03:09:10 -0300 2012:
> On fre, 2012-04-06 at 00:25 -0300, Alvaro Herrera wrote:
> > Some moments of radical thinking later, I became unhappy with the fact
> > that the conninfo stuff and parameter keywords are all crammed in the
> > PQconnectdb
On Wed, Mar 21, 2012 at 09:28:22PM -0400, Robert Haas wrote:
> On Wed, Mar 21, 2012 at 9:22 PM, Tom Lane wrote:
> >> It strikes me that it likely wouldn't be any
> >> worse than, oh, say, flipping the default value of
> >> standard_conforming_strings,
> >
> > Really? It's taking away functionalit
Excerpts from Tom Lane's message of lun abr 09 15:38:21 -0300 2012:
>
> Alvaro Herrera writes:
> >> Robert Haas writes:
> >>> If somebody needs it I'd probably be in favor of doing it. I'm not
> >>> sure I'd do it on spec.
>
> > It would be useful to have a simple function to use with timesta
On Mon, Apr 09, 2012 at 01:29:46PM -0500, Merlin Moncure wrote:
> but generally speaking jdbc is displacing odbc as the 'go to' library
> for connection between different kinds of database systems, especially
> on non-windows environments. jdbc is to java as fdw is to postgres
> basically. so a f
Robert Haas writes:
> On Mon, Apr 9, 2012 at 1:49 PM, Tom Lane wrote:
>> Haven't looked at the code, but maybe it'd be better to not bump the
>> strong lock count in the first place until the final step of updating
>> the lock tables?
> Well, unfortunately, that would break the entire mechanism.
Alvaro Herrera writes:
>> Robert Haas writes:
>>> If somebody needs it I'd probably be in favor of doing it. I'm not
>>> sure I'd do it on spec.
> It would be useful to have a simple function to use with timestamp in
> constraint exclusion without having to use contorted expressions ...
> An im
On 04/09/2012 02:14 PM, Bruce Momjian wrote:
On Tue, Mar 20, 2012 at 01:25:15PM +0100, Claes Jakobsson wrote:
On 20 mar 2012, at 13.08, Heikki Linnakangas wrote:
On 20.03.2012 11:10, Claes Jakobsson wrote:
Personally I'd love a type 2 JDBC driver for PostgreSQL.
Why?
listen/notify over SSL
On Mon, Apr 9, 2012 at 1:14 PM, Bruce Momjian wrote:
> Well, I assume they reimplemented libpq so that java would not rely on a
> platform-specific library like libpq.
yes, that is correct. jdbc for postgres is a complete implementation
of the client side protocol. this has some good and bad po
On 04/09/2012 01:38 PM, Tom Lane wrote:
Andrew Dunstan writes:
i.e. we'd forbid:
initdb -D foo bar
which the OP's error more or less devolves to.
Makes sense. Don't we have a similar issue with psql, pg_dump, etc?
From a quick survey:
psql won't override a dbname or username set e
On Mon, Apr 9, 2012 at 1:49 PM, Tom Lane wrote:
> Robert Haas writes:
>> I looked at this more. The above analysis is basically correct, but
>> the problem goes a bit beyond an error in LockWaitCancel(). We could
>> also crap out with an error before getting as far as LockWaitCancel()
>> and ha
Excerpts from Tom Lane's message of lun abr 09 15:04:10 -0300 2012:
> Robert Haas writes:
> > On Mon, Apr 9, 2012 at 1:30 PM, Tom Lane wrote:
> >> http://archives.postgresql.org/pgsql-general/2012-01/msg00649.php
> >> The above-linked discussion also brings up a different point, which is
> >> th
On Tue, Mar 20, 2012 at 01:25:15PM +0100, Claes Jakobsson wrote:
>
> On 20 mar 2012, at 13.08, Heikki Linnakangas wrote:
> > On 20.03.2012 11:10, Claes Jakobsson wrote:
> >>
> >> Personally I'd love a type 2 JDBC driver for PostgreSQL.
> >
> > Why?
>
> listen/notify over SSL for example unless
"Greg Sabino Mullane" writes:
>> so that we could mark it immutable. On the other hand, it's not
>> entirely apparent why people would need to create indexes on the epoch
>> value rather than just indexing the timestamp itself
> Well, it makes for smaller indexes if you don't really care about
On Mon, Apr 9, 2012 at 11:40 PM, Merlin Moncure wrote:
> On Mon, Apr 9, 2012 at 12:25 PM, Atri Sharma wrote:
>> On Mon, Apr 9, 2012 at 10:15 PM, Andrew Dunstan wrote:
>>> On 04/09/2012 12:14 PM, Dave Cramer wrote:
So I'm confused, once they link a file to an FDW can't you just read
it
On Mon, Apr 9, 2012 at 12:25 PM, Atri Sharma wrote:
> On Mon, Apr 9, 2012 at 10:15 PM, Andrew Dunstan wrote:
>> On 04/09/2012 12:14 PM, Dave Cramer wrote:
>>> So I'm confused, once they link a file to an FDW can't you just read
>>> it with an normal select ?
>>>
>>> What additional functionality
Robert Haas writes:
> On Mon, Apr 9, 2012 at 1:30 PM, Tom Lane wrote:
>> http://archives.postgresql.org/pgsql-general/2012-01/msg00649.php
>> The above-linked discussion also brings up a different point, which is
>> that extracting the epoch from a timestamptz is an immutable operation,
>> but be
Robert Haas writes:
> I looked at this more. The above analysis is basically correct, but
> the problem goes a bit beyond an error in LockWaitCancel(). We could
> also crap out with an error before getting as far as LockWaitCancel()
> and have the same problem. I think that a correct statement
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> so that we could mark it immutable. On the other hand, it's not
> entirely apparent why people would need to create indexes on the epoch
> value rather than just indexing the timestamp itself
Well, it makes for smaller indexes if you don't r
On Mon, Apr 9, 2012 at 1:30 PM, Tom Lane wrote:
> A long time ago, we had this bug report:
> http://archives.postgresql.org/pgsql-bugs/2003-02/msg00069.php
> in consequence of which, I changed timestamp_part() so that it would
> rotate a timestamp-without-timezone from the local timezone to GMT
>
Andrew Dunstan writes:
> i.e. we'd forbid:
> initdb -D foo bar
> which the OP's error more or less devolves to.
Makes sense. Don't we have a similar issue with psql, pg_dump, etc?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On Mon, Apr 9, 2012 at 10:15 PM, Andrew Dunstan wrote:
>
>
> On 04/09/2012 12:14 PM, Dave Cramer wrote:
>>
>>
>> So I'm confused, once they link a file to an FDW can't you just read
>> it with an normal select ?
>>
>> What additional functionality will this provide ?
>>
>
>
>
> I'm confused about
On Sun, Apr 8, 2012 at 9:37 PM, Robert Haas wrote:
>> Robert, the Assert triggering with the above procedure
>> is in your "fast path" locking code with current GIT.
>
> Yes, that sure looks like a bug. It seems that if the top-level
> transaction is aborting, then LockReleaseAll() is called and
A long time ago, we had this bug report:
http://archives.postgresql.org/pgsql-bugs/2003-02/msg00069.php
in consequence of which, I changed timestamp_part() so that it would
rotate a timestamp-without-timezone from the local timezone to GMT
before extracting the epoch offset (commit
191ef2b407f06554
On 04/09/2012 12:36 PM, Clover White wrote:
2012/4/9 Andrew Dunstan mailto:and...@dunslane.net>>
On 04/09/2012 07:38 AM, Clover White wrote:
Hi,
I'm debugging initdb using gdb.
I found that I could not step in the function getopt_long in
line 2572 in in
Dave Cramer wrote:
> Andrew Dunstan wrote:
>> All you'll need on the postgres side is the relevant JDBC driver,
>> so you'd have instant access via standard select queries to
>> anything you can get a JDBC driver to talk to. That seems to me
>> something worth having.
>>
>> I imagine it would
On Mon, Apr 9, 2012 at 12:45 PM, Andrew Dunstan wrote:
>
>
> On 04/09/2012 12:14 PM, Dave Cramer wrote:
>>
>>
>> So I'm confused, once they link a file to an FDW can't you just read
>> it with an normal select ?
>>
>> What additional functionality will this provide ?
>>
>
>
>
> I'm confused about
On 04/09/2012 12:14 PM, Dave Cramer wrote:
So I'm confused, once they link a file to an FDW can't you just read
it with an normal select ?
What additional functionality will this provide ?
I'm confused about what you're confused about. Surely this won't be
linking files to an FDW, but f
2012/4/9 Robert Haas
> On Mon, Apr 9, 2012 at 7:38 AM, Clover White
> wrote:
> > Hi,
> > I'm debugging initdb using gdb.
> > I found that I could not step in the function getopt_long in line 2572
> in
> > initdb.c.
> > I also found that the value of VAR optind never be changed. VAR optind
On Mon, Apr 9, 2012 at 11:14 AM, Dave Cramer wrote:
> So I'm confused, once they link a file to an FDW can't you just read
> it with an normal select ?
>
> What additional functionality will this provide ?
>
> Dave
The basic objective is to expose the JDBC to postgres for grabbing
external data.
2012/4/9 Andrew Dunstan
>
>
> On 04/09/2012 07:38 AM, Clover White wrote:
>
>> Hi,
>> I'm debugging initdb using gdb.
>> I found that I could not step in the function getopt_long in line 2572
>> in initdb.c.
>> I also found that the value of VAR optind never be changed. VAR optind
>> is always
On Mon, Apr 9, 2012 at 11:32 AM, Noah Misch wrote:
> On Mon, Apr 09, 2012 at 03:35:06PM +0200, Andres Freund wrote:
>> On Monday, April 09, 2012 03:25:36 PM Robert Haas wrote:
>> > contrib/xml2 isn't doing us much harm beyond being an ugly wart, but non-
>> > SELECT rules are a land mine for the u
On Mon, Apr 9, 2012 at 11:55 AM, Merlin Moncure wrote:
> On Mon, Apr 9, 2012 at 10:47 AM, Dave Cramer wrote:
>> How will the user access this? Will it be a normal query through the
>> existing API ? Will it be a private postgresql API ?
>>
>> How will they set it up ? It appears complicated as yo
On Mon, Apr 9, 2012 at 10:47 AM, Dave Cramer wrote:
> How will the user access this? Will it be a normal query through the
> existing API ? Will it be a private postgresql API ?
>
> How will they set it up ? It appears complicated as you have to setup
> PL/Java as well
Yeah -- it will run through
How will the user access this? Will it be a normal query through the
existing API ? Will it be a private postgresql API ?
How will they set it up ? It appears complicated as you have to setup
PL/Java as well
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On Mon, Apr 9, 2012
On Sun, Apr 8, 2012 at 8:56 AM, Dave Cramer wrote:
> Hi Atri,
>
> Is there some JDBC API that supports this in newer versions of the API ?
Didn't parse that question. My understanding is that the only JDBC
features needed are what's already there, to make connections to
databases and execute que
Hi all,
I submitted a proposal for GSoc 2012.Please review it and let me know
your comments.
The link is:
https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2012/atrisharma/1001
Atri
--
Regards,
Atri
l'apprenant
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On Mon, Apr 09, 2012 at 03:35:06PM +0200, Andres Freund wrote:
> On Monday, April 09, 2012 03:25:36 PM Robert Haas wrote:
> > contrib/xml2 isn't doing us much harm beyond being an ugly wart, but non-
> > SELECT rules are a land mine for the unwary at best.
> Which we could start deprecating now btw
On Sun, Mar 18, 2012 at 7:25 AM, Cédric Villemain
wrote:
>> Would be nice to sort out the features of the two Postgres extentions
>> pgfincore (https://github.com/klando/pgfincore ) and pg_prewarm: what
>> do they have in common, what is complementary?
>
> pg_prewarm use postgresql functions (buff
Peter Geoghegan writes:
> Having taken another look at the code, I wonder if we wouldn't have
> been better off just fastpathing out of pgss_store in the first call
> (in a pair of calls made by a backend as part an execution of some
> non-prepared query) iff there is already an entry in the hasht
Ashutosh Bapat writes:
> After such a copy tests like if (pointer) will start failing. There are few
> callers of COPY_POINTER_FIELD which do not call the macro if the size can
> be 0. But there are some who do not do so. This looks fishy, in case we
> have if (pointer) kinds of cases.
I don't th
On Thu, Apr 5, 2012 at 8:35 PM, iihero wrote:
> From this point of view, seems N dimensions of empty array all are
> equivalent.
Yes. It's effectively viewed as a 0-dimensional array.
> Is there standard definition of this behavior?
No. Multi-dimensional arrays are a PostgreSQL extension.
--
On Monday, April 09, 2012 03:25:36 PM Robert Haas wrote:
> contrib/xml2 isn't doing us much harm beyond being an ugly wart, but non-
> SELECT rules are a land mine for the unwary at best.
Which we could start deprecating now btw. since INSTEAD triggers landed in
9.1. There were quite some use-case
On Mon, Apr 9, 2012 at 7:38 AM, Clover White wrote:
> Hi,
> I'm debugging initdb using gdb.
> I found that I could not step in the function getopt_long in line 2572 in
> initdb.c.
> I also found that the value of VAR optind never be changed. VAR optind is
> always equal to 1 but how could op
On Mon, Apr 9, 2012 at 1:38 AM, Noah Misch wrote:
> http://wiki.postgresql.org/wiki/Running_a_CommitFest suggests marking a patch
> Returned with Feedback after five consecutive days of Waiting on Author. That
> was a great tool for keeping things moving, and I think we should return to it
> or a
On 09-04-2012 02:43, Vikash3 S wrote:
> Please find the patch regarding trivial changes against To Do item list for
> "psql : Allow processing of multiple -f (file) options ".
> Looking for valuable feedback.
>
Aren't you forget to cover the single transaction (-1) mode? How would you
handle ON_ER
On 04/09/2012 07:38 AM, Clover White wrote:
Hi,
I'm debugging initdb using gdb.
I found that I could not step in the function getopt_long in line
2572 in initdb.c.
I also found that the value of VAR optind never be changed. VAR
optind is always equal to 1 but how could optind be larger
Hi,
I'm debugging initdb using gdb.
I found that I could not step in the function getopt_long in line 2572 in
initdb.c.
I also found that the value of VAR optind never be changed. VAR optind is
always equal to 1 but how could optind be larger than the value of argc(the
value of argc is 6) in
Hi,
COPY_POINTER_FIELD is defined as -
61 #define COPY_POINTER_FIELD(fldname, sz) \
62 do { \
63 Size_size = (sz); \
64 newnode->fldname = palloc(_size); \
65 memcpy(newnode->fldname, from->fldname, _size); \
66 } while (0)
Since we allocate _size me
2012/4/9 Shigeru HANADA :
> 1) connect to the server at the beginning of the local query
> 2) execute EXPLAIN for foreign table foo
> 3) execute EXPLAIN for foreign table bar
> 4) execute actual query for foreign table foo
> 5) execute actual query for foreign table bar
> 6) disco
On Mon, Mar 12, 2012 at 3:50 PM, Alexander Korotkov wrote:
> I believe that attached version of patch can be backpatched. It fixes this
> problem without altering of index building procedure. It just makes checks
> in internal pages softener enough to compensate effect of gist_box_same
> implement
69 matches
Mail list logo
