I wrote:
> ... Polya's Inventors' Paradox states that
> "the more general problem may be easier to solve", and I've found that
> usually holds up in program design too.
While fooling around with the grammar patch that I showed earlier today,
I had an epiphany that might serve as illustration of th
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> wrote
>> "Qingqing Zhou" <[EMAIL PROTECTED]> writes:
>>> After this, the proc->sem will be bumped to 1 unexpectedly ... Since
>>> this problem is rare, a possible fix is to put a critical section
>>> around line 1 to 7 and
"Tom Lane" <[EMAIL PROTECTED]> wrote
> "Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> > After this, the proc->sem will be bumped to 1 unexpectedly ... Since
this
> > problem is rare, a possible fix is to put a critical section around line
1
> > to 7 and remove UnlockBuffers() accordingly.
>
> No, t
Quoting Tom Lane <[EMAIL PROTECTED]>:
> I fear we still have to disable full_page_writes (force it ON) if
> XLogArchivingActive is on. Comments?
Yeah - if you are enabling PITR, then you care about safety and integrity, so it
makes sense (well, to me anyway).
Cheers
Mark
---
I wrote [ in an off-list reply to Mark Dilger ]:
> I don't think this solves the parsing problem at all. The problem as I
> see it is that given
> CREATE AGGREGATE foo (bar ...
> it's not obvious whether bar is a def_elem name (old syntax) or a type
> name (new syntax). It's possible that w
Jonah,
> Where do we stand on this?
Google sent me the docs on this year's SoC literally 2 hours ago. I need
to read through them and start trying to connect mentors and students and
projects.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Right... As I mentioned, the application can use cursors to
> > *work-around* this foolishness in libpq but that doesn't really make it
> > any less silly.
>
> Before you define libpq's behavior as "foolishness"
Where do we stand on this?
--
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
732.331.1324
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Ãhel kenal päeval, R, 2006-04-14 kell 16:40, kirjutas Tom Lane:
>> If the backup-taker reads, say, 4K at a time then it's
>> certainly possible that it gets a later version of the second half of a
>> page than it got of the first half. I don't know abo
Ühel kenal päeval, R, 2006-04-14 kell 16:40, kirjutas Tom Lane:
> I think we had originally argued that there was no problem anyway
> because the kernel should cause the page write to appear atomic to other
> processes (since we issue it in a single write() command). But that's
> only true if the
Stephen Frost <[EMAIL PROTECTED]> writes:
> Right... As I mentioned, the application can use cursors to
> *work-around* this foolishness in libpq but that doesn't really make it
> any less silly.
Before you define libpq's behavior as "foolishness", you really ought to
have a watertight semantics
While thinking about the patch I just made to allow full_page_writes to
be turned off again, it struck me that this patch only fixes the problem
for post-crash XLOG replay. There is still a hazard if the variable is
turned off in a PITR master system. The reason is that while a base
backup is bei
Tom Lane wrote:
> I would really prefer to see CREATE AGGREGATE normalized to have a
> syntax comparable to CREATE FUNCTION (or DROP AGGREGATE for that
> matter):
> CREATE AGGREGATE aggname (typname [, ... ]) ...definition...
> but it's not clear how to get there without breaking backwards
>
* Greg Stark ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Another thought along these lines: Perhaps a 'PQgettuple' which can be
> > used to process one tuple at a time. This would be used in an ASYNC
> > fashion and libpq just wouldn't read/accept more than a tuple'
Stephen Frost <[EMAIL PROTECTED]> writes:
> Another thought along these lines: Perhaps a 'PQgettuple' which can be
> used to process one tuple at a time. This would be used in an ASYNC
> fashion and libpq just wouldn't read/accept more than a tuple's worth
> each time, which it could do into a f
On Fri, Apr 14, 2006 at 01:05:11PM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Perhaps a far easier approach would be to indeed just have a hijack
> > interface that provides read/write over whatever protocol libpq
> > negotiated.
>
> Well, there's a precedent to look at: the orig
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> Does it make sense to extend the aggregate
> functions to the only two-argument case?
No, I don't think so, for two reasons:
1. The user's-eye view: if someone wants 2 arguments, tomorrow he'll
want 3, etc. There's an old saying that "the only go
Martijn van Oosterhout writes:
> Perhaps a far easier approach would be to indeed just have a hijack
> interface that provides read/write over whatever protocol libpq
> negotiated.
Well, there's a precedent to look at: the original implementation of
COPY mode was pretty nearly exactly that. And
I get the following error: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -fno-strict-aliasing -I. -I../../../src/include -I./src/include/port/win32 -DEXEC_BACKEND "-I../../../src/include/port/win32" -DBUILDING_DLL -c -o bootparse.o bootparse.cbootparse.y:101:10: "b4_file_name" i
On Thu, 13 Apr 2006, Tom Lane wrote:
> "Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> > ... Nothing else and nothing internal need not to be changed to
> > insert new two-arg. aggregate functions into the core.
> > Am I right in this ?
>
> IIRC the main issues are the syntax of CREATE AGGRE
On Fri, Apr 14, 2006 at 11:22:23AM -0400, Tom Lane wrote:
> Greg's observation is correct, so maybe we are overthinking this
> problem. A fair question to ask is whether psqlODBC would consider
> going back to a non-hybrid implementation if these features did exist
> in libpq.
Well, it is an issu
-Original Message-
From: "Bruce Momjian"
Sent: 14/04/06 16:57:58
To: "Dave Page"
Cc: "[EMAIL PROTECTED]"<[EMAIL PROTECTED]>,
"kleptog@svana.org", "[EMAIL PROTECTED]"<[EMAIL PROTECTED]>,
"[EMAIL PROTECTED]"<[EMAIL PROTECTED]>,
"pgsql-hackers@postgresql.org",
"inoue@tpf.co.jp"
Subject: R
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Please mention some specific examples. We need some examples as a
> reality check.
Just took a look through a couple of Debian packages which depend on
libpq4:
libpam-pgsql: pam_pgsql.c, line 473 it uses PQgetvalue() as one would
expect, but doesn't actual
> > It's not something I want to spend any more time on, and Hiroshi made
> > it quite clear on -odbc yesterday that he doesn't want libpq to become
> > a requirement of psqlODBC (it's dynamically loaded atm, thus is
> > optional).
>
> Hiroshi does not speak for the psqlODBC project. It is a com
Dave Page wrote:
> > Hiroshi does not speak for the psqlODBC project. It is a community
> > project.
>
> I am well aware of that, but as he is by far the most experienced and
> productive ODBC developer we have it would not be particularly sensible
> to not give his opinion the weight it deserves
-Original Message-
From: "Bruce Momjian"
Sent: 14/04/06 16:42:08
To: "Dave Page"
Cc: "[EMAIL PROTECTED]"<[EMAIL PROTECTED]>,
"kleptog@svana.org", "[EMAIL PROTECTED]"<[EMAIL PROTECTED]>,
"[EMAIL PROTECTED]"<[EMAIL PROTECTED]>,
"pgsql-hackers@postgresql.org",
"inoue@tpf.co.jp"
Subject:
Dave Page wrote:
>
> -Original Message- From: "Tom Lane"<[EMAIL PROTECTED]> Sent:
> 14/04/06 16:22:45 To: "Martijn van Oosterhout" Cc:
> "Greg Stark"<[EMAIL PROTECTED]>, "Zeugswetter Andreas DCP
> SD"<[EMAIL PROTECTED]>, "Dave Page",
> "pgsql-hackers@postgresql.org", "Hiroshi
> Inoue" Subj
-Original Message-
From: "Tom Lane"<[EMAIL PROTECTED]>
Sent: 14/04/06 16:22:45
To: "Martijn van Oosterhout"
Cc: "Greg Stark"<[EMAIL PROTECTED]>, "Zeugswetter Andreas DCP SD"<[EMAIL
PROTECTED]>, "Dave Page",
"pgsql-hackers@postgresql.org", "Hiroshi
Inoue"
Subject: Re: [HACKERS] Practical
On Fri, Apr 14, 2006 at 04:53:53PM +0200, Martijn van Oosterhout wrote:
> Sounds really good.
There's a message on the pgsql-odbc mailing list[1] with some reasons
for not using libpq:
1. The driver sets some session default parameters(DateStyle,
client_encoding etc) using start-up message.
Martijn van Oosterhout writes:
> On Fri, Apr 14, 2006 at 10:42:33AM -0400, Greg Stark wrote:
>> As long as there's a defined wire protocol (and there will always be
>> one) then there's nothing wrong with what the psqlODBC driver is doing
> Well, the main motivation for this is that when a new ve
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> As for adding checks to startup scripts, that's a PITA because
> those scripts will have no idea of where tablespaces might be defined,
> so you'd have to hard-code that info in.
No, just look in $PGDATA/pg_tblspc to see where the symlinks point.
I'd le
On Fri, Apr 14, 2006 at 10:42:33AM -0400, Greg Stark wrote:
> Hm, now that I've had some sleep I think I see where you're going with this.
>
> As long as there's a defined wire protocol (and there will always be one) then
> there's nothing wrong with what the psqlODBC driver is doing and having a
On Thu, Apr 13, 2006 at 09:00:10PM -0400, Tom Lane wrote:
> Probably there would need to be at least three callbacks involved:
> one for setup, called just after the tuple descriptor info has been
> received; one for per-field data receipt, and one for per-tuple
> operations (called after all the f
Greg Stark <[EMAIL PROTECTED]> writes:
> "Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes:
>
> > > Well, the psqlODBC driver apparently ran into a number of problems with
> > > libpq that resulted in them not using it for their purpose. Given libpq
> > > primary purpose is to connect to Po
Jim C. Nasby wrote:
> Yeah, my assumption has been that the only way to tell the difference
> would be by timing, but I don't know how practical that is. Since
> gettime() or whatever EXPLAIN ANALYZE uses is apparently very expensive,
> perhaps there's some other alternative. Perhapse the timing in
Jim C. Nasby wrote:
On Thu, Apr 13, 2006 at 04:39:59AM -0400, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian writes:
Bruno Almeida do Lago wrote:
After that night, I started to ask myself if PostgreSQL should not have a
control file to check if expected datafiles are where they shoul
"Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes:
> > Well, the psqlODBC driver apparently ran into a number of problems with
> > libpq that resulted in them not using it for their purpose. Given libpq
> > primary purpose is to connect to PostgreSQL, it failing at that is
> > something tha
> Well, the psqlODBC driver apparently ran into a number of problems
with
> libpq that resulted in them not using it for their purpose.
> Given libpq primary purpose is to connect to PostgreSQL, it failing at
that is
> something that should be fixed.
I think you are forgetting, that e.g. a JDBC
38 matches
Mail list logo
